Re: Fwd: [Bug 347095] installing m4 macros that break random packages
Thank you, Ralf and Mike Frysinger, On 12/07/10 11:28, Ralf Wildenhues wrote: > Finding out why some macro was installed usually requires looking at > aclocal --verbose [OPTIONS...] > > output. See also 'info Automake "Invoking aclocal"'. I looked into the top level Makefile: aclocal_DATA = config/ag_macros.m4 config/extensions.m4 config/libopts.m4 \ config/liboptschk.m4 config/snprintfv.m4 config/unlocked-io.m4 [...] Looks like I confused "DIST" with "DATA" and I missed it. I wrote the original line many years ago and tweaked it inappropriately. Thank you. Everything is better now. > i'd test it, but the .texi file that comes with autogen-5.11.1 is > causing my automake to error out: >> doc/Makefile.am: `doc/autogen.texi' missing @setfilename Only automake complains. The texi tools are happy. The automake macros make the erroneous assumption that all texi docs are hand crafted and must, perforce, have the layout that the macros expect -- even if the tools do not have such a requirement. It has been some years since I jiggered this around, but I'll figure out how to migrate the @setfilename line from the agdoc.texi file into autogen.texi. Thank you. Regards, Bruce ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Fwd: [Bug 347095] installing m4 macros that break random packages
On Tuesday, December 07, 2010 13:56:35 Bruce Korb wrote: > Thank you. automake list folks -- the main question is > "Why are .m4 files being installed and how can I prevent it?" because your top level Makefile.am is using: aclocal_DATA = ... when i think you should be using: noinst_DATA = ... (obviously the ones you mean to install should remain in aclocal_DATA) i'd test it, but the .texi file that comes with autogen-5.11.1 is causing my automake to error out: doc/Makefile.am: `doc/autogen.texi' missing @setfilename -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Fwd: [Bug 347095] installing m4 macros that break random packages
* Eric Blake wrote on Tue, Dec 07, 2010 at 06:49:41PM CET: > On 12/07/2010 10:39 AM, Bruce Korb wrote: > > > 3. If not, where's the magic for suppressing the installation? > > I'm not sure where the magic for installing it was located in the first > place; can you track down why extensions.m4 was being installed? (and > that may be more of an automake question) Finding out why some macro was installed usually requires looking at aclocal --verbose [OPTIONS...] output. See also 'info Automake "Invoking aclocal"'. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Fwd: [Bug 347095] installing m4 macros that break random packages
Hi Eric, Thank you. automake list folks -- the main question is "Why are .m4 files being installed and how can I prevent it?" >> Original Message >> > Subject: [Bug 347095] sys-devel/autogen installs colliding \ >> > m4 macros which break random packages >> > >> > Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=347095 >> > Secure: https://bugs.gentoo.org/show_bug.cgi?id=347095 > In this comment: >> > http://bugs.gentoo.org/show_bug.cgi?id=347095#c29 On 12/07/10 09:49, Eric Blake wrote: > Which macro are you using? Can you show the .m4 file that you are > installing as part of your public interface to autogen that is depending > on extensions.m4 under the hood? The m4 cruft I am using for configuring autogen uses extensions.m4. I do not deliberately install those macros. In fact: >> So, the questions: >> >> 1. Should these m4 files be installed? I did not believe that autogen configury macros should be installed in the first place. > Probably not - since extensions.m4 is not providing a public m4 macro > directly related to autogen, you are probably better off rewriting your > public macro to work without having to rely on extensions.m4. I do not really have public macros. (Should I have? To what end? Mostly, any client project that builds using autogen probably should not be. They probably ought to do the autogen-ing in a bootstrap phase. But if not, then just see if ``autogen --help'' works and they ought not need an m4 macro for a test that simple.) The public macro I _do_ intentionally install, I install to /usr/share/autogen and is for the purpose of testing the existence and version of libopts, and for allowing the location to be specified with a configure program option. It is "autoopts.m4" and Gentoo folks are not complaining of it. >> 3. If not, where's the magic for suppressing the installation? > > I'm not sure where the magic for installing it was located in the first > place; can you track down why extensions.m4 was being installed? (and > that may be more of an automake question) I spent some time looking at all my Makefile.am's and I am sure I don't know where the magic is, either. As far as I understand, of these files: > $ (cd ~/tmp/_I ; find * -type f|fgrep m4) > usr/local/share/autogen/autoopts.m4 > usr/local/share/aclocal/extensions.m4 > usr/local/share/aclocal/ag_macros.m4 > usr/local/share/aclocal/liboptschk.m4 > usr/local/share/aclocal/autoopts.m4 > usr/local/share/aclocal/snprintfv.m4 > usr/local/share/aclocal/unlocked-io.m4 > usr/local/share/aclocal/libopts.m4 I only mean to install the very first file. The rest are private and publicly installed via implicit means that I do not understand. Here are the macros I use that pull other stuff: > AC_INIT([GNU AutoGen],[5.11.4pre6],[autogen-us...@lists.sourceforge.net]) > AC_CONFIG_SRCDIR(agen5/autogen.c) > AC_CONFIG_AUX_DIR(config) > AC_CANONICAL_TARGET > AM_INIT_AUTOMAKE([gnu check-news 1.5 dist-bzip2]) > AC_USE_SYSTEM_EXTENSIONS > AC_LIBTOOL_WIN32_DLLm4_define(AC_PROVIDE_AC_LIBTOOL_WIN32_DLL) > AC_PROG_LIBTOOL > AM_WITH_DMALLOC > AM_PROG_CC_C_O > AC_PROG_CC_STDC > gl_FUNC_GLIBC_UNLOCKED_IO > AC_EXEEXT > AC_PROG_INSTALL > AC_PROG_LIBTOOL > AC_CHECK_PROG(TEXI2HTML, texi2html, texi2html, :) > AC_C_CONST > AC_C_INLINE > AC_CHECK_LIB(dl, dlopen) > AC_TYPE_MODE_T > AC_TYPE_PID_T > AC_TYPE_SIZE_T > AC_TYPE_UID_T > AC_C_LONG_DOUBLE > AC_CHECK_TYPES([u_int, long long, uintmax_t, size_t, wchar_t]) > AC_CHECK_SIZEOF(char*, 4) > AC_CHECK_SIZEOF(int, 4) > AC_CHECK_SIZEOF(long, 4) > AC_CHECK_SIZEOF(short, 2) > AC_CHECK_FUNCS(strchr strlcpy snprintf dlopen) > AC_SEARCH_LIBS(copysign, [m], >[AC_DEFINE(HAVE_COPYSIGN, 1, > [Define to 1 if you have the `copysign' > function.])]) > AC_SEARCH_LIBS(copysignl, [m], >[AC_DEFINE(HAVE_COPYSIGNL, 1, > [Define to 1 if you have the `copysignl' > function.])]) > AC_SEARCH_LIBS(modfl, [m], >[AC_DEFINE(HAVE_MODFL, 1, > [Define to 1 if you have the `modfl' function.])]) > AM_CONDITIONAL([NEED_PATHFIND], [test X$ac_cv_func_pathfind = Xyes]) The interesting "pullers of other stuff" are likely "AC_USE_SYSTEM_EXTENSIONS" and "gl_FUNC_GLIBC_UNLOCKED_IO". Nowhere that I have found have I set any magic make macro with 'DATA' in its name to any of the .m4 files. So I do not know how they get installed. I don't want 'em installed. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Fwd: [Bug 347095] installing m4 macros that break random packages
On 12/07/2010 10:39 AM, Bruce Korb wrote: >> these files make no sense ... they're coming from gnulib (which should never >> be >> installed) or libopts (which is a package all by itself) or colliding with >> standard autoconf macros: >> /usr/share/aclocal/unlocked-io.m4 >> /usr/share/aclocal/extensions.m4 >> /usr/share/aclocal/libopts.m4 > > But this is not my file -- it gets rolled up into the tarball because > I use a macro that it contains. Which macro are you using? Can you show the .m4 file that you are installing as part of your public interface to autogen that is depending on extensions.m4 under the hood? > So, the questions: > > 1. Should these m4 files be installed? Probably not - since extensions.m4 is not providing a public m4 macro directly related to autogen, you are probably better off rewriting your public macro to work without having to rely on extensions.m4. > 2. If so, why and how can the reported conflicts be averted? The gentoo bug had appropriate comments - you should not be installing a macro that overrides an upstream autoconf macro unless you also take care to only do the override for versions of upstream autoconf where the override is necessary (that is, conditionally define the override only in the case where it is not already provided by autoconf). > 3. If not, where's the magic for suppressing the installation? I'm not sure where the magic for installing it was located in the first place; can you track down why extensions.m4 was being installed? (and that may be more of an automake question) -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
