Re: TODO patch

[Akim Demaille]

>>>>> "Lars" == Lars J Aas <address@hidden> writes:

Lars> Do I need a ChangeLog entry when applying the below patch, and
Lars> do I need approval for a TODO-file patch?

No, good ahead.
 
Lars> +* autoconf.texi +Move the specific macro documentation blocks
Lars> into the source files, and use +a doc-block extraction/merge
Lars> technique to get docuemntation into texi-file. 

This is known: AD_ + traces.  Traces were introduced for this.

FYI, when there was an experimental branch of Autoconf (spoops =
specializing loops).

------------------------------------------------------------

From: Akim Demaille <address@hidden>
Subject: Re: Matt's TODO/wish list for the 2.15 release
To: "Matthew D. Langston" <address@hidden>
Cc: Autoconf Maintainers <address@hidden>
X-Sent: 1 year, 33 weeks, 1 day, 17 hours, 2 minutes, 7 seconds ago

>>>>> "Matthew" == Matthew D Langston <address@hidden> writes:

Matthew> FYI, I am also desperately trying to get my Ph.D. thesis
Matthew> finished and defended within the next month or two as well.

Niark niark niark :)  It's good to see people still in the troubles
you just left ;)

Matthew> 2) I think we should split up the monolithic `acgeneral.m4'
Matthew> and `acspecific.m4' files into smaller, more manageable sized
Matthew> units for 2.15.  

I agree, but for this, I think we first need a merge between the two.
In fact, I didn't know that Ben intended to merge exp. into 2.15.
There are then decisions to take before.

In fact, I would say that 2.15 should limit itself to fix *bugs*, and
not introduce new features.  New features should be thought twice
before.  For instance I'm not really happy with AC_CHECK_TYPE.  The
problem is that once we commit new interfaces we have to deal with
them.

And I believe the interface of Autoconf is not as uniform as it ought
to be.

Basically, my feeling is

1. 2.15 is a bug fix release only.  It should not introduce new
features (people already have their work arounds), and we should not
bother with all of the PR.  Only majors.  Then october is fine.

2. exp. is merged into 2.15.  Then we have to work together, merge the
two branches *often*, and take our time for a clean Autoconf.

I'm OK with both, while the problems with 2.95 make me think 1 is
better.  But pleeeeease, no new features/interfaces we have not
discussed.

Matthew>    I don't think this will be difficult.  We should just make
Matthew> a new `m4' or `lib' subdirectory (I don't care what we name
Matthew> it) , and populate it with smaller chunks from `acgeneral.m4'
Matthew> and `acspecific.m4'.  We can then just read these files with
Matthew> m4 and make the frozen files (i.e. `acgeneral.m4f' and
Matthew> `acspecific.m4f') just like before.

I'm ready to handle the split, but only once the branch are merged.
Otherwise, we won't manage it!  There are no good tools that handle
files splitting.  CVS is not even able to rename :)

Matthew> 3) Add the new (and yet to be properly implemented) Autoconf
Matthew> testsuite.  This requires that the new Automake files for
Matthew> Autoconf are in place first, so I am waiting on these.  

I agree Automakization of Autoconf should be commited quickly.

Matthew>         I've always believed that this particular case would
Matthew> best be served by Literate Programming, so that we could just
Matthew> run a tool on the macros themselves that would generate the
Matthew> Texinfo documentation for us.  However, I'm afraid that this
Matthew> will probably have to wait for Autoconf 3.0.

This is exactely what I have in mind.  In fact, there should be

AC_MACRO        the test
AH_MACRO        the config.h.in snippet
AS_MACRO        the system.h
AD_MACRO        the Texinfo snippet.

For this we need spoops, methink.

Akim

----------------------------------------------------------------------

From: akim demaille <address@hidden>
Subject: Re: Autoconf (fwd)
To: address@hidden (akim demaille)
Cc: address@hidden (Ben Elliston), address@hidden,
        address@hidden, address@hidden
X-Sent: 1 year, 23 weeks, 3 days, 19 hours, 22 minutes, 39 seconds ago

Salut Richard,

Un peu plus d'informations sur ma candidature, mon programme
pour les prochaines e'lections en quelque sorte :)

