[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnucap-devel] autoconf-WIP branch
From: |
al davis |
Subject: |
[Gnucap-devel] autoconf-WIP branch |
Date: |
Fri, 19 Jul 2013 09:16:51 -0400 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
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.