[Gnucap-devel] autoconf-WIP branch

[al davis]

When it was first created, I checked it and it didn't work for 
me, but I didn't have the time to find out why and had a crisis 
on another project.

Try again ...  It works this time.  I think the failure the 
first time had something to do with stuff hanging around from 
before, but I cannot reproduce the failure, so I think it works.

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.

One side of me wants to develop the "old" system into a full 
system.  A more practical side of me says that I don't have time 
to do this.

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

Some thoughts ...

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"?

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.

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.

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

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

6. The "gnucap_default_plugins" name change threw me .. caused 
breakage that I didn't see at first.  After finding it, it's so 
minor I can't really object.  That might be why it didn't work 
the first time.



Thanks for doing the work this far.  I realize that there isn't 
really a good alternative yet, so we need to go with it.  But we 
need to go with it in such a way that we are not bound to it.