I would like to present a bit how I see the future of Autoconf, and
especially the tasks I would give myself were I the maintainer.

Autoconf is essential to the whole GNU project, in fact it *the* most 
essential part of the project, even more than GCC since that the only 
program everybody has to use (one could claim Emacs is even more, since 
there's nothing like a good Autoconf mode to work on Autoconf :).  Since it 
addresses the portability issues it is usually seen as an untouchable 
crystal, extremely fragile and vulnerable.

I don't share this opinion: as any other tool Autoconf is subject to 
improvements and I intend to have Autoconf be very lively.  This does not 
mean I will work without care, testing etc.

First of all, let me start with my definition of Autoconf: Autoconf
is before anything else a frame work for testing features.  Many
people see it as a collection of existing tests, but by no way this
is the most important part of Autoconf: the infrastructure it provides
is more important.

Currently this infrastructure has important flaws, which is what I
first want to address.

1. Autoconf is too selfish.
It does not collaborate enough with its peers, such as Automake and 
Libtool.  I intend to be in close relationship with the maintainers of both 
tools to provide them with a better ABI.  There are yet several such
improvements.

2. Autoconf requires too much knowledge on itself to be used.
I've always considered as a bug that I have to have
AC_FUNC_FNMATCH, I want to be able to say AC_REPLACE_FUNCS(fnmatch)
and have the Right Thing happen.  I know we can do it, though this
requires major changes, hence a major release Autoconf 3.
Equally, it is not normal that there is an autoscan, but no autorescan.
In fact, it is autoconf itself which should tell the maintainer that
she uses a feature which is not portable, and it should suggest the
new tests to run.

3. Autoconf is not uniform.
Autoconf 2 did bring a significant improvement over the previous
versions, nevertheless there are yet too many non motivated differences
between families of macros.  I have already provided numerous patches
to reduce the differences (same arguments and semantics for the
families AC_CHECK func, type, header etc.).
I will proceed on this track.  It turns out everybody wins from this:
the user has less exceptions to learn, the maintenance of Autoconf is
eased since a brand lot more code is shared between macros, and the 
documentation is shorter.

4. Autoconf is too monolithic.
Autoconf in itself is also too big a project, it lacks what the libc is to 
C projects.  Alexandre Oliva and others, amongst them myself, are working 
on a separate project, named Ad'HoC, which will provide a libm4, and also 
a layer of m4 macros meant for writing shell scripts.  Autoconf will use 
this framework some day.  For the time being, I am developping its libm4, 
and the readability of Autoconf itself is greatly improved thanks to this.

5. Autoconf does not automate enough subtasks.
For instance Autoconf should provide system.h.  Thanks to the 
revolutionary features required for 2., this will be possible in the 
future.  But there are many other ways we can improve other subtasks, for 
instance writing the documentation (macros should come with their 
documentation), the required files (currenly Automake knows some Autoconf 
macros and what files they require, but this design is wrong and imposed by 
the selfishness of Autoconf, in the future Autoconf will tell what are the 
files that are needed.).

I could continue on quite a few other points I have in mind, but I think 
you get the idea.  Of course I was mentioning only major changes I'd like 
to introduce in Autoconf, but there are also many bug fixes needed.

I should also say that I use my own version of Autoconf for a2ps, what 
helps me a lot knowing exactly how Autoconf behaves.  I have the intention 
to continue this way, so that Autoconf has a torture test before being 
released.  You should also know that Jim is using this version of Autoconf 
for his betas of the jim-utils, so, again, the coverage of the real scale 
tests is quite good.



It is also on purpose that I left this program scare a bit.  I could have 
soften it, but I wanted to give an exact picture of what I want from 
Autoconf as a maintainer using it, hence what I'd do if I were the Autoconf 
maintainer.  Nevertheless, I would pay special attention to compatibility 
and portability.  I would also love sharing the maintaince with other 
people, especially Alexandre Oliva, if he agrees.  On some issues we have 
opposite views, and the balance that results seems extremely positive to 
Autoconf.  We've already had the opportunity to show that in many long 
threads in Autoconf's mailing lists.

Well, that was a snippet of my program, to detail what I feel about 
Autoconf, and what would happen if I were its maintainer.

Akim