autoconf-archive-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Discrimination


From: Francesco Salvestrini
Subject: Re: Discrimination
Date: Sun, 2 Aug 2009 19:44:14 +0200
User-agent: KMail/1.9.10

Hi all,

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.

[SNIP]

>  > 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
> scheme.

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 
web-scrapers).

Groups aren't orthogonal thus the tagging approach could come handy for the 
task.

>  > 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 
macros (AX_WITH_PROG).

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 
done.

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

>  > 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 
solutions). 

> 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.

I agree.

> 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 
renamed too.

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.

[SNIP]

Have a good day,
Francesco

-- 
Brain fried -- Core dumped




reply via email to

[Prev in Thread] Current Thread [Next in Thread]