bug#70410: Fwd: [PATCH] gotools: Workaround non-reproduceability of automake

On 2024-04-17 11:55, Karl Berry wrote: > so whether it is > @NATIVE_FALSE@install-exec-local: > @NATIVE_FALSE@uninstall-local: > or > @NATIVE_FALSE@uninstall-local: > @NATIVE_FALSE@install-exec-local: > depends on some hash table traversal or what. > > Thanks for the

Re: Getting long SOURCES lines with subdirs shorter

On 2023-12-01 15:37, Jan Engelhardt wrote: > On Friday 2023-12-01 21:13, Mike Frysinger wrote: >> On 17 Jul 2023 16:51, Karl Berry wrote: >>> Hi Jan, >>> >>> Current automake likely won't have anything in store already, >>> >>> Not that I know of. >>> >>> a_SOURCES = $(addprefix

bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get

[bug#67516] [PATCH] aclocal: handle both # and dnl for serial number lines

On 2023-11-28 16:06, Karl Berry wrote: > Hi Ross - you sent a change to automake-patches back in February 2017. > Sorry for the absurdly delayed reply. > > https://lists.gnu.org/archive/html/automake-patches/2017-02/msg1.html > > Instead of only accepting comment lines that start

Re: Detect --disable-dependency-tracking in Makefile.am

On 2023-09-30, Nick Bowler wrote: > Two suggestions, one relying on Automake internals and one not: > > Suggestion 1) > internal ... Automake conditional called AMDEP. [...] > Suggestion 2) [...] > AM_CONDITIONAL([NO_DEPS], [test x"$enable_dependency_trac

Re: Detect --disable-dependency-tracking in Makefile.am

On 2023-09-29, Dave Hart wrote: > I'm guessing someone has trod this ground before. I'd appreciate > pointers to examples of how others have detected > --disable-dependency-tracking to change their build behavior. Two suggestions, one relying on Automake internals and one not: Suggestion 1) It

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

On 31/08/2023, Karl Berry wrote: > Hi Bogdan, > > In reference to: > https://lists.gnu.org/archive/html/automake/2023-07/msg7.html. > > Thanks much! > > Since it's Autoconf 2.70 that started using the parameter, I've > bumped the required value. > > I don't think we should

bug#64743: Speed up GNU make's internal processing

On 20/07/2023, Bruno Haible wrote: > Karl Berry wrote: >> I just hope those weird-looking %:: rules do not cause trouble with >> other makes. I guess we'll find out. > > I tested the default 'make' of various OSes, before submitting the patch. > Whether some other, rarely-used 'make'

bug#19614: Split packaging invocation to catch errors

On 2023-07-17, Karl Berry wrote: > Hi Dimitrios, Bogdan - back on this bug from 2015 (sorry): > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19614 > > Bogdan sent a patch that splits the tar and compress into separate > invocations. It seems basically good to me, but the dist-formats test >

Re: if vs. ifdef in Makefile.am

On 2023-03-01, Jan Engelhardt wrote: > You can utilize the same mechanism behind automake's `make V=1`: > > NDEBUG = 0 > my_CPPFLAGS_0 = > my_CPPFLAGS_1 = -NDEBUG > my_CFLAGS_0 = -O3 > my_CFLAGS_1 = > AM_CPPFLAGS = ${my_CPPFLAGS_${NDEBUG}} > AM_CFLAGS = ${my_CFLAGS_${NDEBUG}} This syntax is not

Re: rhel8 test failure confirmation?

On 2023-03-01, Karl Berry wrote: > Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky > Linux, original RHEL, or even (sort of) CentOS 8? It would be nice if > someone could run a make check there (from automake dev). > git clone -q git://git.savannah.gnu.org/automake.git >

bug#61278: Automake warns about LDFLAGS for defined library

On 2023-02-04, Reuben Thomas via Bug reports for Automake wrote: > When automake is run, it warns: > > liba2ps/Makefile.am:63: warning: variable 'libnowarnings_a_LDFLAGS' is > defined but no program or > liba2ps/Makefile.am:63: library has 'libnowarnings_a' as canonical name > (possible typo) > >

[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution

On 14/01/2023, Zack Weinberg wrote: > On Sat, Jan 14, 2023, at 7:18 PM, Mike Frysinger wrote: >> Rather than assume such coarse delays, re-use existing logic for >> probing the current filesystem resolution. This speeds up the >> testsuite significantly.> [...] > No objection to this patch in

bug#55025: Automake should allow one to enable POSIX make behavior

On 14/01/2023, Mike Frysinger wrote: [...] >> I tried several other implementations and they follow the POSIX >> behaviour by default, adding -e only when errors are not suppressed. > > this is exactly my point. if i'm developing a project with automake > and i'm using gnu make, i can easily

bug#55025: Automake should allow one to enable POSIX make behavior

On 2023-01-13, Mike Frysinger wrote: > On 13 Jan 2023 16:01, Karl Berry wrote: >> I am doubtful about blithely defining .POSIX unconditionally. I feel >> sure that will break existing Makefiles. I don't think we should do that. >> >> Detecting .POSIX in an existing Makefile.am and moving it to

bug#60607: Making dvi target do nothing

On 2023-01-06, Reuben Thomas via Bug reports for Automake wrote: > I'm using automake 1.16.5. The advice about how to disable the "dvi" > target doesn't seem to work. > > In the manual it says: > >To make ‘dvi’ into a do-nothing target, see the example for > ‘EMPTY_AUTOMAKE_TARGETS’ in *note

[bug#60535] [PATCH] depend2: switch echo|sed to automatic vars

On 2023-01-04, Mike Frysinger wrote: [...] > dmake is one implementation that fails, and your suggestion doesn't work > :/. > $ dmake foo/bar.o > dmake: Error: -- Incomplete macro expression [)' b='$(at_f:.o=)'; test > x"$$a.o" = x"$(@F)" || a=$$b;\ > echo $$a] It might also be

[bug#60535] [PATCH] depend2: switch echo|sed to automatic vars

On 2023-01-04, Mike Frysinger wrote: > On 04 Jan 2023 21:10, Nick Bowler wrote: [...] >> maybe something like: >> >> % cat >Makefile <<'EOF' >> at_f = $(@F) >> foo/bar.o: >> a='$(@F:.o=)' b='$(at_f:.o=)'; test x"$$a.o" = x"$(@F

[bug#60535] [PATCH] depend2: switch echo|sed to automatic vars

On 2023-01-03, Mike Frysinger wrote: > The echo|sed is used to split the dirname & filename so it can insert > $(DEPDIR) in the middle, and then chop the trailing object suffix. In > the generic case, %OBJ% is $@, so we can leverage the POSIX vars $(@D) > and $(@F) to do the pathname splitting

Re: Old .Po file references old directory, how to start fresh?

On 2022-08-04, Travis Pressler via Discussion list for automake wrote: > I'm learning how to make an autotools project and have created a test > project to work with. I ran make with a directory `nested` and then deleted > it and deleted the reference to it in my `Makefile.am`. > > Now I'm

Re: Problem with build

Hi, On 2022-08-01, aotto wrote: > but in ONE library I dont want to have a static library build because it > is only used as dlopen (by tcl)… [...] > pkglib_LTLIBRARIES = libtclmkkernel.la [...] > question what I have to-do to avoid a "static" library "libtclmkkernel.a" Since this seems to be a

Re: How to speed up 'automake'

On 2022-05-02, Karl Berry wrote: > - @echo '# dummy' >$@-t && $(am__mv) $@-t $@ > + @: >>$@ > > 1) does it actually speed anything up? The answer seems to be a resounding "yes". I tried one of my packages on an old slow PC, and changing this one line in Makefile.in cuts almost 5 seconds

bug#53780: Automake failing with conditional AC_CONFIG_FILES

On 2022-02-20, Mike Frysinger wrote: > can you link to the project/source ? the snippet you posted isn't > complete, and adding a few more lines doesn't cause automake crash for me. Here is a minimal reproducer: % cat >configure.ac <<'EOF' AC_INIT([test], [0]) AM_INIT_AUTOMAKE([foreign])

Re: portability of xargs

On 2022-02-14, Mike Frysinger wrote: > context: https://bugs.gnu.org/53340 > > how portable is xargs ? like, beyond POSIX, as autoconf & automake both > support non-POSIX compliant systems. i want to use it in its simplest > form: `echo $var | xargs rm -f`. As far as I can tell xargs was

bug#53780: Automake failing with conditional AC_CONFIG_FILES

On 2022-02-04, Valio Valtokari wrote: > Hello, > > I have a project that supports multiple platforms (windows and linux as of > right now). To implement testing functionality I use a library that I > haven't configured for windows in my project yet. As such, my configure.ac > has these lines: > >

Re: adding a command line option for ACLOCAL_PATH-type search paths

On 19/01/2022, Mike Frysinger wrote: > the ACLOCAL_PATH functionality is useful (adding search dirs after -I), > but a bit unwieldy as an env var. any reason we can't add a command line > option for this ? call it --aclocal-path ? or --extra-system-acdir ? > or some other other boring name ? >

Re: Automake for RISC-V

On 20/11/2021, Billa Surendra wrote: > I have RISC-V native compiler on target image, but when I am compiling > automake on target image it needs automake on target. This is the main > problem. Automake should not be required to install automake if you are using a released version and have not

Re: Automake for RISC-V

Hi Billa, On 18/11/2021, Billa Surendra wrote: > Dear All, > > I have cross-compiled Automake-1.16.2 package with RISC-V cross compiler, > but when I am executing binaries on RISC-V target OS image its gives errors > like "not found". Automake is written in Perl so it does not really get

Re: `make dist` fails with current git

On 2021-10-13, Zack Weinberg wrote: > On Wed, Oct 13, 2021, at 2:11 PM, Nick Bowler wrote: >> I think this happened because your CI system has done a shallow clone. >> So the changelog generation failed because the git log is incomplete. > > I did a --single-branch clone,

Re: `make dist` fails with current git

On 13/10/2021, Zack Weinberg wrote: > On Wed, Oct 13, 2021, at 11:54 AM, Bob Friesenhahn wrote: >> On Wed, 13 Oct 2021, Zack Weinberg wrote: >>> >>> Looks like some kind of problem with automatic ChangeLog generation? >> >> To me this appears to be the result of skipping an important step in >>

Re: generated lex/yacc sources?

On 21/09/2021, Karl Berry wrote: > Suppose I want to generate a lex or yacc input file from another file, > e.g., a CWEB literate program. Is there a way to tell Automake about > this so that the ultimately-generated parser/lexer [.ch] files are saved > in srcdir, as happens when [.ly] are direct

bug#49901: Bug in build c-ares [too many loops]

On 17/08/2021, Brad House via Bug reports for Automake wrote: > This ended up being the fix to needing to run autoreconf -fi multiple > times: > https://github.com/c-ares/c-ares/commit/e73fb47 Probably an OK workaround. I suspect the effect of this change is to get aclocal to pull in the

bug#49901: Bug in build c-ares [too many loops]

On 17/08/2021, Brad House via Bug reports for Automake wrote: > On 8/17/21 1:06 PM, Nick Bowler wrote: >> On 2021-08-17, Brad House via Bug reports for Automake >> wrote: >>> I'm one of the maintainers of the c-ares project at >>> https://github.com/c-ares/c-ar

bug#49901: Bug in build c-ares [too many loops]

On 2021-08-17, Brad House via Bug reports for Automake wrote: > I'm one of the maintainers of the c-ares project at > https://github.com/c-ares/c-ares and have had a couple of users report > this issue. I took a quick glance and I found this:

[RFC PATCH] Improve diagnostics wrt. mutliple AM_INIT_AUTOMAKE calls.

If you expand AM_INIT_AUTOMAKE more than once with options, automake currently barfs on the resulting m4 traces with a less-than-helpful assertion failure ("global options already processed"). This also prompts users to report bugs against Automake, when the actual problem is with their autoconf

bug#50046: Probably a bug

On 2021-08-15, Karl Berry wrote: > two expansions of AM_INIT_AUTOMAKE in your configure.ac. > ... > diagnostic message was certainly not very useful! > > Fully agreed. > > Nick, any chance you could easily write a patch to generate a decent > error message for this? I am tied up with

bug#50046: Probably a bug

On 2021-08-14, José Hipólito Moyano wrote: > I attached the project files in the email. Maybe they were filtered :-) > Here they go again (maybe the C code won't compile XD, I was just > starting) [...] >> automake: error: global options already processed Your error is presumably caused by

Re: How to prevent distribution of `texinfo.tex`

On 2021-06-23, Werner LEMBERG wrote: Yeah, it would be nice to have a means to control that. >> >> Yes it is really not a good solution in this case. The file is >> detected at "automake" time and the rule to distribute texinfo.tex >> is baked into the generated Makefile.in. That then gets

Re: How to prevent distribution of `texinfo.tex`

On 23/06/2021, Peter Johansson wrote: > > On 24/6/21 3:02 am, Werner LEMBERG wrote: >>> As far as I know there is no way to disable this behaviour, although >>> I agree the automagic file inclusion can be a bit funky. >> Yeah, it would be nice to have a means to control that. > > There is the

Re: How to prevent distribution of `texinfo.tex`

On 2021-06-23, Werner LEMBERG wrote: > The file `texinfo.tex` is in the list of files (given by `automake > --help`) that gets always distributed. How can I disable this? I > don't have texinfo documentation. The texinfo.tex file (and others listed along with it) is included in the

Re: parallel build issues

On 2021-06-21, Werner LEMBERG wrote: > >> The problem is not related to the snippet you posted. The >> concurrent recursive make invocations are being spawned from >> somewhere else in your build system. > > The `Makefile.am` file one level higher is as follows. > > ACLOCAL_AMFLAGS = -I

Re: parallel build issues

On 2021-06-21, Warren Young wrote: > On Jun 21, 2021, at 11:49 AM, Werner LEMBERG wrote: >> >> bin_PROGRAMS += ttfautohintGUI > > Is Automake smart enough to realize what you’ve done there? This is not a problem. Automake interprets this assignment syntax (and outputs a single assignment to

Re: parallel build issues

On 2021-06-21, Werner LEMBERG wrote: > I have a `Makefile.am` in a `frontend` subdirectory that looks like > the following (abridged). [...] > Running the generated `Makefile` with `make -j12`, I get this: > > ... > Making all in frontend > make[2]: Entering directory '.../frontend' > ...

Re: config.sub/config.guess using nonportable $(...) substitutions

On 09/03/2021, Warren Young wrote: > On Mar 9, 2021, at 1:26 PM, Paul Eggert wrote: >> >>> 1) There is no actual benefit to using $(...) over `...`. >> >> I disagree with that statement on technical grounds (not merely cosmetic >> grounds), as I've run into real problems in using `...` along

Re: config.sub/config.guess using nonportable $(...) substitutions

On 2021-03-08, Tim Rice wrote: > On Mon, 8 Mar 2021, Nick Bowler wrote: [...] >> These scripts using $(...) are incorporated into the recently-released >> Automake 1.16.3, which means they get copied into packages bootstrapped >> with this version. So now, if I create a pac

config.sub/config.guess using nonportable $(...) substitutions

Hi, I noticed that config.sub (and config.guess) scripts were very recently changed to use the POSIX $(...) form for command substitutions. This change is, I fear, ill-advised. The POSIX construction is widely understood to be nonportable as it is not supported by traditional Bourne shells such

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

On 2021-02-18, Karl Berry wrote: > I think the right thresholds are 5.10 for absolute minimum and 5.16 > for 'we aren't going to test with anything older than this' > > I appreciate the effort to increase compatibility with old versions. > > I imagine you could provide Digest::SHA

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

Hi Zack, On 2021-02-17, Zack Weinberg wrote: > On Fri, Jan 29, 2021 at 5:54 PM Karl Berry wrote: >> But, I think it would be wise to give users a way to override the >> requirement, of course with the caveat "don't blame us if it doesn't >> work", unless there are true requirements such that

Re: DIST_COMMON

On 2021-02-17, Leo Butler wrote: > I cannot find DIST_COMMON documented in the automake manual[*]. Is this > intended or an oversight? Most likely intentional, this looks pretty internal to the "make dist" machinery and not meant to be used directly by package authors. > Looking at the automake

bug#45756: Prepending '+' to the recipe line when linking with GCC's -flto=jobserver

On 2021-01-09, R. Diez wrote: > [Resending in hopes it will attach to the new bug. --karl] > >> [...] >> At any rate, it would be extremely helpful to have a minimal-as-possible >> runnable (automake-able) example showing the case where the + needs to >> be prepended. rdiez, can you create such a

Re: bug#45756: Prepending '+' to the recipe line when linking with GCC's -flto=jobserver

On 2021-01-09, R. Diez wrote: > [Resending in hopes it will attach to the new bug. --karl] > >> [...] >> At any rate, it would be extremely helpful to have a minimal-as-possible >> runnable (automake-able) example showing the case where the + needs to >> be prepended. rdiez, can you create such a

Re: Automake's file locking

On 2021-02-03, Bob Friesenhahn wrote: > GNU make does have a way to declare that a target (or multiple > targets) is not safe for parallel use. This is done via a > '.NOTPARALLEL: target' type declaration. According to the manual[1], prerequisites on .NOTPARALLEL target are ignored and this

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

On 2021-01-28, Zack Weinberg wrote: > There is a potential way forward here. The *only* place in all of > Autoconf and Automake where XFile::lock is used, is by autom4te, to > take an exclusive lock on the entire contents of autom4te.cache. > For this, open-file locks are overkill; we could

Re: Future plans for Autotools

As always, thanks for all your effort Zack! I wanted to share some of my thoughts on Autoconf and friends. Maybe I wrote too much. For me the most important requirement of the GNU build system is that it must be as straightforward as possible for novice users to build free software packages

Re: INSTALL_DATA += -p

On 2020-11-03, Thien-Thi Nguyen wrote: > I'd like to make sure that timestamps are preserved on "make > install". In general, preserving timestamps while copying files cannot be done reliably and when it is possible, it is difficult to do in a portable fashion. But it seems preservation is not

Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver

On 2020-10-28, Zack Weinberg wrote: > On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler wrote: >> On 2020-10-28, H.J. Lu wrote: >> > GCC introduced some time ago option -flto=jobserver in order to use the >> > GNU Make jobserver when parallelising LTO builds. It is actuall

Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver

On 2020-10-28, H.J. Lu wrote: > GCC introduced some time ago option -flto=jobserver in order to use the > GNU Make jobserver when parallelising LTO builds. It is actually a > similar "recursive make". When doing a recursive make, you need to > place a '+' character at the beginning of the

Re: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

On 2020-08-01, TomK wrote: > Thanks very much Karl. Appreciate this feedback. You've answered alot > of the lingering questions I had around this topic. Much appreciated! > > Just for some continued open discussion, included some basic answers. > Not meant to sway to one side or the other, just

Re: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

On 25/07/2020, TomK wrote: > Out of curiosity and a bit on another topic. Is the syntax written > like this for compatibility reasons with other shells? Or because it > could get in the way of the parsers Automake uses? Autoconf is primarily a portability tool and thus a key goal is for

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

On 18/04/2020, Vincent Lefevre wrote: > On 2020-04-18 15:04:08 -0600, Karl Berry wrote: [...] >> Also, not that I wrote any of this, but it seems to me that the >> pervasive assumption is that the automake user in fact owns the file >> trees in question. Thus rm -rf should work even if it's mode

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

On 2020-04-13, Paul Eggert wrote: > I just checked, and GNU Make uses high-resolution file timestamps when > available, and considers a file to be up-to-date if it has exactly the same > timestamp as its dependency. I suspect that this is because Makefile rules > like > this: > > a: b > cp

Re: Installing something nonstandard in $(libdir)

On 2020-02-07, Tom Tromey wrote: >> "Zack" == Zack Weinberg writes: > > Zack> Makefile.am:158: error: 'libfoo$(SOEXT).1' is not a standard library > name > Zack> Makefile.am:158: did you mean 'libfoo$(SOEXT).a'? > > Zack> and lib_DATA is the obvious alternative but that doesn't work either:

Re: Installing something nonstandard in $(libdir)

Hi Zack, On 2/6/20, Zack Weinberg wrote: > For reasons too complicated to get into here, I have been > experimenting with building shared libraries in an autoconf+automake > build *without* using libtool. [Please do not try to talk me out of > this.] I have something that works correctly on

Re: Supporting build rules for grouped targets

On 2020-01-20, Markus Elfring wrote: > Variants of the make software support build rules for grouped targets. > > Examples: > * > https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html#Rules-with-Grouped-Targets > * >

Re: How to install data / lib in more than 1 place?

On 12/11/19, Georg-Johann Lay wrote: >> On Tue, 10 Dec 2019, Georg-Johann Lay wrote: [...] >>> Will this also work with same file names? Like >>> >>> avrfoo_LIBRARIES = libfoo.a >>> >>> avrbar_LIBRARIES = libfoo.a >>> >>> or would that confuse the tools? [...] > It appears to work though, and

Re: Make -j to Compiler Question

Hello Nick, On 2019-09-21, Nicholas Krause wrote: > I'm currently looking on and continuing the palleraling of gcc. There > was a discussion about if its possible to link to make -j to split the > tasks if possible. If so how and what is the easiest way to get this > info into Assuming you're

Re: BUILT_SOURCES called on `make dist` even if the built sources should not be included in the dist

Hi Jerry, On 9/17/19, Jerry Lundström wrote: > This problem seems to have been introduced in v1.16 with: > > - "./configure && make dist" no longer fails when a distributed file > depends on one from BUILT_SOURCES. > > And what I can see in the Makefile output is that $(BUILT_SOURCES) has > been

bug#35848: Should automake use gmake by default if exists?

Hello, On 5/22/19, libor.buk...@oracle.com wrote: > On 5/21/19 5:37 PM, Nick Bowler wrote: >> On 5/21/19, libor.buk...@oracle.com wrote: >>> automake expects GNU make to support dependency tracking. >>> >>> On Solaris it works well if MAKE variable is set t

bug#35848: Should automake use gmake by default if exists?

On 5/21/19, libor.buk...@oracle.com wrote: > automake expects GNU make to support dependency tracking. > > On Solaris it works well if MAKE variable is set to gmake during the > configuration, otherwise, it fails with the following error. > > config.status: error: Something went wrong

bug#35762: (No Subject)

On 2019-05-16, howaboutsyne...@protonmail.com wrote: > On Thursday, May 16, 2019 8:12 PM, Eric Blake wrote: [...] >> : >"$log_file" > Very cool! Thank you very much! I'll use that in my local automake > rebuild. Where can I find more information about ":" ? it seems kinda > tough to search for.

bug#35526: misleading documentation about flag variable ordering

On 5/1/19, Daniel Kahn Gillmor wrote: > https://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering > says: > > The reason ‘$(CPPFLAGS)’ appears after ‘$(AM_CPPFLAGS)’ or > ‘$(mumble_CPPFLAGS)’ in the compile command is that users should > always have the last

Re: Help with -Werror

Hello, On 2019-04-24, Phillip Susi wrote: > It seems like every time I go back to try to do somoe work on the parted > sources I run into a failure to compile due to some silly warning or > other and -Werror being enabled. This time it is from a generated > source file made by gperf. Is this

Re: Is it possible to set the permission bits used by the default install target in a Makefile.am?

Hello Craig, On 2019-03-13, Craig Sanders wrote: > Is it possible to set the permission bits used by the default install > target in a Makefile.am? > > To help try and illustrate what I mean, I present a code snippet from one > of my Makefie.am files. > >>> Begin code snippet >>

Re: Parallel builds with some ordering constraints

On 12/29/18, Kip Warner wrote: > On Sat, 2018-12-29 at 16:10 -0500, Nick Bowler wrote: [...] >> all_tests_except_start = test1.log test2.log test3.log test- >> stop.log >> all_tests_except_stop = test-start.log test1.log test2.log >> test3.log >> >> $(

Re: Parallel builds with some ordering constraints

Hello, On 2018-12-29, Kip Warner wrote: > Parallel builds work fine for my build tree of a system daemon I am > developing. I have unit tests in the form of check_SCRIPTS and > check_PROGRAMS. > > These unit tests, however, can only be partially parallelized because > there needs to be some

Re: Recreate the config files

On 12/7/18, Deepa Ballari wrote: > I'm trying to add new options to newlib.I get all different sort of > errors when I run autoconf,automake.. > How can I recreate the config files and sync with > automake (GNU automake) 1.15, autoconf (GNU Autoconf) 2.69, libtool > (GNU libtool) 2.4.6 ? > > List

bug#33594: TEXINFO_TEX file is not in dist

Hi Ben, On 2018-12-02, Ben Elliston wrote: > When setting TEXINFO_TEX to a different location (eg, > doc/texinfo.tex), the file is no longer distributed in the dist > tarball. Shouldn't it be? This actually is the documented behaviour[1]: ... if you set the TEXINFO_TEX variable (see below),

bug#33166: automake --add-missing does not install config.rpath when AM_ICONV is used

On 10/26/18, Hans-Bernhard Bröker wrote: > Am 26.10.2018 um 17:06 schrieb Stuart Caie: >> Technically, AM_ICONV is not distributed with automake, and neither is >> is config.rpath. However, automake recognises config.rpath as a special >> file to distribute nonetheless. > > That's not really

bug#33085: using myprog_CXXFLAGS with VPATH prevents Makefile from finding sources

Hello, On 10/18/18, Julien COURTAT wrote: > Here's my bug report, I'm building my software out of the source tree, this > is called parallel build (very nice feature). > The way to reproduce the issue is very simple, set myprog_CXXFLAGS = -DANY > and VPATH=@MYDIR@ and the corresponding Makefile

bug#32269: Expanding variables

On 7/25/18, Philip Prindeville wrote: > Since automake/autoconf are responsible for generating Makefiles, we > could add something like: > > val.%: > @$(if $(filter undefined,$(origin $*)),\ > echo "$* undefined" >&2, \ > echo '$(subst ','"'"',$($*))' \ > )

Re: PATCH: silence Shellcheck warning

On 7/21/18, Ben Elliston wrote: > This patch silences a warning from Shellcheck about using old-style > `...` command substitutions. [...] > commit 4d35c7aae97234bf055519075ef03cd4090a1dfc > Author: Ben Elliston > Date: Sun Jul 22 08:22:44 2018 +1000 > > * missing: Use $(..) command

bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?

Hi, I have some doubts about the automake-provided macro AM_WITH_DMALLOC. This appears to be a development tool which could be useful to help programmers debug their packages. It has a very brief description in the Automake manual in section 6.4.1 "Public Macros"[1], including a link to the

Re: _SOURCES files in sub-directories lead to make distdir failure

Hi, On 1/24/18, netfab wrote: > Into that project, there's a subdirectory to build a library using > libtool-2.4.6. The source code of this library is organized into > sub-directories, like this : >> mylib/makefile.am >> mylib/aaa.cpp >> mylib/aaa.h >>

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On 2017-11-28 18:13 -0800, Jim Meyering wrote: > On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote: > > The Automake manual unequivocally states that BUILT_SOURCES files are > > generated only when running 'make all', 'make check' or 'make

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

Hi Jim, On 2017-11-28 11:21 -0800, Jim Meyering wrote: > Date: Thu, 20 Mar 2014 12:31:32 -0700 > Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES) > > * lib/am/distdir.am (distdir-am): New intermediate target. > Interpose this target between $(distdir) and its dependency > on

Re: Finding #includes from a yacc .y.

Hi Ralph, On 2017-11-20, Ralph Corderoy wrote: >> It seems wrong for foo.y to have to `#include >> "path/from/root/to/bar.h" since that means it has to alter if they >> move around the hierarchy. Is there another way? > > I can be more precise having dug into this project

Re: warning: TEST_LDFLAGS' is defined but no program or library has 'TEST' as canonical name

Hi, On 2017-11-20, Thomas Martitz wrote: > here's some quite annoying warning. I'm trying to define a variable > TEST_LDFLAGS that multiple programs use. There is no program named TEST. > The same works fine with TEST_CFLAGS (i.e. no warning is displayed). > > Here's the

Re: Per-Object Flags for Autotool C++ library?

On 11/4/17, Jeffrey Walton <noloa...@gmail.com> wrote: > On Sat, Nov 4, 2017 at 3:56 PM, Nick Bowler <nbow...@draconx.ca> wrote: >>> EXTRA_libcryptopp_la_DEPENDENCIES listing the objects worked for Linux >>> and OS X, but not Solaris. For Solaris I needed to drop

Re: Per-Object Flags for Autotool C++ library?

Hello, > EXTRA_libcryptopp_la_DEPENDENCIES listing the objects worked for Linux > and OS X, but not Solaris. For Solaris I needed to drop the leading > `EXTRA`, and use just `libcryptopp_la_DEPENDENCIES`. Is that just because you happen to be running an antique version of Automake on the Solaris

Re: Per-Object Flags for Autotool C++ library?

On 11/3/17, Jeffrey Walton wrote: > On Thu, Nov 2, 2017 at 6:04 PM, Jeffrey Walton wrote: >> I'm working on adding Autotools to a C++ library and test program. My >> Automake.am has: >> >> >> ... > > I believe I applied Nick and Mathieu correctly. The

Re: Per-Object Flags for Autotool C++ library?

Hi Jeffrey, On 11/2/17, Jeffrey Walton wrote: > I'm working on adding Autotools to a C++ library and test program. My > Automake.am has: > > lib_LTLIBRARIES = \ >libcryptopp.la > > libcryptopp_la_SOURCES = \ >cryptolib.cpp \ >cpu.cpp \ >integer.cpp \ > >

Re: Parallel build sometimes resulting in "fatal error: config.h: No such file or directory"

Hi Simon, On 10/16/17, Simon Sobisch wrote: [...] > Running without `make -j` always work but using parallel builds sometime > break with the mentioned error. [...] > ~~~ > gcc -O2 -pipe -finline-functions -fsigned-char -Wall -Wwrite-strings > -Wmissing-prototypes

bug#28838: Authoritative answer about licensing and copyright of provided scripts and templates

On 2017-10-14, Joël Krähemann wrote: > I need some authoritative answer about copyright notices to be used > for scripts and templates. The files generated by autoscan, autoconf, > automake or alike. > > I need this information in order to proceed with a submission on >

Re: No rule to make target 'bzr.mk', needed by 'all-am'

On 9/29/17, Sascha Manns wrote: > Am Freitag, den 29.09.2017, 16:26 +0200 schrieb Sascha Manns: >> i have a project what provides a file called "bzr.mk". This isnt >> generated and should just installed in $(datadir)/bzrmk. >> [...] >> bzrmk_DATA = bzr.mk >> >> But while

Re: Automake Digest, Vol 175, Issue 3

On 2017-09-05, Kip Warner wrote: [...] > Hey Thomas. Good question. It could well be that no hackery at all is > required with this. Here is my Makefile.am: > > https://github.com/cartesiantheatre/narayan-designer/blob/master/Source/Makefile.am > > See

Re: Portable $addprefix

Hello, On 8/24/17, Kip Warner wrote: > I'd like to transform the following variable in my Makefile.am from... > > files_only = a.foo b.foo c.foo d.foo ... > > Into... > > files_with_path = dir/a.foo dir/b.foo dir/c.foo dir/d.foo ... I'm not aware of any truly

bug#27781: LIBOBJS should depend on LIBOBJDIR

On 8/23/17, Mathieu Lirzin wrote: > Michael Haubenwallner writes: >> Another thought about the final "$(LIBOBJS): .../.dirstamp" Makefile >> line: If I remember correctly, there have been (non-GNU) make >> implementations thatchoke on this

Re: Not installing to hard-coded locations vs polkit's fixed location

Hi, On 2017-08-21, Mike Fleetwood wrote: > I'm working on adding installation of a polkit action file into > GParted's build and install system, however the polkit daemon only > recongises action files installed into the single location of >

Re: Integrating flexc++(1) and bisonc++(1) into Makefile.am

Hello, On 7/12/17, Kip Warner wrote: > My challenge is replicating their functionality for flexc++(1) and > bisonc++(1) in the absense of macros to make their usage easier in > Automake [...] > In trying to integrate the two tools into my build environment, I've > attempted

Re: Makefile.am and patch orthogonality

On 2017-06-21, Anton Shepelev wrote: > Contextual diff-files a very good means of collaborative development > whenever they are used with source code, but I have a problem with > .am files. If two patches should add new source files to the same > directory, they will also

  1   2   3   >