Re: [Gnucap-devel] Autotools build system

[David Fang]

> (after sitting in my drafts folder for too long)

A similarly slow reply from me...

> I consider in to be very important to control the dependencies
> of gnucap (or any program).  Specifically, the only absolute
> dependency that can be tolerated for the core is a standards-
> compliant C++ compiler with a standard library.  Even that is
> asking too much.  Every compiler has bugs and holes in its
> implementation.  So, the expectation now is the subset of the
> standard that common compilers support.
>
> Any other goodies are fine if they are not required.  If
> something else makes your job easier, go ahead and use it, but
> don't require everyone else to use it. There must be a work-
> around.
>
> I consider any deviation from this policy to be a bug.  Whether
> it is a release-critical bug is a matter of judgement, but it is
> a bug.
>
> Plugins can have more dependencies, since they are optional.
>
> For the build system, GNU has a document specifying a set of
> programs that can be used in the build process.  Ironically, it
> seems to be designed around autotools, but autotools itself does
> not comply with the policy.

I don't see anything wrong with a set of tools having more requirements 
during use (say, by developers) than its products which are distributed to 
end-users.  To require the absolute minimum during development is just 
crippling oneself unnecessarily.  Tools like perl and m4 used by the 
autotools aren't needed by the end users of the autotools (thank 
goodness!), that isolation is a good thing, IMHO.  For example, one common 
practice is for developers to use lex/yacc to create interpreters, but 
ship the generated C sources so they are ready-to-compile out of the box, 
without requiring users to have lex/yacc. If you forbid lex/yacc during 
development, the alternative is to hand-write your own lexer/parser, time 
and effort that can be saved.  I can't even imagine hand-writing a good 
configure script, and the cost of maintaining one.  We save a lot of 
effort by letting autoconf generate a Bourne-shell script (using whatever 
tools it wants).  If you agree on the minimality of the requirements for 
the end-user (that autotools produces satisfy them), then the choice of 
developer tools just depends on what we consider are reasonable 
requirements for us as developers.

Oh, and I'll get back to you on the plug-in system in a separate email... 
this weekends is kind of packed again...  I'm slowly working on a 
pre-configured boilerplate Makefile suitable for sharing for plug-in 
building, not unlike the templates in your plug-in sources, but 
leveraging libtool scripts.

David

David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/