Re: [Gnucap-devel] autoconf-WIP branch

[Felix Salfelder]

Hi Al.

dont have time right now to complete it (otherwise i'd already done) let
me comment shortly.

On Fri, Jul 19, 2013 at 09:16:51AM -0400, al davis wrote:
> My original intent was to put back autoconf when it works, but 
> still keep the "old" system as an alternative.  I would like to 
> be able to offer Cmake too.

in the autotools-WIP branch, i have moved the static configure script
aside. i think thats bad. if both systems are supposed to work, we
probably should call them configure.static and confiugure.gnu (or
whatever else, but mutually different).

> I still have issues with the complexity and clutter of 
> autotools, which is why don't want to make it the only way.

the more options, the better.

> 1. Is there a way to hide the clutter?  Files like config.guess, 
> depcomp, ....  These really shouldn't be up front where they are 
> the first thing people see.  Can this stuff be in a subdir 
> "autoconf-generated-files"?

until now, i haven't found anything. apparently nobody else cares.
since i'm short on time right now, i'd prefer to make it work and change
aesthetic aspects later.

> 2. It does lots of tests that seem irrelevant, to the extent 
> that if something really is wrong it will often be buried by the 
> clutter.  I don't see any place where those tests were 
> requested.  It seems that autotools ALWAYS does this, 
> everywhere.  It checks for C headers that gnucap doesn't use, 
> and doesn't check for the C++ headers that gnucap does use.  
> What really bothers me about this is that I could not find where 
> such tests were requested.

yes, there are a lot of tests, none of which looks extremely
superfluous... but i can have a look, can you suggest a test to start?

if it should check for c++ headers that it currently doesnt, maybe
"autoscan" can help. autoscan reads throught the source code and
(nondestructively) writes out everything that might be useful (to
configure.scan iirc).

> 3. The essense of the "old" system, which predates autoconf and 
> was never intended as a complete system, is a 3-part Makefile, 
> that splits the program specific part (Make1), the requested 
> (generated in this case) configuration (Make2), and a part that 
> is always the same (Make3).  An equivalent of "configure" would 
> generate Make2 and cat the 3 parts.  Autotools seems to scramble 
> it into an unreadable mess.  How about using autotools to 
> generate Make2, and allowing a Make1 to be used without 
> processing?  This would allow users to configure the apps, and 
> provide a base for compiling plugins.

automake written makefiles are not meant to be edited. they are not
meant to be even looked at. configuration should be done by configure.

mixing up static and generated makefiles will make things worse. look at
the half-converted (half-static) build systems for gnucap-bsim,
gnucap-spice3f...

> 4. The file configure.am makes reference to specific external 
> plugins.  This is a violation of a basic design goal of the 
> plugin system.

no, it makes references to external *packages*. this is just convenience
for building all in one go. the external packages i have created/adapted
also work standalone and without that mechanism (but yes, i can remove
it, if you insist).

> 5. Some other programs that use autoconf have managed to tame 
> some of the compile time clutter.  Can (should) we do that too?

what exactly do you mean by this?

> But we need to go with it in such a way that we are not bound to it.

some things are a pain to do with static Makefiles/Cmake/whateverelse.
but that doesn't mean autotools is a requirement. i'd like to focus on
the user, who will never have to mess with the internals.

regards
felix