Re: proposal to fork the build-tools projects

[Roger Leigh]

Tom Lord [EMAIL PROTECTED] writes:

Long-time automake readers already know I'm strongly against
this sort of structuring.  This yields Makefiles which are
fragile and undependable.  For instance, if you create a
temporary file with a source-like name in the source tree,
then the build fails.
 
 
 Conversely, using the opposite approach, if you add a source file, and
 fail to correctly update the makefile, the build fails.  Big whoop.
 Just as fragile and undependable either way.  This is a purely
 rhetorical line of analysis that admits no objective decision making.

Globbing can inadvertently lead to unwanted files being
compiled/distributed/deleted/whatever.  If you accidentally delete a
source file, make won't complain because it won't know.

If you explicitly list the files, it ensures the dependencies will be
correct.  You want the build to be /consistent/, and globbing does not
guaruantee consistency.  The build should be identical on my machine,
all my co-developers' machines and my users machines, whatever
temporary files, copied files etc. are in the source tree, and
whatever they deleted, either accidentally or on purpose.  In these
cases a list certainly isn't fragile, and is much more dependable than
globbing.

Having to keep the Makefile.am up-to-date is a very small price to pay
for consistency.

That's not to say globbing is never useful; it certainly is.  However,
it does cause more problems than it solves.  Try working out why
$random_user's build is failing when you can't predict what is
actually happening.


Regards,
Roger

-- 
Roger Leigh
Liberty and Livelihood - Support the Countryside Alliance
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers

Re: proposal to fork the build-tools projects

[Tom Lord]

   Globbing can inadvertently lead to unwanted files being
   compiled/distributed/deleted/whatever.  If you accidentally
   delete a source file, make won't complain because it won't
   know.

I've played around a bit with an approach to globbing that solves (in
some sense) both problems you've cited.

Builds work by globbing.  Thus, while I'm engaged in heavy program
editting (e.g. directory restructuring, code factoring), I just use a
nice directory editor and change the source tree freely, not having to
worry about updating makefiles.

At the same time, I can periodically take an inventory of the tree
and compare that to a canonical inventory -- which tells me what
renames have taken place and what files have been added and deleted.

With that approach, I'm _stil_ maintaining an explicit list of files,
but with a few advantages:

1) It's a separate task from Makefile maintenance: it doesn't
   slow down the edit/compile/debug cycle.

2) There is automation to assist building and checking the 
   inventory list.



-t