[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Autotools build system

From: David Fang
Subject: Re: [Gnucap-devel] Autotools build system
Date: Sat, 18 Jul 2009 16:21:08 -0400 (EDT)

(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-

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 Fang

reply via email to

[Prev in Thread] Current Thread [Next in Thread]