Just noticed...

[Bill Stoddard <bi...@wstoddard.com>]

The windows make files are in the source tree.  This is rather annoying when I
do a cvs diff -u from the top of the tree (or a cvs commit from the top) as
the makefiles are no longer kept up to date. Can we either keep the files up
to date or nuke them completely (which is what I though we decided to do for
2.0 anyway)

Bill

Re: Just noticed...

[Bill Stoddard <bi...@wstoddard.com>]

> On Wed, Jan 24, 2001 at 05:54:43PM -0500, Bill Stoddard wrote:
> > The windows make files are in the source tree.  This is rather annoying when I
> > do a cvs diff -u from the top of the tree (or a cvs commit from the top) as
> > the makefiles are no longer kept up to date. Can we either keep the files up
> > to date or nuke them completely (which is what I though we decided to do for
> > 2.0 anyway)
>
> When people are building tarballs on Unix, how would they create the .mak
> files?

Sorry, I was specifically referring to the Windows make files.  I tend to like to generate new
makefiles from the .dsp project files and do my compiles from the command line. If I change a lot of
code then expect to do a cvs commit from the root directory, I get all the diffs to the makefiles as
well which is a RPIB.

> When OtherBill perfects his makefile generator, then I presume that
> we can toss the .mak files and just insert a step in the release process to
> generate them (or mebbe they'd be created all the time by buildconf).

Okay...

Bill

Re: Just noticed...

[Greg Stein <gs...@lyra.org>]

On Wed, Jan 24, 2001 at 05:54:43PM -0500, Bill Stoddard wrote:
> The windows make files are in the source tree.  This is rather annoying when I
> do a cvs diff -u from the top of the tree (or a cvs commit from the top) as
> the makefiles are no longer kept up to date. Can we either keep the files up
> to date or nuke them completely (which is what I though we decided to do for
> 2.0 anyway)

When people are building tarballs on Unix, how would they create the .mak
files? When OtherBill perfects his makefile generator, then I presume that
we can toss the .mak files and just insert a step in the release process to
generate them (or mebbe they'd be created all the time by buildconf).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Just noticed...

[Bill Stoddard <bi...@wstoddard.com>]

> For the alpha cycle, yes, we decided to forgo the .mak files.  They were built
> immediately before we expected to launch the first beta.
> 
> Nuke them from the tree if you like, we can resussetate them right before
> we roll each tree.
> 
> The problem is - if you don't built the projects, you can't effectively build
> the dependencies to export the make files

I'll just build from dev studio from now on.  The awk script even work correctly :-)

Bill

Re: Just noticed...

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

For the alpha cycle, yes, we decided to forgo the .mak files.  They were built
immediately before we expected to launch the first beta.

Nuke them from the tree if you like, we can resussetate them right before
we roll each tree.

The problem is - if you don't built the projects, you can't effectively build
the dependencies to export the make files.  That is, there are hidden dependencies
that are only 'revealed' on a build (dropping in config.h files all about.)
So the convoluted sequence becomes:

1. build the InstallBin project from the .dsp's.
2. export the make files from the .dsp's

Bill

----- Original Message ----- 
From: "Bill Stoddard" <bi...@wstoddard.com>
To: <ne...@apache.org>
Sent: Wednesday, January 24, 2001 4:54 PM
Subject: Just noticed...


> The windows make files are in the source tree.  This is rather annoying when I
> do a cvs diff -u from the top of the tree (or a cvs commit from the top) as
> the makefiles are no longer kept up to date. Can we either keep the files up
> to date or nuke them completely (which is what I though we decided to do for
> 2.0 anyway)
> 
> Bill
> 
>