automake
[Top][All Lists]
Advanced

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

Re: FYI: summary of 1.8.0a bug fixes


From: Alexandre Duret-Lutz
Subject: Re: FYI: summary of 1.8.0a bug fixes
Date: Wed, 07 Jan 2004 08:07:07 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

>>> "Kevin" == Kevin P Fleming <address@hidden> writes:

 Kevin> Alexandre Duret-Lutz wrote:
 Kevin> (from automake-patches)

 >> +  - Honor definitions in m4_included files.  aclocal 1.8 had been
 >> +    updated to check m4_included files for new requirements, but
 >> +    forgot that these m4_included files can also provide new
 >> +    definitions.
 >> +
 >> +    This principally affected packages that were m4_including files in
 >> +    a way that aclocal would not have to duplicate entire M4 files
 >> +    into aclocal.m4.  Since aclocal 1.8.x will precisely output
 >> +    m4_includes for local M4 files, we recommend that you clean up
 >> +    your setup, removing all manual m4_includes and letting aclocal
 >> +    output them.

 Kevin> OK, now I'm really confused! 

I have changed that text as follows.  I hope it's clearer.
Otherwise, maybe someone could help me to write something less
confusing.

  - Fix aclocal to honor definitions located in files which have been
    m4_included manually.  aclocal 1.8 had been updated to check
    m4_included files for new requirements, but forgot that these
    m4_included files can also provide new definitions.

    Note that if you have such a setup, we recommend you get rid of
    it.  In the past, there was a reason to m4_include files manually:
    aclocal used to duplicate entire M4 files into aclocal.m4, even
    files that were distributed.  Some packages were therefore
    m4_including the distributed file directly, and playing some
    tricks to ensure aclocal would not copy that file to aclocal.m4,
    in order to limit the amount of duplication.  Since aclocal 1.8.x
    will precisely output m4_includes for local M4 files, we recommend
    that you clean up your setup, removing all manual m4_includes and
    letting aclocal output them.

 Kevin> I have a simple package, with some additional m4 macros
 Kevin> in its m4/ directory. Using automake-1.7 (and 1.8), this
 Kevin> appears to work correctly, and I'm using Paolo's
 Kevin> backport of AC_LIBTOOL_TAGS from libtool CVS so I can
 Kevin> get a smaller configure script since I'm using only C
 Kevin> (no C++, F77, etc.). This means there is an
 Kevin> ac_libtool_tags.m4 file in the m4/ directory, and this
 Kevin> also appears to work.

 Kevin> Is this still the proper way to set things up? 

Yep.

 Kevin> I see all this discussion of using m4_include, then not
 Kevin> using m4_include, 

The recommendation is not to use m4_include yourself: let
aclocal do that.

 Kevin> passing -I... to aclocal (which doesn't seem to be
 Kevin> needed in my case for some reason)...

but you need `-I m4' so that aclocal pick up definitions therein.

 Kevin> Since this appears to have changed so much since the major automake
 Kevin> documentation was written, can someone clarify the _preferred_ method
 Kevin> for including local m4 macros, especially if they need to override
 Kevin> system-supplied macros with the same names?

Exactly what you seem to do.  Put all local macros in a
subdirectory, e.g. m4/, and add `ACLOCAL_AMFLAGS = -I m4' to the
top-level Makefile.am (so that -I m4 will be passed to aclocal
when it is run from Makefile or autoreconf), and pass -I m4
to any other manual invocation of aclocal.

-- 
Alexandre Duret-Lutz





reply via email to

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