bug#19418: AC_CONFIG_FILES / stamp-h? problem
I'm afraid I can't easily tell. It looks like I added a workaround in https://github.com/open-mpi/ompi/commit/40dd4c5b766ff62a681692b1fa6b72a1023fc81f on Dec 20, 2014 (the same day that I initially filed this bug report). Half of that workaround was removed in June of 2015 when we stopped embedding a major component (https://github.com/open-mpi/ompi/commit/3e1b85ceb36d952190934e041b8894db98bb38ef); the other half persisted for several years until we changed packaging of another major component in October of 2020 (https://github.com/open-mpi/ompi/commit/0e9581d478a20b496c579c9510ea0f3d644a460d). Honestly, I think that when I put in the workaround, we forgot about the issue -- the workaround ultimately disappeared organically over time when we made other major changes to the Open MPI code base. So I can't say whether the bug ultimately got fixed in subsequent versions of Automake, whether it was fixed in Open MPI's m4 code, or whether the other major changes in Open MPI made the issue moot. -- Jeff Squyres jsquy...@cisco.com From: Mike Frysinger Sent: Sunday, February 20, 2022 11:03 PM To: Jeff Squyres (jsquyres) Cc: 19...@debbugs.gnu.org Subject: Re: AC_CONFIG_FILES / stamp-h? problem On Sat, 20 Dec 2014 15:48:49 +, Jeff Squyres (jsquyres) wrote: > I have found what appears to be a subtle bug in the Autotools, and I *think* > it may be in Automake. ...but I am not sure; it could also be a bug in our > m4 code. it's been ... a while. have you managed to track this down yourself ? or is this issue still plaguing the project ? -mike
bug#20713: aclocal/tar.m4 and solaris 5.10
i have no idea what the quoting style/preference is in the GNU world, Nothing GNU-wide, but among autotools and related packages written/maintained by approximately the same group of people, I believe test x"$foo" = x1 is the most-usual style. Though "x$foo" is common too, since it makes no difference. The "test" item, most of the way down in the "Limitations of Shell Builtins" node of the Autoconf manual, reports a lot of the things that have led to the common forms/workarounds. https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins Not including the not-quoting of constant strings though, granted, since that also makes no difference. I can't recall any other style guide for shell coding conventions, either. Anyway, back to the bug topic. i think there's merit to issuing a warning Ok, I yield. No appetite to argue further over this tiny issue. configure user can (re)create dist tarballs too. not the common flow, Quite an understatement there :). the reason your system hit this code path I was not running make dist. I was just running configure on Solaris 5.10. As far as I can recall. it can be helpful when you're hacking on a system and want to pull the state back out. Personally, I would never trust make dist not to alter the state that it was supposedly snapshotting. But whatever. --thanks, karl.
bug#20300: [PATCH] automake: allow required files to be in subdirs
* bin/automake.in: Split dir & file name back out from the constructed required file path. Looks like good work to me. Thanks. -k
bug#20713: aclocal/tar.m4 and solaris 5.10
On 22 Feb 2022 16:29, Karl Berry wrote: > The "test" item, most of the way down in the "Limitations of Shell > Builtins" node of the Autoconf manual, reports a lot of the things that > have led to the common forms/workarounds. > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins thanks, this is what i was looking for. maybe i should actually read the autotools manuals one day instead of using them purely as references. > the reason your system hit this code path > > I was not running make dist. I was just running configure on Solaris 5.10. > As far as I can recall. i'm sure that was the case (i.e. you ran configure but never dist). but if we can only test tools during configure, and the dist step requires results from that probing, but we're not allowed to probe dist-specific tools during configure, then we're in a bit of a catch-22. i'm not aware of other parts being delayed/split based on their usage. for example, if i just `make && make install`, one could argue that configure checking for deps/behaviors that only matter to `make check` are incorrect. off the top of my head, i think Automake's `missing` tool is about the only exception to this approach/rule, and even then, that's pretty thin -- it's only seeing if a specific program exists, not whether it supports specific functionality or is otherwise buggy. >it can be helpful when you're hacking on a system and want to pull >the state back out. > > Personally, I would never trust make dist not to alter the state > that it was supposedly snapshotting. to be clear, when i said "state", i meant "the source code". obviously i wouldn't expect (or want) `make dist` to pick up any intermediates or build outputs. i'm not sure along what lines your distrust of dist flows, but i will point out that this logic is entirely Automake's, so it would be a little unusable if you consider `make dist` unreliable as a maintainer of Automake :). -mike signature.asc Description: PGP signature
bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files
On 17 Feb 2022 16:33, Karl Berry wrote: > Hi Damian - thanks for the report. > > LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \ > $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \ > $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ > $(AM_CFLAGS) $(CFLAGS) > ... > `libtool` has a command line option, `-no-suppress` ... > > Well, the immediate answer would apparently be to add yet another > variable after the --mode=compile, say LTMODEOPTS for the sake of > argument (have to think about the name), so the output is > > LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \ > $(LIBTOOLFLAGS) --mode=compile $(LTMODEOPTS) $(CC) ... to clarify, Damian isn't saying it has to be between --mode=compile & $(CC). in fact, pretty sure this doesn't work as libtool expects the argv to be the arguments right after --mode=compile. $ libtool --tag=CC --mode=compile -no-suppress gcc test.c -c -o test.o Usage: /usr/bin/libtool [OPTION]... [MODE-ARG]... Try 'libtool --help' for more information. libtool: error: unrecognised option: '-no-suppress' the right command line is: $ libtool --tag=CC --mode=compile gcc test.c -c -o test.o -no-suppress so i think we can reframe the request as: Automake offers no way of specifying flags that are only used at compile time. breaking down LTCOMPILE (for C): * $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile: doesn't help as comes before $(CC) and we need flags to be after * $(CC): used for preprocessing & compiling, and linking, and default for linking via `CCLD = $(CC)` * $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS): used for preprocessing (dep generation, etc...) and compiling * $(AM_CFLAGS) $(CFLAGS): used for preprocessing, compiling, and linking if we look at the linking phase specifically, it's possible to put libtool flags into xxx_LDFLAGS. this is good, and what we already document+recommend. my inclination is to introduce two new variables that would be used for libtool & non-libtool, and only when compiling. * xxx_COMPILE: to provide parity with existing xxx_LINK setting -- override the compiler on a per-program basis * xxx_COMPILEFLAGS: appended only to compile calls so it can override all the variables that are shared with other commands my only gripe is the lack of parity between other stages from a naming pov, but i think we just have to swallow this pill. most flags are based on the language selection rather than the phase (e.g. CFLAGS is for C language and is used for preprocessing, compiling, and linking C code). LDFLAGS is only for linking -- it's language independent. if we added xxx_LINKFLAGS, it would serve the same exact purpose as xxx_LDFLAGS, so doesn't add a whole lot of value. -mike signature.asc Description: PGP signature
bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files
On 23 Feb 2022 01:12, Mike Frysinger wrote: > my inclination is to introduce two new variables that would be used for > libtool > & non-libtool, and only when compiling. > * xxx_COMPILE: to provide parity with existing xxx_LINK setting -- override > the compiler on a per-program basis > * xxx_COMPILEFLAGS: appended only to compile calls so it can override all the > variables that are shared with other commands having glanced through the implementation a bit, i don't know that i'll try to implement this myself, at least any time soon. this is heavily in the perl side of things, and i'm not really versed in it. -mike signature.asc Description: PGP signature
