|
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- 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/
[Prev in Thread] | Current Thread | [Next in Thread] |