[Top][All Lists]

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

Re: Site Macro Directory

From: Akim Demaille
Subject: Re: Site Macro Directory
Date: 25 Jul 2002 13:03:13 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

| After considering this for a few days, I think the current behavior is
| actually better.  The current behavior is that each language has its
| own environment variable and its own site macro subdirectory:
|  ------------------------------------------------------------------------
|  autoconf   AC_MACRO_PATH       ${datadir}/autoconf/site_macros/autoconf
|  autotest   AT_MACRO_PATH       ${datadir}/autoconf/site_macros/autotest
|  m4sugar    M4SUGAR_MACRO_PATH  ${datadir}/autoconf/site_macros/m4sugar
|  m4sh     M4SH_MACRO_PATH     ${datadir}/autoconf/site_macros/m4sh
| This setup accomplishes your goal of making sure that people put files
| in the proper place.  However, it has two advantages:
|  * It's more convenient for Autoconf users, because they can say
|    `m4_include([foo.m4])' instead of `m4_include([autoconf/foo.m4])'.

When maintaining Autoconf, maintainability seems much more important
than convenience.  In particular, Autoconf has always suffered from
underestimating what the future will be like.  Henceforth, I much
prefer the other scheme for being more open.

As far as convenience could be an issue, I insist on the fact that
syntactic sugar can be introduced (AC_INCLUDE).

|  * It's more intuitive for Autoconf users to use AC_MACRO_PATH than to
|    use AUTOM4TE_PATH.  Remember that autom4te runs behind the scenes,
|    and most Autoconf users probably don't know it's there.

More intuitive, I agree with that.  Guessable, no.  Therefore, since
in any case reading the doc will be required, I see no strong

| Given this, I think it makes more sense to keep it the way it is.
| What do you think?

I'm still in favor of the scheme I suggested.

reply via email to

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