On 2024-07-18 09:40, Zack Weinberg wrote:
> On Thu, Jul 18, 2024, at 5:09 AM, Tijl Coosemans wrote:
>> Automake 1.17 produces a warning for the use of \# ...
>
> For reference, the construct in question is
>
> subst = sed \
> -e 's|@PACKAGE_VERSION[@]|$(PACKAGE_VERSION)|g' \
> -e '1 s|^\
On 2024-07-01 10:21, Zack Weinberg wrote:
> # clue Make that gen-foo also updated foo.h whenever foo.c is new
> foo.h: foo.c
> @:
>
> If I had to guess, I would guess that someone thought Make would be
> more likely to skip invoking a shell if the command was actually empty
> rather than "
On 2024-06-29 07:28, Dave Hart wrote:
> I'm seeing a regression building ntpd on FreeBSD 12.1 amd64 with
> Autoconf 2.71 between Automake 1.16.5 and 1.16.92. I haven't filed a
> bug report yet as I'm trying to do my part to characterize it well and
> provide an easy reproduction. It may well be a
On 2024-06-24 10:04, Zack Weinberg wrote:
> On Mon, Jun 24, 2024, at 2:56 AM, Nick Bowler wrote:
>> I think at the same time it would be worth documenting the AS_LINENO
>> functionality, which is the main internal functionality of these
>> macros that (unless you just
On 2024-06-23 22:23, Zack Weinberg wrote:
> I'm thinking of making AC_RUN_LOG, which has existed forever but is
> undocumented, an official documented macro ...
Yes, please!
I will note that Autoconf has a lot of "run and log a command" internal
macros with various comments of the form "doesn't w
On 2024-06-16 21:35, Jacob Bachmeyer wrote:
> I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST
> to touch config.status if neccessary, instead of trying to decide
> whether to sleep before writing config.status.
If the problem is simply that we want to avoid the situati
On 2024-06-14 10:09, Dan Kegel wrote:
> Oh, ok, perhaps I was confused by the note in automake 1.13.1's NEWS file
> (iirc), which said
>
> Support for IRIX and the SGI C/C++ compilers will be removed in
> Automake 1.14: they have seen their last release in 2006, and SGI
> is expected to retire
On 2024-06-07 19:26, Jacob Bachmeyer wrote:
> Bruno Haible wrote:
>> [I'm writing to automake@gnu.org because bug-autom...@gnu.org appears
>> to be equivalent to /dev/null: no echo in
>> https://lists.gnu.org/archive/html/bug-automake/2024-06/threads.html
>> nor in https://debbugs.gnu.org/cgi/pkgre
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 aprog/,main
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_tracking"
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
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 s
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
>
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 running
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
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
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 introd
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 ?
>
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 mo
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 "compil
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,
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
>> wh
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
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
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 dist
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 distribution
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 gnulib/
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 bi
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'
> ...
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 with
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
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
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 "interna
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 not
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
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
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 will
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 inste
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 from
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 r
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
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
generat
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:
>
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 ELF
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
> *
> https://docs.oracle.com/cd/E86824_01/html/E54763/make-1s.htm
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 even
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 ta
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
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 se
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 >>
>
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
>>
>> $(
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 order
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
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
>> mylib/foo/bbb.cpp
>>
On 2017-11-28 18:13 -0800, Jim Meyering wrote:
> On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler wrote:
> > The Automake manual unequivocally states that BUILT_SOURCES files are
> > generated only when running 'make all', 'make check' or 'make install'.
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 $(DIST
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 a bit.
> Currently, it
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 warning:
>
> Makefile.am:
On 11/4/17, Jeffrey Walton wrote:
> On Sat, Nov 4, 2017 at 3:56 PM, Nick Bowler wrote:
>>> 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 jus
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
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 project is
> available at https://github.com
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 \
>
>...
>
> cpu.cpp nee
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 -Wno-format-y2k -U_FORTIFY_SOURC
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 building the package i'm g
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 parser_clobbered_source_full_paths as an exam
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 portable way to do this dire
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
> /usr/share/polkit-1/action/.
There is a section about
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 the following in Makef
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 have to modify according
Hello,
On 3/3/17, Paul Jakma wrote:
> Well, it's due to the distributed 'doc/quagga.info' being slightly older
> than the (built by automake) doc/defines.texi.
>
> Both are made by the 'make dist' and put in the dist tarball. Then
> distcheck unpacks that to a subdir, makes it RO, and creates ano
Hi,
On 3/3/17, Paul Jakma wrote:
> My make distcheck is broken and I can't figure out how to fix it or
> where the problem lies.
[...]
> chmod -R a-w quagga-1.2.0
> chmod u+w quagga-1.2.0
> mkdir quagga-1.2.0/_build quagga-1.2.0/_build/sub quagga-1.2.0/_inst
> chmod a-w quagga-1.2.0
> test -d qua
On 2016-05-24, Wouter Verhelst wrote:
> I'm adding a systemd unit to my package. To that end, I'm checking if
> there is a pkg-config .pc file for systemd which sets a variable
> "systemdsystemunitdir", and am trying to install the systemd unit in
> that location.
[snip configure script computes s
Hi Andy,
(Note that your mailer seems to have completely mangled all whitespace,
particularly the newlines, in your make snippet. This makes it very
hard to read. I have tried to manually correct it in the quoted text).
On 2016-03-28, Andy Falanga (afalanga) wrote:
> My question is, I hope, qu
On 11/12/15, Will Estes wrote:
> On Thursday, 12 November 2015, 9:41 pm +, Gavin Smith
> wrote:
>> On 12 November 2015 at 19:19, Will Estes wrote:
>> > and Makefile.am:
>> >
>> > check_PROGRAMS = test
>> >
>> > test_SOURCES = test.l
>> > nodist_test_SOURCES = test.c
[...]
>> I'd guess that
Hello,
On 2015-11-12, Will Estes wrote:
> The flex program includes a test suite to enable testing of the version of
> flex built in the flex tree. From a distributed tar ball (made with "make
> dist"), it is possible to build flex without needing to have flex already
> installed because automake
On 10/31/15, Kim Walisch wrote:
> Hi,
>
> I have two open source projects (primesieve and primecount) which use
> the GNU build system. Both currently print a warning during make
> (tested on Ubuntu 15.10 and Fedora 22):
>
> ar: `u' modifier ignored since `D' is the default (see `U')
>
> For prime
On 11/3/15, Michael Felt wrote:
> I suppose in a GNU only world, this would be okay. However, my man page for
> ar still says:
>
>-u
> Copies only files that have been changed since they were last
> copied (see the -r flag discussed previously).
>
> while the option -D is not f
e ANOTHER_PJ_DIR contains an absolute path of another project, but
> the include does't parsed by automake.How can i do it?thx!
> miles.zhaof
Configure substitutions (AC_SUBST) cannot work because Automake includes
are expanded only once, when Automake is run.
The generated Makefile.in file (which gets processed by configure) does
not contain the include commands at all.
Regards,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
[--comments|--no-comments] [--] TEST-COMMAND
The `--test-name', `--log-file' and `--trs-file' options are mandatory.
[1] https://gnu.org/software/gawk/manual/gawk.html#Getline
Regards,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
t3.abc
echo '#!/bin/bash' > test3.abc
+ echo '#!/bin/bash'
echo "echo test3.abc $# ' [' $@ ']'>> test3.log" >> test3.abc
+ echo 'echo test3.abc 0 '\'' ['\'' '\'']'\''>> test3.log'
echo "echo I am a test script>> test3.log" >> test3.abc
+ echo 'echo I am a test script>> test3.log'
Do you see the problem now?
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
(i.e., additional
arguments including the program name are mandatory).
Regards,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Hello,
On 2015-05-18 16:10 +0800, Bas Vodde wrote:
> On 14 May 2015, at 9:24 pm, Nick Bowler wrote:
> > But I think there is a solution: we can (ab)use the fact that 'make dist'
> > internally performs a recursive make invocation. This gives us the chance
> > to
Actually using these features will often break things.
But none of this really has much to do with Automake, except
tangentially because Automake is a tool to help generate portable
make programs.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
='$(COPYFILE_DISABLE)'
into Makefile.am should work I think (not tested), because variables
defined on the make command line *are* exported into the environment.
You will still need the AC_SUBST to define COPYFILE_DISABLE in the
first place.
Regards,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
tests.
[1] Results from a quick test: GNU make and Heirloom make update the
environment, while dmake, NetBSD make, and FreeBSD make do not.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
ed and
reported an error in your package.
Usually these sort of errors are the result of mixing up $(srcdir) and
$(builddir) in the make rules.
To do your own VPATH builds, outside of "make distcheck", first do a
"make distclean" to delete all the build products, then cd in
$(top_srcdir)/build-aux/tap-driver.sh
AM_TAP_AWK is defined right there, in the example code. Its purpose is
to tell the tap-driver.sh program which AWK program to use.
[1]
https://gnu.org/software/automake/manual/automake.html#Use-TAP-with-the-Automake-test-harness
Cheers,
--
Nic
https://gnu.org/software/automake/manual/automake.html#Options
Hope that helps,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
tomake then? Presumably it should either be
generating good tarballs or failing hard. Maybe we could at
least augment distcheck to test for these artifacts and reject
the package in that case.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
O0 -ggdb"
> CXXFLAGS=" -std=c++0x -O0 -ggdb"
> else
> CFLAGS=" -O2 -g"
> CXXFLAGS="-std=c++0x -O2 -g"
> fi
...will override any user assignment to CPPFLAGS, CFLAGS and CXXFLAGS.
It is also basically guaranteed to fail on any compiler that is not
compatible with GCC.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On 2014-11-12 21:58 +0200, fr33domlover wrote:
> On 2014-11-12
> Nick Bowler wrote:
> > What is probably happening is that in VPATH builds from your tarball,
> > your documentation is being rebuilt even though it was distributed.
> > This is leaving files behind in you
nu.org/software/automake/manual/automake.html#Suffixes
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
s is leaving files behind in your build directory, which distcheck
is then complaining about.
Hope that helps,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
s portable, or should a portable Makefile.am use
> only
> the plain $(var) form without the tricks?
The first form of expansion on that page, $(var:.a=.b), should be OK.
They are standard in POSIX and work on all make implementations that I
know of.
The version with % characters is not portabl
ut then instead of being
> satisfied by it (since the script file exists), it complains there's
> no target for it (but none needed since it's a file and it already
> exists).
You can't have ChangeLog depend on your script because the script is
not distributed, so this dependency can never be satisfied in the
tarball.
> Is there a solution for this in automake?
Yes, use a dist-hook.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
ll automagically include
ChangeLog in the tarball if it is present in srcdir. You may want to
also add a distcheck-hook to ensure that this actually happens.
For the second point, if you are not routinely testing VPATH builds
from your git tree at all, just be aware that distcheck may uncove
the actual object
names, which is why I suggested it is safer than specifying object
filenames directly.
If you wrote some object filename explicitly in your Makefile.am, it may
be out of date if you, for example, added per-target CFLAGS or enabled
subdir-objects.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
s, but those .o filenames may change in the future,
> especially in the face of subdir-objects.
The object filenames are reliable as long as you don't change any
settings (like subdir-objects, but also other things). So it is
safer to use mumble_OBJECTS in my opinion.
Hope that helps,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
by the build process; files like READMEs, change
logs, etc. Distcheck will normally NOT notice if such files are
missing.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
portable too (at least in the future).
Well no, it doesn't follow that := assignments will become portable in
the future just because POSIX standardized ::= syntax.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
1 - 100 of 161 matches
Mail list logo
