[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 2 Aug 2009 19:44:14 +0200
I had no time to reply to all the mails thus ... please have patience with me.
Since my free-time slot is ended even for today I'll give my agree/disagree
here at once ... be kind enough to not blame me ...
On Sunday 02 August 2009, Peter Simons wrote:
> Reuben Thomas wrote:
> > There are now far too many macros of dubious utility.
> > Special-purpose vs. general-purpose macros
> Yes, this is a useful distinction indeed. General-purpose macros like
> AX_COMPARE_VERSION lay foundations for other macros to build on, which
> means that bugs in those macros tend to affect a lot of other code. It's
> a good idea, IMHO, to put those macros under some additional scrutiny.
Let us have a regression test suite in place, that would ease the job a lot.
See comments and patch in the other thread.
I think that it would be better to have the regression test suite up and
running before beginning the hack-and-slash fest ...
> > 1. Separate the macros into two groups, those which are
> > single-purpose (broadly speaking, those which don't take arguments),
> > and those which are general purpose. This makes the search problem
> > easier.
> Yes, this is a good idea. When someone looks for a way to detect Python,
> she'll just enter the terms "python autoconf macro" into Google, and
> that will quickly lead her to the right place. You cannot easily find
> AX_COMPARE_VERSION or AX_PREFIX_CONFIG_H that way, though, because there
> aren't any obvious keywords that describe the macro's purpose. These
> general-purpose macros would benefit greatly from an categorization
We should tag the macros then transform the tags into html lines (something
like '# USE: generic, perl' -> generic and perl could be use to generate a
better line in the html pages that will be later indexed by the
Groups aren't orthogonal thus the tagging approach could come handy for the
> > 2. Be more demanding when new general-purpose macros are submitted:
> > are they necessary? can the functionality be added to an existing
> > macro? For special-purpose macros: why is a special-purpose macro
> > needed? What's the audience?
> I completely agree. IMHO, the central issues here are time and effort.
> Someone has to make those decisions about new submissions in a timely
> fashion. It would help a lot if we'd have some document that describes
> our expectations.
We could accept even macros that seems not so necessary and funnel them later
in a more generic macro and some one-liner examples (the way I did for
AX_PATH_GENERIC, AX_LIB_CURL and AX_LIB_TAGLIB).
Without AC_LIB_CURL and AX_LIB_TAGLIB I couldn't have the idea of merging them
into AX_PATH_GENERIC, AX_LIB_CURL, AX_LIB_TAGLIB.
> > 3. Refactoring. There are quite a few macros whose functionality
> > overlap (I'm working on one of these too) and others that are very
> > thin wrappers, like all the acltx_prog_* and acltx_package_* macros,
> > which look as though they ought to be compressed into single macros,
> > perhaps, in the case of acltx_prog_*, a macro which knows a list of
> > binary names to try for each of a list of program names (associative
> > arrays in m4?). For acltx_package_*, it's far from obvious to me why
> > kpathsea is not used to find package files.
> You are right. IMHO, there are two sides to this issue that need to be
> weighed and balanced. A macro like AX_WITH_PERL is trivial, if you know
> about AX_WITH_PROG. However, a lot of people don't know about
> AX_WITH_PROG. For them, AX_WITH_PERL is useful because that macro is
> fairly easy to find.
> I feel that we can delete macros like AX_WITH_PERL (or most of the LaTeX
> macros, for that matter), if we ensure that the underlying
> general-purpose macros are easy to find and easy to use.
I wouldn't agree completely even if we find a way to ease the use of base
There are two kind of users out there IMHO:
1) Those who are leveraged enough to use the macros the way they like, hacking
and composing them without problems
2) The others who use autoconf with mere copy and paste, to get their task
Those one liners come handy in the latter case, even if they are apparently of
scarce use for us.
There are stupid one-liners (AX_WITH_PERL, AX_WITH_PYTHON, AX_WITH_...) and
less stupid one-liners (AX_LIB_CURL, AX_LIB_TAGLIB). I wrote them all for
different purposes (as testing framework, as replacement etc.).
But ... do you think that all autoconf users are shell-gurus capable of
tracking macros error, quoting sed expression the right way, hacking macros
or even using autotools the right way ? I see in the #gnu IRC channel people
asking for aclocal/autoconf problems the whole day...
Would be better for them to have examples, in order to teach them to use other
> > I feel like we need this documentation in place *before* we begin a
> > mark-and-sweep of the macros, as the rename is a perfect time to
> > change the interface.
> Maybe we can combine those tasks? Good submission guidelines would stem
> from real-life experience. As it happens, we have that real-life
> experience in the form of 500+ macros in our repository. We could go
> through those macros, review them, and write down all problems and
> inconsistencies that we discover. The resulting list would probably be a
> great step into the direction that we want go.
We should bring the different opened threads to completion too (with working
> Generally speaking, I think it's fine to perform all kinds of wild
> changes in the Git repository. It's okay for our users to expect stable
> *releases*, but they shouldn't expect that from the 'master' branch.
> The notion of renaming files and breaking interfaces doesn't bother me at
> all. We can do all that, we just need to clean up a little before
> compiling a release tarball. ;-)
Since we don't have a versioning in place at the moment (see the serial line
thread) I would like to change an API only if the involved macro has to be
We could do more harm than good the other way.
> > Perhaps Peter should make the first cut and then we can adjust?
> I can try to provide a starting point based on my experiences so far. I
> won't be able to do that quickly though, so if someone else would like
> to work on that subject, please go right ahead. The README-maint file
> feels like a good place to keep preliminary documentation, and so does
> the autoconf-archive.texi file in 'maint'. Frankly, a plain ASCII text
> that's posted to this mailing list is fine too. We shouldn't worry about
> formatting etc. right now, the contents of the submissions guidelines is
> more important than the presentation.
I agree completly.
Have a good day,
Brain fried -- Core dumped