Re: proposal to fork the build-tools projects

[Roger Leigh <roger at whinlatter dot uklinux dot net>]

Tom Lord <lord@regexps.com> 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