Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Peter Johansson]

On 1/4/24 06:00, Eric Gallager wrote:

So, `aclocal` has a flag to control this behavior: specifically, its
`--install` flag. Right now I don't see `aclocal` mentioned in the GNU
Coding Standards at all. Should they be updated to include a
recommendation as to whether it's better to put `--install` in
`ACLOCAL_AMFLAGS` or not? Or would such a recommendation be a better
fit for the `automake` manual (since that's where `aclocal` comes
from)?

A common scenario is that the embedded M4 files are not the latest 
version and that the code in configure.ac is not compatible with newer 
versions that might be installed. Setting the --install flag and make 
every developer bootstrap with 'aclocal --install' or anyone trying to 
bootstrap an old version of the project would be very fragile. Also 
'aclocal --install' only overwrite the embedded copy if the serial 
numbers in the files suggest the installed file is a newer version than 
the embedded M4 file.


Peter

bug#68860: race condition with make recheck

[Peter Johansson]

Hi automakers,

I think I've found a race condition with 'make recheck' that results in 
a source file being compiled twice in parallel and resulting in a 
failure such as


mv: cannot stat '.deps/foo.Tpo': No such file or directory

In my trimmed down example my Makefile.am looks like:

lib_LIBRARIES = libfoo.a
libfoo_a_SOURCES = foo.cc
check_LIBRARIES = libtest.a
libtest_a_SOURCES = test.cc
TESTS = one.test two.test
TEST_EXTENSIONS = .test
AM_DEFAULT_SOURCE_EXT = .cc
EXTRA_PROGRAMS = $(TESTS)
libtest_a_LIBADD = libfoo.a
LDADD = libtest.a libfoo.a

The problem seems to be that both $(TESTS) and check_LIBRARIES depend on 
libfoo.a and trigger compilation of foo.cc. I haven't managed to get the 
same problem with 'make check', so I thought comparing the generated 
rules for check: and recheck: would be useful.


recheck: all $(check_LIBRARIES)



all: config.h
    $(MAKE) $(AM_MAKEFLAGS) all-am
...

check-am: all-am
    $(MAKE) $(AM_MAKEFLAGS) $(check_LIBRARIES)
    $(MAKE) $(AM_MAKEFLAGS) check-TESTS
check: check-am

I can see how the "check-am: all-am" works as firewall against the race 
condition. OTOH, in the rule for recheck, 'all' triggers a sub-process 
that will build libfoo.a and in the meantime the main process will build 
$(check_LIBRARIES) which trigger the building of libfoo.a. My 
understanding of parallel make is a bit hazy, but I guess the main 
process and sub-process are only talking wrt how many workers they 
employ and are not talking about which rules to work on.


I suppose this is not by design or that I'm doing something illegal by 
having check_LIBRARIES depend stuff that is built within 'make all'. I'm 
not sure what the best way to fix this would be. One idea would to 
change the rule for recheck to


recheck: all

 $(MAKE) $(AM_MAKEFLAGS) $(check_LIBRARIES)

 


but personally I don't fancy these sub-processes because it feels like 
they are the core of the problem for these sort of race conditions.


I have tested with automake 1.16.5 (ubuntu) and 1.16i.

Please find attached a trimmed down example of the problem.


Best Regards,

Peter


automake.sh
Description: application/shellscript

bug#68808: subsecond mtime discovery code insufficient

[Peter Johansson]

On 30/1/24 22:46, Erik A Johnson wrote:

(Why, then, does Apple continue to include 3.81 in the software 18 years later? 
Beyond me.)


Probably because 3.81 was the last version released under GPLv2 or later 
and IIRC Apple avoids shipping things that are licensed with GPLv3.


Cheers,

Peter

bug#67894: automake-1.16i pretest available: please test

[Peter Johansson]

Hi Karl,

On 27/12/23 08:38, Karl Berry wrote:

 I get one failure (t/nodef)

Hi Peter - I hope this random timing bug is fixed now.


It seems to work. 'make check -j16' goes through and since it seemed to 
be of a random nature previously I ran the individual test repeatedly 
and it passed every time.


Cheers,

Peter

bug#67894: automake-1.16i pretest available: please test

[Peter Johansson]

Hi Karl,

On 20/12/23 10:09, Karl Berry wrote:

Could you try running the test on its own?
   make VERBOSE=1 check TESTS=t/nodef.sh keep_testdirs=yes


I ran it ten times and it succeeded 70% of the runs, so seems quite 
random in line with being due to the timing issue.


Peter

Re: if vs. ifdef in Makefile.am

[Peter Johansson]

On 2/3/23 16:07, ljh via Discussion list for automake wrote:

Hi,


It seems I can not use `--disable-assert` on Debian 11.


You need to call macro AC_HEADER_ASSERT in your 'configure.ac'

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Particular-Headers

hope that helps,

Peter

bug#33573: Patch to replace symlinks with files

[Peter Johansson]

Hi both,

On 1/1/23 05:20, Bogdan wrote:
Karl Berry , Sat Dec 31 2022 03:30:42 GMT+0100 
(Central European Standard Time)

Hi Bogdan,

 Someone reported a bug for this, so I simply gave it a try.

Thank you! I didn't realize you were working on some of the old bugs.
That is great!



:)



To bring this one in particular to fruition: can you check what happens
when -c -a would need to overwrite a symlink? I think it should just
give a warning. Then the user can decide what to do.



It simply doesn't do or say anything, because the object already 
exists (the subroutine simply leaves).



FWIW, as a user I think this is the expected behavior. The option is 
named --add-missing, so if the file is not missing, I expect nothing to 
happen.


Cheers,

Peter

bug#17614: parallel compilation fails

[Peter Johansson]

Hi Mike,

On 25/1/22 16:24, Mike Frysinger wrote:

On 19 Jan 2022 18:32, Peter Johansson wrote:

On 19/1/22 18:10, Mike Frysinger wrote:


assuming it still fails with Automake 1.16 ...


I'll test when I'm out of this semi-lockdown and have access to a
computer with more CPUs.


can you link to the project for us to take a look ?

Tar file is available from here

https://sourceforge.net/projects/libyat/

and subversion repo from here if that's preferable

https://dev.thep.lu.se/yat/svn/trunk

i grabbed the 0.19 release.  perhaps unsurprising, nothing stood out to me
related to the error above.  you didn't have any recursive makes or any code
that seemed to override the dep generation or create conflicting outputs.

if you can reproduce it, get a full log and send it over, and include the
config.log file i think.  something like `make -O -j... >& log`.

the error you quoted is part of automake's dependency generation.  it's very
weird that you'd get an error about .Tpo & .Plo being the same file when the
rule that creates them creates the .Tpo then moves it to .Plo.  there is no
place where we ever write to .Plo otherwise.


I've tried this now and in short I cannot reproduce it. I tried with 
Automake 1.13 now (bcs it's what available by default) and ran both on 
current code and an older branch, but nothing that looks like this. Many 
things have changed since 2014 when this was filed and I think for 
example that the file system was much slower back then. I suspect that 
the problem was that the same file was compiled twice, but since I can't 
reproduce it, it's impossible to determine whether it was due to 
problematic Makefile.am, generated Makefile, or possibly behaviour of 
make, so if not already closed, please close this and I'll report back 
if something similar returns.


Cheers,

Peter

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

[Peter Johansson]

Hi Karl,

On 20/1/22 09:05, Karl Berry wrote:

But if both are set, should the --aclocal-path argument replace
$ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure.


FWIW, in autoconf the commandline -W takes precedence over environment 
variable WARNINGS


https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#autoconf-Invocation


Cheers,

Peter

bug#17614: parallel compilation fails

[Peter Johansson]

Hi Mike,

On 19/1/22 18:10, Mike Frysinger wrote:

retitle 17614 parallel compilation fails: mv: 
yat/statistics/.deps/Percentiler.Tpo and yat/statistics/.deps/Percentiler.Tpo 
are the same file
tag 17614 = moreinfo
thankyou

On Wed, 28 May 2014 14:52:21 +1000, Peter Johansson wrote:

I have a project with a libtool archive built from many source files.
When I build with 'make -j40' I get error message

mv: `yat/statistics/.deps/Percentiler.Tpo' and
`yat/statistics/.deps/Percentiler.Plo' are the same file
make[1]: *** [yat/statistics/Percentiler.lo] Error 1


Looks like some kind of race problem, but I cannot see anything wrong in
the Makefile. Is this a known problem? If not let me know what would be
useful.

The Makefile is generated with Automake 1.14

assuming it still fails with Automake 1.16 ...



I'll test when I'm out of this semi-lockdown and have access to a 
computer with more CPUs.




can you link to the project for us to take a look ?


Tar file is available from here

https://sourceforge.net/projects/libyat/

and subversion repo from here if that's preferable

https://dev.thep.lu.se/yat/svn/trunk


Thanks,

Peter

bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK

[Peter Johansson]

Hi Mike,

On 11/12/21 15:14, Mike Frysinger wrote:

On 11 Dec 2021 09:33, Peter Johansson wrote:

On 10/12/21 15:47, Mike Frysinger wrote:

if it's dropped, i'm not sure how users are supposed to fix things.
the error message says to install GNU coreutils, but if GNU coreutils
uses automake and presents the same error ...

FWIW, automake is not needed to build and install GNU coreutils from a
released tarball.

the issue isn't about running `automake`, it's about the generated Makefile
using functionality that requires GNU coreutils.


Correct. I was sloppy in my analysis. Apologies for the noise.



  if an empty `rm -f` was
invoked as part of the coreutils build process, then the user would be a
bit stuck.

admittedly it's a bit unlikely to show up outside of `make clean`, but
coreutils is known to do some "extra" things (optional tools, generation
of man pages, etc...), and i haven't fully looked at every place where
automake will generate a `rm -f` pattern.  do we have to self-regulate
every time we try to use that in case it might break the bootstrap flow
of coreutils ?

i'm not saying we have to support this scenario.  i'm just pointing out
that it's not as cut & dry as we might hope it would be.

it probably comes down to being a bit clearer on what autotools' goals are
and what it considers reasonable prerequisites.  the GNU config project has
undergone a bit of lively debate in the last year about whether it can use
POSIX shell features that have been standardized for over 30 years.  it has
decided that it cannot for some.

automake clearly doesn't require GNU make.  the manual says:

https://www.gnu.org/software/automake/manual/automake.html#Why-Autotools
* As we have seen, the GNU Build System has a lot of features ...
* Implementing these features portably is difficult and exhausting. Think of
writing portable shell scripts, and portable Makefiles, for systems you may
not have handy. See Portable Shell Programming in The Autoconf Manual, to
convince yourself.
* The GNU Autotools take all this burden off your back and provide:
* Tools to create a portable, complete, and self-contained GNU Build System,
from simple instructions. Self-contained meaning the resulting build system
does not require the GNU Autotools.

so how is "portable" being defined ?  clearly it's not "anything in the latest
POSIX standard is fair game, and anything not supporting the latest POSIX
standard is SOL".  i think users of automake would be surprised by that when
automake has a history of producing Makefile's packages that can be reliably
built on older systems.

if POSIX were a hard requirement, automake wouldn't carry support logic for
Microsoft's lib archiver via `ar-lib`.

so circling back, can we see a way of walking the `rm -f` line without the
maintenance burden being too high ?  e.g. a configure test that checks if
`rm -f` exits non-zero, and some Makefile logic that is able to switch in
the test in/out as needed ?  we could set am__rm_f_suppress to - and just
ignore all failures.  it would allow packages to continue to build (if at
the cost of being extra chatty) for such deficient setups.
am__rm_f_suppress = @am__rm_f_suppress@
am__rm_f = $(am__rm_f_suppress)rm -f

or do we document that we expect `rm -f` to work, and if it doesn't on
your system, then hopefully you won't happen to run into the limitation
when building the project (even if `make clean` might break).  i.e. we
turn the configure-time error into a warning, and then just hope for the
best.  nowhere do we use the `test ... || rm -f ...` pattern.


That seems reasonable. I'd say the minimal change would be to at least 
not call 'rm -f' directly but define a variable


RM = rm -f

so a user has some way around potential problems.

Cheers,

Peter

bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK

[Peter Johansson]

Hi Mike,

On 10/12/21 15:47, Mike Frysinger wrote:

if it's dropped, i'm not sure how users are supposed to fix things.
the error message says to install GNU coreutils, but if GNU coreutils
uses automake and presents the same error ...


FWIW, automake is not needed to build and install GNU coreutils from a 
released tarball.


Cheers,

Peter

Re: Automake for RISC-V

[Peter Johansson]

On 21/11/21 16:32, Billa Surendra wrote:

Then how-to install automake in target image.



Download the tarball from https://ftp.gnu.org/gnu/automake/

unpack and follow the instructions in INSTALL; typically somethings like

./configure

make

sudo make install


Peter

Re: installing documentation one level higher

[Peter Johansson]

On 11/8/21 9:55 pm, Werner LEMBERG wrote:

Folks,



My current rule (in the top-level `Makefile.am`) is

nobase_dist_doc_DATA = doc/bar.html \
   doc/img/baz.png

I think you wanna get rid of the 'nobase_' prefix (but haven't
tested).

If I do that, all files are installed into the same directory,
according to the documentation.


Correct. Sorry about that.



This is not what I want; images
should still be in the `img` subdirectory.

A solution to the problem is the 'install-data-hook' target to move up
all documentation files and directories by one level (I haven't tried
this yet, though).  I just wonder whether there is a better, more
'natural' one.


An alternative approach would be the following snippet:


dist_doc_DATA = doc/bar.html

doc_imgdir = $(docdir)/img
dist_doc_img_DATA = doc/img/baz.png


Cheers,

Peter

Re: installing documentation one level higher

[Peter Johansson]

On 11/8/21 9:55 pm, Werner LEMBERG wrote:

Folks,



My current rule (in the top-level `Makefile.am`) is

nobase_dist_doc_DATA = doc/bar.html \
   doc/img/baz.png

I think you wanna get rid of the 'nobase_' prefix (but haven't
tested).

If I do that, all files are installed into the same directory,
according to the documentation.


Correct. Sorry about that.



This is not what I want; images
should still be in the `img` subdirectory.

A solution to the problem is the 'install-data-hook' target to move up
all documentation files and directories by one level (I haven't tried
this yet, though).  I just wonder whether there is a better, more
'natural' one.


An alternative approach would be the following snippet:


dist_doc_DATA = doc/bar.html

doc_imgdir = $(docdir)/img
dist_doc_img_DATA = doc/img/baz.png


Cheers,

Peter

Re: installing documentation one level higher

[Peter Johansson]

Hi Werner,

On 8/8/21 5:49 am, Werner LEMBERG wrote:

Folks,



My current rule (in the top-level `Makefile.am`) is

   nobase_dist_doc_DATA = doc/bar.html \
  doc/img/baz.png


I think you wanna get rid of the 'nobase_' prefix (but haven't tested).

Cheers,

Peter

bug#49309: Feature Request: Automake script based tests to print the test name before running it

[Peter Johansson]

Hi Kasper,

I leave to the maintainers to comment on the suggestion, but in the 
meantime...


On 1/7/21 1:01 pm, Kasper k wrote:

Hello automake devs,

In script based testsuites 
(https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html#Scripts_002dbased-Testsuites),
 when we run `make check` it prints one of the following string for each test: PASS , 
FAIL , XFAIL  or SKIP .

However, in some cases (long running test, flaky test, other inconclusive ones 
for more involved reasons), it is essential to know which test is currently in 
flight. Especially in CI systems, where flakiness every now and then, due to 
external factors, is almost unavoidable.

It would be very helpful if a new option AM_TESTS_NAME=1 is provided, which 
would change the stdout output from:

 
  PASS (or FAIL/XFAIL/SKIP) $name

to something like:

 RUNNING $name
 
  PASS (or FAIL/XFAIL/SKIP) $name


Please note that that output comes from the test-driver script. If 
you're not happy with the default test-driver, you can declare to use 
your own my-test-driver (see 
https://www.gnu.org/software/automake/manual/automake.html#Declaring-Custom-Test-Drivers), 
and for example this could be a modified version of 'test-driver' script 
provided by Automake. Adding a line outputting 'Running $name' is 
trivial if you know any shell, or otherwise, I'm sure people here can help.




this way we can easily find out the name of test (or multiple of them; in case 
of parallel execution) which is (are) currently running.


I usually find out which tests are running by looking at the timestamps 
of log and trace files with something like 'ls -lrt *.log *.trs'.


Cheers,

Peter

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

[Peter Johansson]

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 hook, which can be used to remove files from the 
distribution, but seems dangerous to exclude files from the tarball that 
are mentioned in the Makefile.



Peter

Re: Constantly changing libtool

[Peter Johansson]

Hi Laurence,

On 15/4/21 6:35 am, Bob Friesenhahn wrote:
Most problems seem to stem from packages providing the generated files 
from Autoconf, Automake, and libtool so that end users don't need to 
have the tools available.


It will be easier for people here to help if you provide a bit more 
information about your set-up. Is the problem when building from a 
tarball or when building from git/subversion? If the latter, do have you 
checked in files generated by autotools into git/subversion, so when 
checking out/cloning the source to a system with other autotools 
versions, there becomes a clash between versions?


Cheers,

Peter

bug#47381: Atomic (fast) install

[Peter Johansson]

On 25/3/21 8:24 pm, Дилян Палаузов wrote:

• Please adjust Automake on “make install” to do (per default or with
an option) atomic install of files, even when libtool is involved: the
file is moved to a temporary destination first, and then rename(2)d, or
the source is moved to the destination, disappearing from the source,
or something like this.


As a workaround, I would write a script using the DESTDIR variable. 
First running make install DESTDIR=/some/path (please refer to the 
manual for details) and then move (rename) files from there to their 
final destination - or include the script in the Makefile if certain 
make variables are needed.


Cheers,

Peter

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

[Peter Johansson]

On 3/14/2019 3:24 AM, Nick Bowler wrote:

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 >>

gimpdir = ${prefix}

gimp_SCRIPTS = scaleAndSetSize.py \
ScaleAndSetSizeClass.py

.PHONY: install
install:

 mkdir -p ${prefix}
 ${INSTALL} -m 544 scaleAndSetSize.py ${prefix}
 ${INSTALL} -m 444 ScaleAndSetSizeClass.py ${prefix}

<< End code snippet <<

My problem with this code snippet is - I don't like the fact that I have
overridden the default install target to get the files installed with the
permission bits set the way I want. Rather, I'd like to have the default
install target do the install work for me, using permission bits that I
would like to specify. Does anybody know if this is possible?

Automake uses INSTALL_SCRIPT to install scripts, which is normally provided
by AC_PROG_INSTALL from Autoconf (and is set to INSTALL).  You can set
this explicitly in Makefile.am to something different (or change the
value in configure).

However, that's probably a pain because you want different permissions
for different files.

One option would be to use both xxx_DATA and xxx_SCRIPTS, which are
installed by INSTALL_DATA and INSTALL_SCRIPT, respectively (this is the
only practical difference between xxx_DATA and xxx_SCRIPTS).  You can
then adjust those variables separately as desired.

Alternately you can use install-local[1] instead, to get more flexibility
but without replacing the standard "install" target.  Try to respect
DESTDIR as well, and prefer $(MKDIR_P) over open-coding mkdir -p.
For example (totally untested):

   544_scripts = scaleAndSetSize.py
   444_scripts = ScaleAndSetSizeClass.py

   install-local: install-my-scripts
   install-my-scripts:
$(MKDIR_P) "$(DESTDIR)$(gimpdir)"
$(INSTALL) -m 544 $(544_scripts) "$(DESTDIR)$(gimpdir)"
$(INSTALL) -m 444 $(444_scripts) "$(DESTDIR)$(gimpdir)"
   .PHONY: install-my-scripts


The manual has the following example of an install hook. I suppose you 
could use something similar, probably a lot easier as changing the 
permission bits is easier than creating a link as in the example below



install-exec-hook:
cd $(DESTDIR)$(bindir) && \
  mv -f prog$(EXEEXT) prog-$(VERSION)$(EXEEXT) && \
  $(LN_S) prog-$(VERSION)$(EXEEXT) prog$(EXEEXT)


Cheers,

Peter

Re: Parallel builds with some ordering constraints

[Peter Johansson]

Hi Kip and Nick,

On 12/30/2018 12:03 PM, Kip Warner wrote:

Almost! The problem is with the last rule you defined because a rule to
generate test-stop.log would have already been generated by Automake
and this would override it. I tested in my own source tree and
confirmed that:

automake-1.16: warnings are treated as errors
Makefile.am:200: warning: user target 'Init_d_Stop.sh.log' defined here ...
/usr/share/automake-1.16/am/check2.am: ... overrides Automake target 
'Init_d_Stop.sh.log' defined here
make: *** [Makefile:1156: ../Makefile.in] Error 1


Interesting. I've used this pattern for long time here

https://sourceforge.net/p/yat-util/code/HEAD/tree/trunk/Makefile.am

The most significant difference I can see is that my tests have suffix 
'.test' and the log files '.log' (not '.test.log'). I know that variable 
TEST_EXTENSIONS is set to '.test' by default so my guess would be that 
the different behaviour would be related to this variable.


Cheers,

Peter

Re: automatically showing test-suite.log on failure?

[Peter Johansson]

Hi Karl,


On 9/13/2018 7:53 AM, Karl Berry wrote:

After make check runs, if there were any failures, I'm wishing for a way
to have automake to automatically show the relevant test-suite.log.


I might be missing something, but I get that behavior in my automatic 
builds by calling 'make check VERBOSE=1'.


Cheers,
  Peter

bug#31157: Advice for help2man does not work for parallel builds

[Peter Johansson]

Hi Ruben and Mathieu,


On 4/22/2018 1:13 AM, Mathieu Lirzin wrote:

Hello Reuben,

Reuben Thomas  writes:


In the manual, we are given the following pattern for using help2man
without breaking make distcheck:

foo.1: foo.c $(top_srcdir)/configure.ac
$(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)
help2man --output=foo.1 ./foo$(EXEEXT)

The problem is that with make -j this can result in two attempts to
make a library in parallel (suppose that we have:

foo_LDADD = libfoo.la
lib_LTLIBRARIES = libfoo.la

). This can fail, and in any case is wasteful.

Have you identified the reason why this can fail?  because


One problem is that the rule for foo.1 can be triggered before 
foo.$(EXEEXT) exists and the rule needs foo.$(EXEEXT) or help2man will 
fail. In a -j1 build this is never a problem as binaries are built 
before man pages.


When the 'missing' script changed behaviour in Automake 1.13 (and became 
useless imvho), we changed the rule in one project so foo.1 depended on 
foo.$(EXEEXT) but not if we are 1) building from a tarball and 2) 
foo.$(EXEEXT) exists.


http://dev.thep.lu.se/svndigest/browser/trunk/man/Makefile.am


Cheers,
Peter

Re: Portable $addprefix

[Peter Johansson]

On 9/2/2017 1:27 PM, Quinn Grier wrote:

You can fix this by generating the complete macro definitions before
Automake runs and including them in Makefile.am.

Another way to do this is to use

macro `AX_AM_MACROS_STATIC' in Autoconf Macro Archive

https://www.gnu.org/software/autoconf-archive/ax_am_macros_static.html#ax_am_macros_static

but it can be a bit quirky to get correct

Cheers,
Peter

Re: installing info files

[Peter Johansson]

Hi Patrick,


On 6/3/2017 5:26 PM, Patrick Alken wrote:

Hi Peter,
   Yes make distcheck is in fact failing (even with your modification).
The error is:

/bin/install -c -m 644 file.info
/data/palken/package/package-1.0+/_inst/share/info
/bin/install: cannot stat ‘file.info’: No such file or directory


Hard to say without seeing the context, but it might be that you need to 
prefix the file with $(srcdir)


install-data-local: $(srcdir)/file.info
${INSTALL_DATA} $(srcdir)/file.info $(DESTDIR)${infodir}

Cheers,
Peter

Re: installing info files

[Peter Johansson]

Hi Patrick,


On 5/21/2017 5:16 PM, Patrick Alken wrote:

Hello,

   I have a .info file (not generated by texinfo) and would like it to be
installed under 'make install'. I tried adding it like this:

info_DATA = file.info

but this gives the following error:

doc/Makefile.am:7: error: 'infodir' is not a legitimate directory for 'DATA'

My current solution, which works is this:

--
EXTRA_DIST = file.info

install-data-local: file.info
 ${INSTALL} file.info ${infodir}
--


I don't know how to do this "automakially", but I would modify the rule 
above to


install-data-local: file.info
${INSTALL_DATA} file.info $(DESTDIR)${infodir}

where I 1) use INSTALL_DATA which default sets permission -m 644 and 2) 
use DESTDIR variable to allow for staged installation 
(https://www.gnu.org/software/automake/manual/html_node/DESTDIR.html#DESTDIR)


I think 'make distcheck' at least is checking that 2) works, so I 
suspect 'distcheck fails' with your current rule.


Cheers,
Peter

Re: Problem with VPATH builds and SCRIPTS primary

[Peter Johansson]

On 11/02/2016 08:06 PM, Raphaël Halimi wrote:

Hi Peter,

Thanks for your answer.

Just to make sure I understand:


CLEANFILES += data/.dirstamp

data/.dirstamp:
  @$(MKDIR_P) data
  @: > $@

This creates a directory "data", and then a file ".dirstamp" in this
directory by redirecting the (empty) result of the "true" command to
this file.


Yes, I stole this rule from the rule generated by Automake when it 
creates files in subdirs.





data/foo.txt: data/.dirstamp
   

This creates a file "foo.txt" (in my case it would be a shell script) in
the "data" directory according to a some rule.


Correct



Unlike the other solution, this doesn't involve configure.ac, and so
it's usable with a "pure" automake setup (without autoconf). This is not
the case of my current setup but still, I see this as an advantage, to
clearly separate the "configure" phase and the "make" phase (I'm still
new to autotools).


Yes, I prefer to have the code for this in Makefile.am (rather than 
configure.ac); it's the natural place to look when 'make' doesn't work 
and easier for new developers to understand, imho.


Cheers,
Peter

Re: Problem with VPATH builds and SCRIPTS primary

[Peter Johansson]

Hi Raphael,

I have the following in my Makefile.am


CLEANFILES += data/.dirstamp

data/.dirstamp:
@$(MKDIR_P) data
@: > $@


data/foo.txt: data/.dirstamp
 

Cheers,
Peter


On 10/28/2016 05:46 AM, Raphaël Halimi wrote:

Hi,

I have a problem with parallel build trees (a.k.a. VPATH Builds).

I'm trying to use GNU autotools to distribute a shell script that need
to be installed with some other files (sample configuration, man pages,
data, etc etc).

Nothing in this project needs to be compiled, but the script is passed
through sed to replace some variables (as showed through examples in
section 9.1 of automake documentation, and section 4.8.2 of autoconf
documentation).

The provided examples work with recursive make, but I only want to
manage a single Makefile.am, and thus I want to use non-recursive make;
that's where my problem appears.

I'm trying to have the final script (the file where sed output is
redirected) in the same subdirectory as the script template, but I can't
find a way to do this that would let "make distcheck" work.

According to section 2.2.6 of GNU automake documentation:

"The build tree usually has the same subdirectory layout as the source
tree; its subdirectories are created automatically by the build system."

Unfortunately, it doesn't seem to be true for the SCRIPTS primary (I
assume it's true and works as expected for compiled binaries and
libraries, I can't know, I'm new to autotools and I'm a sysadmin, I
develop only scripts, nothing compiled).

So, at first, I did this :

-%<-

#
# Main script
#

pkgsysconfdir = $(sysconfdir)/$(PACKAGE)

bin_SCRIPTS = scripts/my_script

# Command to substitute variables
do_subst = $(SED) \
 -e 's,[@]PACKAGE[@],$(PACKAGE),g' \
 -e 's,[@]VERSION[@],$(VERSION),g' \
 -e 's,[@]pkgsysconfdir[@],$(pkgsysconfdir),g' \
 -e 's,[@]pkgdatadir[@],$(pkgdatadir),g'

# Generic recipe to substitute variables in scripts
$(bin_SCRIPTS): Makefile
 $(do_subst) $(srcdir)/$@.in > $@
 chmod +x $@

# Per-script prerequisites
scripts/my_script: $(srcdir)/scripts/my_script.in

->%-

This works for a normal build, but not with "make distcheck"; it fails
with the error message (translated from French):

/bin/bash: scripts/my_script: No such file or directory

I guess make doesn't create the "scripts" subdirectory in "_build/sub"
as it's supposed to (according to the documentation quoted above), so
the shell can't redirect sed's output to this file.

So for now I'm doing this:

-%<-

#
# Main script
#

pkgsysconfdir = $(sysconfdir)/$(PACKAGE)

bin_SCRIPTS = my_script

# Command to substitute variables
do_subst = $(SED) \
 -e 's,[@]PACKAGE[@],$(PACKAGE),g' \
 -e 's,[@]VERSION[@],$(VERSION),g' \
 -e 's,[@]pkgsysconfdir[@],$(pkgsysconfdir),g' \
 -e 's,[@]pkgdatadir[@],$(pkgdatadir),g'

# Generic recipe to substitute variables in scripts
$(bin_SCRIPTS): Makefile
 $(do_subst) $(srcdir)/scripts/$@.in > $@
 chmod +x $@

# Per-script prerequisites
my_script: scripts/my_script.in

->%-

It works with both a normal build and "make distcheck", but the script
ends up in $(srcdir), instead of the "scripts" subdirectory, which is
not my initial goal.

Is there a way to create the script in the "scripts" subdirectory, *and*
make it work with "make distcheck" ?

Thanks in advance.

Regards,

bug#23521: XFAIL

[Peter Johansson]

On 05/19/2016 09:04 AM, Mathieu Lirzin wrote:

Another common use for "expected failure" is to write tests to check
>that error conditions arise as expected, for example, by checking that
>a program raises an error when given invalid input.

I agree that XFAIL can be ambiguous, however I think this usage is not
desirable.  It gives an additional opposite meaning to XFAIL symbol
which makes it even more confusing.

I agree. When I wanna tests that a program fails with incorrect input, I 
prefer writing a tests that calls the program, check that it fails (exit 
1 or whatever is expected), and perhaps even parse the error message, 
and if it looks like I expect exit 0 aka PASS.


Cheers,
Peter

Re: make distclean

[Peter Johansson]

Hi Jürgen,


On 03/18/2016 01:28 AM, Juergen Sauermann wrote:

Hi,

I have received a bug-report saying that 'make distclean' fails for 
GNU APL.


The error message is this:

make[2]: Entering directory `/home/eedjsa/projects/juergen/apl-1.5/src'
Makefile:837: .deps/apl-Archive.Po: No such file or directory
Makefile:838: .deps/apl-ArrayIterator.Po: No such file or directory
Makefile:839: .deps/apl-Assert.Po: No such file or directory
Makefile:840: .deps/apl-Avec.Po: No such file or directory
Makefile:841: .deps/apl-Backtrace.Po: No such file or directory
...
Makefile:916: .deps/apl-Workspace.Po: No such file or directory
Makefile:917: .deps/apl-configure_args.Po: No such file or directory
Makefile:918: .deps/apl-main.Po: No such file or directory
Makefile:919: .deps/libapl_la-Archive.Plo: No such file or directory
Makefile:920: .deps/libapl_la-ArrayIterator.Plo: No such file or 
directory

Makefile:921: .deps/libapl_la-Assert.Plo: No such file or directory
Makefile:922: .deps/libapl_la-Avec.Plo: No such file or directory
Makefile:923: .deps/libapl_la-Backtrace.Plo: No such file or directory
...
Makefile:998: .deps/libapl_la-Workspace.Plo: No such file or directory
Makefile:999: .deps/libapl_la-configure_args.Plo: No such file or 
directory

Makefile:1000: .deps/libapl_la-libapl.Plo: No such file or directory
make[2]: *** No rule to make target `.deps/libapl_la-libapl.Plo'. Stop.
make[2]: Leaving directory `/home/eedjsa/projects/juergen/apl-1.5/src'
make[1]: *** [distclean-recursive] Error 1
make[1]: Leaving directory `/home/eedjsa/projects/juergen/apl-1.5/src'
make: *** [distclean-recursive] Error 1

 





Hard to tell what's going on here without seeing the message from 'make 
distclean' before the error message.



From what I can see:

(1) the libapl related files should not be deleted in the first place .


Well, 'make distclean' always deletes directory '.deps' if their's 
compilation going on.



The Makefile.am (attached) uses:

if WANT_LIBAPL

which is an AM_CONDITIONAL() and the project was NOT ./configure'd to 
build libapl


(2) why would 'make distclean' try (and then fail) to build any 
targets in the first place?


It's not trying to build anything. It's trying to remove deps files, 
which are created by configure (and usually updated by the compiler).





Shouldn't it just delete files created by ./configure and be happy if 
they are gone?




Cheers,
Peter

Re: [libtool] make install fails after an incremental build after a prefix change?

[Peter Johansson]

Hi Kees-Jan,

On 12/30/2015 05:52 AM, Kees-Jan Dijkzeul wrote:

On Tue, Dec 29, 2015 at 8:46 PM, Bob Friesenhahn
  wrote:

>Try adding 'make clean' to your build steps.
>
>The best thing to do is to build outside of the source tree and use a
>separate build directory for each configure incantation.

Either would obviously work, but kind of defeat the purpose of having
incremental builds, and unnecessarily  load the buildserver. A
solution where I could do an incremental build after a configure
incantation would be much preferred.
Similarly, you could add a 'rm foo.la' in your build steps, which will 
be less [cpu] expensive. Or you could manually add the dependency you're 
after, i.e., try something like


foo.la: Makefile

in 'Makefile.am'.

Cheers,
Peter

bug#21956: subdir-objecs dies with "rm: cannot remove 'emxp_cm_bl': Is a directory", even git version

[Peter Johansson]

On 11/19/2015 06:19 PM, Joakim Tjernlund wrote:

hmm, I see the problem.

How do I change Makefile.am, with minimal effort as we have alot of them?
Tried
   bin_PROGRAMS += emxp_hw_bl/emxp_hw_bl
but that gives me:
ne/emxp_ss/emxp_hw_bl/Makefile.inc:14: warning: variable 'emxp_hw_bl_SOURCES' 
is defined but no program or
ne/emxp_ss/emxp_hw_bl/Makefile.inc:14: library has 'emxp_hw_bl' as canonical 
name (possible typo)
ne/emxp_ss/Makefile.am:15:   'ne/emxp_ss/emxp_hw_bl/Makefile.inc' included from 
here
ne/emxp_ss/emxp_hw_bl/Makefile.inc:1: warning: variable 'emxp_hw_bl_LDADD' is 
defined but no program or
ne/emxp_ss/emxp_hw_bl/Makefile.inc:1: library has 'emxp_hw_bl' as canonical 
name (possible typo)
ne/emxp_ss/Makefile.am:15:   'ne/emxp_ss/emxp_hw_bl/Makefile.inc' included from 
here
ne/emxp_ss/emxp_hw_bl/Makefile.inc:2: warning: variable 
'emxp_hw_bl_common_LDADD' is defined but no program or
ne/emxp_ss/emxp_hw_bl/Makefile.inc:2: library has 'emxp_hw_bl_common' as 
canonical name (possible typo)
ne/emxp_ss/Makefile.am:15:   'ne/emxp_ss/emxp_hw_bl/Makefile.inc' included from 
here
It looks like you haven't changed variable names e.g. 
'emxp_hw_bl_SOURCES' to 'emxp_hw_bl/emxp_hw_bl_SOURCES'.


Cheers,
Peter

bug#21956: subdir-objecs dies with "rm: cannot remove 'emxp_cm_bl': Is a directory", even git version

[Peter Johansson]

Hi Joakim,

On 11/19/2015 11:15 AM, Joakim Tjernlund wrote:

automake>= 1.13 (did not test lower than that) dies during make with:
  CCLD emxp_cm_bl_shell
  rm: cannot remove 'emxp_cm_bl': Is a directory
  Makefile:1070: recipe for target 'emxp_cm_bl' failed

This happens if you have the same name on the containing directory and
in bin_PROGRAMS, like so
   bin_PROGRAMS = emxp_hw_bl


You try to create a program named 'emxp_hw_bl'.


   emxp_hw_bl_SOURCES = emxp_hw_bl/emxp_hw_bl.c


But that name is already taken by the directory (in which the source 
files resides).


If you think this is a bug, what do you think is the preferable behaviour?

Cheers,
Peter

Re: What is minimum set of Automake work files needed for distribution on github?

[Peter Johansson]

On 09/28/2015 08:20 PM, Robert Parker wrote:

I need to meet the requirements of 2 sets  of users, the ordinary user who
is only interested `./configure; make; make install` and the power users
who want to start with `autoreconf`.

So far google search on the topic has only increased my confusion.

The minimum set is 'configure.ac' and 'Makefile.am', but we typically 
have the m4 files under version control as well to avoid the requirement 
that the right version should be available in a location where aclocal 
can find it. Then we usually add some text files also, such as 'README' 
and definitely 'COPYING'.


hth,
Peter

Re: GNU Standards

[Peter Johansson]

On 09/01/2015 08:14 AM, Andy Falanga (afalanga) wrote:

  Where can I get these standards?


https://www.gnu.org/prep/standards/

Cheers,
Peter

Re: _build/sub and distcheck

[Peter Johansson]

On 06/24/2015 10:20 PM, Harlan Stenn wrote:

So I notice that in automake-1.15 the distcheck stuff is now begin built
in _build/sub/.  I am generating some files for our test framework that
want to access stuff in srcdir.

I have these .in files using @srcdir@, but with the change from _build
to _build/sub this expansion is no longer working.
@srcdir@ should expand to ../.. in _build/sub/Makefile, so it should 
still work. What am I missing?


Cheers,
Peter

Re: How do you set VERBOSE for parallel testin

[Peter Johansson]

On 05/15/2015 12:24 AM, Arthur Schwarz wrote:

And as a simple question, why are you using make -j8? Shouldn't this

be part of the automake generated test code?

The short answer is because I wanna use 8 cpus. There is no sensible way

Automake can know how many cpus I wanna use.

$ make check TESTSUITEFLAGS=-j8

I just searched the Automake.html manual and can't find TESTSUITEFLAGS.
Where is this documented? Is this part of a new release?

Unlike Serial Test Harness execution, the Parallel Test Harness does not
output how it executes its tests. No way to find out what's under the hood
without checking the code.

I haven't looked at the Makefile source - mainly, I suspect, because I'm not
a make guru (or even an aficionado). My guess was that The Makefile directed
test execution was either:

make -j# $(TESTS)   or
  
for I in $(TESTS); do make -j $i; done


Your guess is wrong. The key line in 'Makefile.in' is

$(TEST_SUITE_LOG): $(TEST_LOGS)

which means that before creating 'test-suite.log' the log file for each 
test is generated. This structure *allows* parallel execution, but only 
if the user chooses to. If the user run make single-threaded the test 
suite will be run on a single cpu. This is by design. If a user issues 
'make check' you want one single cpu to be used; it would be very 
annoying if make spawned away processes. If a user issues 'make -jX' 
then the structure allows make to run tests in parallel. This is not 
possible in the old serial test suite, which basically just ran the 
tests in a loop.


Cheers,
Peter

Re: How do you set VERBOSE for parallel testin

[Peter Johansson]

On 05/15/2015 10:36 AM, Arthur Schwarz wrote:

  And, if I guess correctly, the user can write
  make check TESTSUITEFLAGS=-jN


I've never seen TESTSUITEFLAG before, so I don't know.


  
  As a nit-noy, don't you mean processor and not cpu? And

  does -jN specify processors or processes or both?

Correct.

Cheers,
Peter

Re: How do you set VERBOSE for parallel testin

[Peter Johansson]

On 05/14/2015 01:20 AM, Arthur Schwarz wrote:
My question is is this the only way to use VERBOSE? The Automake 
Manual seems to say that VERBOSE is a variable, not a make argument. 
And, as a variable, if the user (you) can change it's value then the 
appropriate way to do it is either: env VERBOSE=1 make -e check or 
VERBOSE=1; export VERBOSE; make -e check 


well I use GNU make for which 'make VERBOSE=1' works as well.


Have you tried make check -j8 VERBOSE? If this works then it means that
the existence of VERBOSE is sufficient to turn the option on. This is a
possible interpretation of 15.2.3 Parallel Test Harness If the variable
'VERBOSE' is set, this file is output after the summary.

And as a simple question, why are you using make -j8? Shouldn't this be
part of the automake generated test code?


The short answer is because I wanna use 8 cpus. There is no sensible way 
Automake can know how many cpus I wanna use.


Parallel here means that the tests will run in parallel. The old serial 
test-suite had a rule with something like this


check: all
  for t in $(TESTS); do $(SHELL) $$t; done

which is not parallel and the run command $(SHELL) $$t depended on the 
labguage etc; can't remember the details.


Cheers,
Peter

Re: How do you set VERBOSE for parallel testin

[Peter Johansson]

On 05/13/2015 08:42 AM, Arthur Schwarz wrote:



Yes, this is expected.  test-suite.log is created no matter what, but
the rules associated with creating it fail if the log contains any
failure reports, so that make will quit running and let you investigate
those failures.

If I understand this correctly, when executing test scripts the first
failure will cause make to discontinue execution (?). This doesn't happen.
Make continues until all tests in the variable TESTS are executed. Then
again, I must be misunderstanding you?


Correct. All tests will run and create their corresponding .log files.


As for why test-suite.log was not replayed as part of the make output,
I'm not sure that you had VERBOSE=1 set.  So far, you've only attached
the generated Makefile (but not the source Makefile.am), and didn't show
what command you ran.  You'll need to make your setup easier for others
to reproduce before we can see what you are attempting.

I am including several files.
test.pdfconsole output showing test results
Makefile.am src/Makefile
Test-suite.log  generated file
configure.ac./configure.am
Makefile.am ./Makefile.am

As for the test-suite.log not having much output, it is probably because
your tests are not very noisy.  Running make captured all of the output
of your tests, but if your tests didn't output anything, then the log
has very little to show.  Again, without knowing what your test scripts
are doing, it's hard to reproduce your setup.

 From the Automake Manual Section 15.2.3 Parallel Test Harness,  The output
from failed tests is collected in the test-suite.log file. If the variable
'VERBOSE' is set, this file is output after the summary.

This quote is in fact not fully accurate. The output from all tests are
collected in the test-suite.log file.


Nope, I just ran 'make check' in one of my projects and test-suite.log 
only contains the output from the test that failed.



I can not set VERBOSE to output the
test-suite.log file.

Your statement concerning the paucity of output does not preclude showing
any output. In fact, removing the generated echo statements from the
generated shell scripts in Makefile.am, and making no other change, will
show that the test harness generates an output for each test case executed
in the test-suite.log file.

I have tried to set VERBOSE in my Makefile.am to '1' and to 'yes' and yes
and just plain yes. The test-suite.log file does not output. Am I missing
something? How is VERBOSE supposed to be turned on?


Usually I run my tests with something like this:

make check -j8 VERBOSE=1


hth,
Peter

--
Peter Johansson

Re: How do you echo a shell variable reference

[Peter Johansson]

On 04/14/2015 08:24 AM, Arthur Schwarz wrote:

I am trying to echo:
echo 'exit $status'  file

from the Makefile generated by Makefile.am. What I get is:
echo 'exit $status'  file

in the Makefile, which is correct, but in execution (make check) I get
exit tatus

Shell variables are referred to with double dollar sign in a Makefile:

echo exit $$status

hth,


--
Peter Johansson

Re: distcheck: permission denied for file created from .PHONY target

[Peter Johansson]

On 03/14/2015 06:13 PM, Marko Lindqvist wrote:

The file can get outdated (i.e. you can't rely it being always
correct even when it exist), but the exact situation where it gets
outdated would be hard to track (having it to have correct
dependencies would be*the*  clean solution to my problems) so it's set
as .PHONY target.
I'd let it depend on 'configure' and then it's re-generated (at least) 
every time you bump your VERSION, which should happen every time you 
release.


Cheers,
Peter

--
Peter Johansson

Re: make dist fails for EXTRA_DIST elements

[Peter Johansson]

Hi Andy,

On 03/10/2015 08:23 AM, Andy Falanga (afalanga) wrote:

I try taking out the *.cpp file and try again with the same error but with the *.h.  If I 
take out the *.h file, all is well again and make dist is happy and fine.  
Why is it picky with files ending with *.cpp and *.h if these things are extra to the 
distribution and have nothing to do with the build anyway?


You tell Automake that files 'path/to/WindowsSource.cpp' and 
'path/to/WindowsSource.h' should be included in the dist tarball. When 
make can't find the files and no rules to create the files, it aborts. 
That is as expected.


Cheers,
Peter

Re: Part 2: Add Cleanfiles for User Defined Special Sources [Re: How to add new Makefile-Rules through Configure?]

[Peter Johansson]

On 03/09/2015 06:34 PM, Marc Wäckerlin wrote:
Just to state my intention: I want to ad a couple of M4-Macros to 
support users of now unsupported build tools, namely doxygen, Qt, 
dpkg-buildpackage, rpmbuild, ...; then I will deliver those as M4 
macro library that can be included in configure.ac and that should do 
as much as possible automagically - as usual within the autotools.


I have a macro YAT_SVN_RELEASE that I use in several projects

http://dev.thep.lu.se/yat/svn/trunk/m4/yat_svn_release.m4

You may also find AX_ADD_AM_MACRO_STATIC useful

http://www.gnu.org/software/autoconf-archive/ax_add_am_macro_static.html#ax_add_am_macro_static

Cheers,

--
Peter Johansson

Re: converting to subdir-objects

[Peter Johansson]

On 03/08/2015 07:46 PM, Harlan Stenn wrote:

The problem I'm seeing (with at least automake-1.12.1 and automake-1.15)
is that the .deps directories are not being created along the subdir
path, so the build is failing.

So if A/Makefile.am contains:

  foo_SRCS = ... $(srcdir)/../foo/bar.c

Hi Harlan,

I had the same issue and wouldn't care unless Automake 1.15 started to 
warn about source file in a subdirectory. In my case 'bar.o' is also 
built from 'foo/Makefile' so I decided to skip using 'bar.c' as SOURCE 
and instead link in 'foo/bar.o'.


http://dev.thep.lu.se/svndigest/changeset/1581

Cheers,
Peter

--
Peter Johansson

bug#19961: check-local is kind of like check-hook

[Peter Johansson]

On 02/28/2015 02:07 AM, Shahbaz Youssefi wrote:

Hi,

The -local and -hook targets are generally used like this:

X: X-local
 # stuff to do X
 $(MAKE) X-hook

That is, X-local is run first, then the automake generated rules do X
and then X-hook is called.

With check-local, the generated Makefile.in looks like this:

check-am: all-am
 $(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local

Now as far as the documentation is concerned, this is valid:


With the -local targets, there is no particular guarantee of execution order; 
typically, they are run early, but with parallel make, there is no way to be 
sure of that.

However, even with not-parallel make, check-local executes after the tests.

To align this with the other -local rules, why not generate it like this?

check-am: all-am check-local
 $(MAKE) $(AM_MAKEFLAGS) check-TESTS


I think it would be a mistake to change this rule. Some projects might 
rely on the fact that 'check-local' depends on 'all-am' and 
'check-local' might e.g. run some of the programs built within 'all-am'.





The reason I actually have a problem with the current method is that
it is impossible to perform an action before the check. In my
particular case, my test scripts use test kernel modules. Of course,
automake doesn't have a target like check_KERNELMODULE for example to
automatically build the kernel module before running the tests. So
ideally what I could do is to build the kernel module in check-local.
The way the Makefile.in's are currently generated, this is impossible.

In my case, I had to use all-local to build the test kernel modules,
even if the user is not interested in make check, which is annoying in
the least.


With my Automake the rule looks like:

check-am: all-am
$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS) $(check_DATA)
$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local

so you could move your check_kernelmodule into check_DATA with something 
like (untested)


check_DATA = kernelmodule.timestamp

kernelmodule.timestamp:
@echo ***
@echo ***
@echo I want this to be called before the check
@echo ***
@echo ***





Cheers,
Peter

--
Peter Johansson

Re: dist prerequisites

[Peter Johansson]

On 06/09/14 02:20, Jack Bates wrote:

How do I make another target a prerequisite of the dist target?
I want my man target to be a prerequisite of the dist target,
so when I run $ make dist it calls my man target.

EXTRA_DIST is not working directly, I suppose, but I would still try 
that path.


Cheers,
Peter

Re: Automake extension mechanism?

[Peter Johansson]

On 22/08/14 10:55, David Ventimiglia wrote:

Hi,

Does Automake provide any kind of extension mechanism so that one can
produce, and possibly share, useful Makefile fragments?



Hi David,

What I've chosen to do is to write autoconf macros that generate these 
Automake fragments, so all I need to do as user is to call the macro in 
'configure.ac' and include the fragment file in my 'Makefile.am'. The 
real benefit of that is when the macro has been modified and aclocal 
will take care of updating the macro in each project and the automake 
fragments are re-generated. An example of this idea you can see in macro 
YAT_SVN_REVISION found here 
http://dev.thep.lu.se/yat/svn/trunk/m4/yat_am_macros.m4


Cheers,
Peter

bug#18286: distcheck fails to detect missing files

[Peter Johansson]

Hi,

I have this snippet in my 'Makefile.am'


include am/test_data.am

$(srcdir)/am/test_data.am: $(srcdir)/test/data.txt 
$(srcdir)/am/test_data.am.in

cd $(srcdir)  $(SHELL) bootstrap am/test_data.am


It first includes (at Automake time) a snippet, which is generated while 
bootstrapping. Now I forgot to include $(srcdir)/test/data.txt 
$(srcdir)/am/test_data.am.in in the distball, which caused the embarrassing


make: *** No rule to make target `am/test_data.am.in', needed by 
`am/test_data.am'.  Stop.


The surprising thing is that distcheck does not detect this problem, but 
'make distcheck' passes through without problem. The reason for this is 
probably because while $(srcdir)/test/data.txt does not exist, make also 
looks in $(srcdir)/$(srcdir)/test/data.txt and that file exists as it is 
part of my development directory. If I change my Makefile.am to


$(srcdir)/am/test_data.am: test/data.txt am/test_data.am.in
cd $(srcdir)  $(SHELL) bootstrap am/test_data.am


'make distcheck' will detect the problem, but I have this habit of type 
$(srcdir) for things that are supposed to be in $(srcdir). Is that a bad 
habit?


A fix could be to let distcheck not work in $(distdir) but instead 
create 'tmp_/$(distdir)', builddir 'tmp_/$(distdir)/$(builddir)', and 
installdir 'tmp_/$(distdir)/inst_' which would hide the development 
files from the distcheck. What do you think?


Thanks,
Peter

--
Peter Johansson

Re: make install-dirPRIMARY

[Peter Johansson]

On 08/18/2014 03:07 AM, fr33domlover wrote:

Anyone has some advice? My code uses those targets at the moment, but I'm not
sure it's good for long term.
Not sure I understand your problem, but have you read the 'Extending' 
section in the manual


http://www.gnu.org/software/automake/manual/automake.html#Extending

Cheers,

--
Peter Johansson

bug#17614: parallel compilation fails

[Peter Johansson]

Hi,

I have a project with a libtool archive built from many source files. 
When I build with 'make -j40' I get error message


mv: `yat/statistics/.deps/Percentiler.Tpo' and 
`yat/statistics/.deps/Percentiler.Plo' are the same file

make[1]: *** [yat/statistics/Percentiler.lo] Error 1


Looks like some kind of race problem, but I cannot see anything wrong in 
the Makefile. Is this a known problem? If not let me know what would be 
useful.


The Makefile is generated with Automake 1.14

Thanks,
Peter

--
Peter Johansson

bug#17614: parallel compilation fails

[Peter Johansson]

On 05/28/2014 02:52 PM, Peter Johansson wrote:

Hi,

I have a project with a libtool archive built from many source files. 
When I build with 'make -j40' I get error message


mv: `yat/statistics/.deps/Percentiler.Tpo' and 
`yat/statistics/.deps/Percentiler.Plo' are the same file

make[1]: *** [yat/statistics/Percentiler.lo] Error 1


Looks like some kind of race problem, but I cannot see anything wrong 
in the Makefile. Is this a known problem? If not let me know what 
would be useful.


I forgot to mention that the source file in question, 'Percentiler.cc', 
is extremely small (only a constructor that copies a bool and a double) 
so the compilation is extremely fast.


Cheers,

--
Peter Johansson

Re: Influencing DEFAULT_INCLUDES

[Peter Johansson]

On 18/05/14 10:54, Bob Friesenhahn wrote:
Is there a safe way to change DEFAULT_INCLUDES to only include what is 
needed? 


Hi Bob,

Have you looked at automake option 'nostdinc'?

Hope that solves it.

Peter

Re: Recompiling a source multiple times

[Peter Johansson]

On 03/31/2014 02:45 AM, Balaji, Pavan wrote:

Hello,

I’m looking for a way to recompile the same source file multiple times with 
different flags and adding them into a single library.

Currently, I’m doing this:

8
lib_foo_la_CPPFLAGS = -DBUILD_FOO
lib_foo_la_SOURCES = a.c b.c

lib_bar_la_CPPFLAGS = -DBUILD_BAR
lib_bar_la_SOURCES = a.c b.c
8



You can merge libfoo and libbar with something like:

lib_LTLIBRARIES = libfubar.la
libyat_la_LIBADD = libfoo.la libbar.la

Very untested and confused by your underscores.

Cheers,
Peter


This builds a.c and b.c with two different flags, but creates two different 
libraries libfoo.la and libbar.la.  Is there a way to embed them into a single 
library?  The build flags already take care of eliminating duplicate symbols.

Note that doing source-specific builds will be inconvenient as the number of 
source files can be very large.

Thanks,

   — Pavan





--
Peter Johansson

Re: Cannot locate /usr/share/aclocal/pkg.m4

[Peter Johansson]

On 03/26/2014 08:41 AM, Yunzhong Gao wrote:

Hi all,
I was trying to install automake 1.14 on Ubuntu 13.10 which comes with
automake 1.13 pre-installed. I appear to be missing this file
/usr/share/aclocal/pkg.m4. Is this file
auto-generated by the configure-make-install process, or is it to be
downloaded from
somewhere? Many many thanks in advance,
- Gao
Sounds like you need to set the search path; have a look at `dirlist' in 
the manual. If you provide more details on what error you experience, 
it's easier for people to help.


Cheers,

--
Peter Johansson

Re: generated version numbers

[Peter Johansson]

On 02/27/2014 04:47 AM, Harlan Stenn wrote:

So while the filestamps are technically correct, the generated Makefile
*will*  see that version.m4 is newer than config.h.in and regenerate it
via Makefile dependencies.

I suspect the answer is that at the end of the bootstrap script, if the
aclocal.m4 file is newer than the config.h.in file we need to touch
the config.h.in file.

Hi Harlan

File 'config.h.in' is generated by autoheader [I assume]. Autoheader 
will not touch the time-stamp of 'config.h.in' if the content doesn't 
change. This can be annoying, and is the reason Automake generated rule 
has a 'touch $@' after autoheader is called


$(srcdir)/config.h.in:  $(am__configure_deps)
($(am__cd) $(top_srcdir)  $(AUTOHEADER))
rm -f stamp-h1
touch $@

In my bootstrap script I issue autoreconf with option '--force', so I 
don't see this problem. If you think that is too expensive, you could 
set environment

variable AUTOHEADER with something like:

AUTOHEADER=autoheader -f autoreconf -vi

Changing the behaviour of autoheader, I suspect will be met by some 
significant resistance.



Cheers,

--
Peter Johansson

Re: generated version numbers

[Peter Johansson]

On 02/27/2014 11:05 AM, Harlan Stenn wrote:

Yes, understood.  And the problem is that am__configure_deps includes
am__aclocal_m4_deps, which includes aclocal.m4.


Inaccurate. am__configure_deps includes aclocal,m4 via variable 
$(ACLOCAL_M4). am__aclocal_m4_deps describes which files 'aclocal.m4' 
depends on and depending on itself would probably have caused Make to 
implode.




So we have a case where as a result of autoreconf running, aclocal.m4
gets updated and config.h.in does not get updated.  But the resulting
directory will require autotools (apparently the 'missing' stuff is
insufficient) because make*will*  force a rebuild of config.h.in because
aclocal.m4 is newer.


Correct. Are you saying that these time-stamps get propagated to a 
distribution tarball. If so, it smells like the 'make dist' target could 
get improved???



Cheers,
Peter



So perhaps autoreconf needs a late test that if aclocal.m4 is newer than
config.h.in, we touch config.h.in .

This way, if nothing is updated then nothing gets touched.  But if
aclocal.m4 gets updated we'll avoid this particular problem.



--
Peter Johansson

bug#16623: PACKAGE vs PACKAGE_TARNAME

[Peter Johansson]

[adding bug-automake]

Hi infirit,

On 02/02/14 12:25, infirit wrote:

Hi,

So for a project we wanted to make the tarball different from from the
package name. So we updated AC_INIT and added the tarname and indeed
now the tarball generated changes.

However, we noticed that now the $PACKAGE variable is also changed to
what we set as tarname. Which then caused files being installed in the
wrong place as now $(pkgdatadir) changed as well.


The first argument in AC_INIT is used to set variable $PACKAGE_NAME. The 
variable $PACKAGE is set by Automake within AM_INIT_AUTOMAKE somehow 
inferred from your AC_INIT call, so this looks like a bug (or feature) 
in Automake (cc:d here). I think you can solve your problem by adding 
no-define to AM_INIT_AUTOMAKE and define variables PACKAGE and version 
yourself. Hopefully the gurus on the list have some better idea.


Cheers,
Peter


As an example, we changed
AC_INIT([this_is_package], [0.0.1], [http://someurl/])

to
AC_INIT([this_is_package], [0.0.1], [http://someurl/],
[this_is_package_tarname])

I tested this with a small configure.ac and empty Makefile.am. The
example is below.

--
AC_INIT([this_is_package], [0.0.1],[http://someurl/],[this_is_package_tarname])
AM_INIT_AUTOMAKE([1.9 foreign dist-xz no-dist-gzip])

AC_OUTPUT
AC_CONFIG_FILES([Makefile])

echo ${PACKAGE}
echo ${PACKAGE_TARNAME}
--

I put in some echo's at the end of the configure.ac and indeed the
variables $PACKAGE and $PACKAGE_TARNAME *both* change when adding the
tarname to AC_INIT.

Is this a bug in autoconf or are we missing something?

I am not subscribed so please cc me on replies.

Thx
~infirit

___
Autoconf mailing list
autoc...@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

bug#16057: Non-parallel test suite API changes in 1.13

[Peter Johansson]

On 12/06/2013 08:49 AM, Eric Blake wrote:

Why not? 1.13 is almost one year old now...

Believe it or not, some people still like to make their project work
with out-of-the-box tools.

+1

--
Peter Johansson

Re: generated files issues

[Peter Johansson]

On 09/25/2013 08:00 AM, Werner LEMBERG wrote:


What's the recommended solution to such a problem, except adding
dependencies for all .c files which directly or indirectly include
`foo.h' (which is both inconvenient and error prone)?

Hi Werner,

I use line below in one of my project for similar thing

BUILT_SOURCES = $(builddir)/svn_revision.h


That should ensure that 'svn_revision.h' is created before any 
compilation starts. I have a non-recursive Makefile so not sure how it 
works in recursive context.


Cheers,
Peter

Re: [OMPI devel] GNU Automake 1.14 released

[Peter Johansson]

On 09/04/2013 09:10 AM, Miles Bader wrote:

Jeff Squyres (jsquyres)jsquy...@cisco.com  writes:

We've been using sym links in the OMPI project for years in order to
compile a series of .c files in 2 different ways.  It's portable to
all the places that we need/want it.

Hmm, how about just cp ...? :]


Autoconf's AC_CONFIG_LINKS provides a way to use symbolic links when 
possible and otherwise hard links or copies. Could be an alternative if 
portability becomes an issue


http://www.gnu.org/software/autoconf/manual/autoconf.html#AC_005fCONFIG_005fLINKS

Cheers,
Peter

bug#14775: automake 1.13.3 warning about version mismatch

[Peter Johansson]

Hi,

This is probably already fixed with the version scheme and everything, 
but wanted to report it just in case. I updated from from automake 1.13 
to 1.13.3 and after having modified an Makefile.am, Automake complained 
about version mismatch. I suspect aclocal.m4 was created with aclocal 
1.13 (?). This is easily resolved by running autoreconf -if, but I found 
it odd that a patch upgrade should cause that minor head ache. 
Especially since I then upgraded to Automake 1.14 and expected the same 
thing to happen, but no - now if I issue 'make' it will happily keep 
running automake-1.13 (which is version 1.13.3 obviously). So in short 
upgrading a patch version cause version mishmash but upgrading a minor 
version is smoother than expected. Is this still the case with 1.14, 2.0 
etc? If so, is it on purpose?


Cheers,
Peter

tests using multiple processes

[Peter Johansson]

Hi automakers.

I have a test-suite (with automake parallel) in which some of the test 
cases run multithreaded applications and therefore use eg four CPUs. In 
order to avoid total overload I currently reduce number of jobs e.g. 
'make -j2' rather than 'make -j8', which is sort of waste because it 
means that for part of test the load is only 25%. Is there a way/trick 
anyone has come up with to tell Make that OK this test should allocate 
4 jobs, while these jobs only need one job each.


Cheers,
Peter

Re: Broken install-data-yes target

[Peter Johansson]

On 06/06/2013 07:37 AM, Kip Warner wrote:

Hey list,

My make install target for my autotool'd project's translations
directory has a number of prerequisites. The one which seems to be
causing trouble is the install-data-yes target. Yes, I am aware the path
I am using contains spaces and yes I am aware that makefiles can choke
on it if not properly dealt with (e.g. escaped). From the final
generated Makefile...

install-data-yes: all
 @catalogs='$(CATALOGS)'; \
 for cat in $$catalogs; do \
   cat=`basename $$cat`; \
   lang=`echo $$cat | sed -e 's/\.gmo$$//'`; \
   dir=$(localedir)/$$lang/LC_MESSAGES; \
   $(mkdir_p) $(DESTDIR)$$dir; \

The second to last line seems to be causing problems.


Have you tried quoting the last two lines; something like:

  dir=$(localedir)/$$lang/LC_MESSAGES; \
  $(mkdir_p) $(DESTDIR)$$dir; \

Cheers,
Peter
 

Re: install-strip variant that strips then installs?

[Peter Johansson]

On 05/08/2013 02:12 AM, Rhys Ulerich wrote:

I gather that 'make install-strip' installs and then strips binaries.
Is there some variant that reverses the order?  If not, any
recommendations for how to write one in an Automake-compliant manner?



Hi Rhys,

I'm tempted to believe the DESTDIR feature could be useful here with 
something like


make install-strip DESTDIR=`pwd`/tmp

and then copy files under 'tmp' into your final destination.

Cheers,
Peter

Re: serial-tests option and backwards compatibility

[Peter Johansson]

On 2/7/13 7:58 PM, Stefano Lattarini wrote:

On 02/05/2013 12:22 AM, Peter Johansson wrote:

On 02/04/2013 11:31 PM, Stefano Lattarini wrote:


When I did this, I should really have published a 1.11.x release offering
this same option as well; that would have removed all confusion.  Sigh,
such a low-hanging fruit not picked :-(

I disagree. IMVHO micro releases should only fix bugs and not introduce new
features,


I agree, but this wouldn't have been the case; 'serial-tests' would have
just been recognized as a no-op option (as it is in 1.12), to enhance
forward compatibility.



To recognize an new option is a feature also if the option is a no-op. 
Accepting an option in 1.11.6 which is not accepted in 1.11 means that 
those versions are not compatible. A Makefile.am that works with 1.11.6 
might not work with 1.11.



i.e., versions within 1.11.x should be both back and forward
compatible.


And it would have been so -- better than now!


No, only one way direction compatible.


The way to avoid these problems would have been to let the fruit sit
there for, say 3-5 years, and then change the default value.


Indeed (which is just what I've before admitted has been my mistake).


   2013-01-01  Release automake 1.13.1 (parallel tests now default)


This isn't the only backwards incompatible change made recently,
and in my humble opinion I think the timeframes introducing
backwards incompatibility are too aggressive.


You are not the only one to think so, and I've come to agree (at least
partially); for some more discussions and background, see:

http://lists.gnu.org/archive/html/automake/2013-02/msg1.html
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578

So things should proceed more carefully in the future (I hope).

In hindsight, I'm surprised no one objected to your aggressive changes.


   From a backwards-compatibility point of view, I think the default
should be reverted to serial tests, and make it clearer that
parallel tests are available as an option.


With this I must disagree, sorry.

I agree with your disagreement ;) flip-flopping back and forth would
cause complete confusion and chaos. It would, however, be useful to
  document a workaround (perhaps in FAQ)


I fear we don't have FAQs;


Sorry, must have confused with Autoconf manual.

Cheers,
Peter

Re: bug#13524: Improving user experience for non-recursive builds

[Peter Johansson]

On 2/4/13 9:33 PM, Stefano Lattarini wrote:

What about doubling the curly braces?  As in '{{RELDIR}}'.
Would that be tolerable?  Other possibilities (none particularly
pleasant either, IMHO):

   {+RELDIR+}
   {:RELDIR:}
   {.RELDIR.}
   {-RELDIR-}

Other proposals?

Using Automake's namespace, 'AM_', comes to mind: {AM_RELDIR}.

cheers,

--
Peter Johansson

Re: serial-tests option and backwards compatibility

[Peter Johansson]

On 02/04/2013 11:31 PM, Stefano Lattarini wrote:

On 02/04/2013 01:16 AM, Luke Mewburn wrote:

[CUT]

Especially when the time between previous major releases was 2.5 years.

Examining the Changelog and release dates:

  2009-12-08  Release automake 1.11.1

  2012-02-21  Add serial-tests support (in HEAD)

  2012-04-13  Release automake 1.11.5 (without serial-tests)

  2012-05-18  Parallel tests now the default (in HEAD, not 1.11.x)

  2012-06-01  Release automake 1.12.1 (with serial-tests)


When I did this, I should really have published a 1.11.x release offering
this same option as well; that would have removed all confusion.  Sigh,
such a low-hanging fruit not picked :-(


I disagree. IMVHO micro releases should only fix bugs and not introduce 
new features, i.e., versions within 1.11.x should be both back and 
forward compatible.


The way to avoid these problems would have been to let the fruit sit 
there for, say 3-5 years, and then change the default value.



  2013-01-01  Release automake 1.13.1 (parallel tests now default)


This isn't the only backwards incompatible change made recently,
and in my humble opinion I think the timeframes introducing
backwards incompatibility are too aggressive.


You are not the only one to think so, and I've come to agree (at least
partially); for some more discussions and background, see:

   http://lists.gnu.org/archive/html/automake/2013-02/msg1.html
   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578

So things should proceed more carefully in the future (I hope).


In hindsight, I'm surprised no one objected to your aggressive changes.




 From a backwards-compatibility point of view, I think the default
should be reverted to serial tests, and make it clearer that
parallel tests are available as an option.


With this I must disagree, sorry.


I agree with your disagreement ;) flip-flopping back and forth would 
cause complete confusion and chaos. It would, however, be useful to 
document a workaround (perhaps in FAQ) how to support serial-test using 
both Automake 1.11 and Automake 1.13. Is there such a workaround?


Cheers,
Peter

bug#13378: Backward-compatibility in the autotools

[Peter Johansson]

On 01/12/2013 04:45 AM, Stefano Lattarini wrote:

As a rule of thumb on when to remove a macro - I would personally like
  being able to write a configure script that works on both RHEL 5 (or
  CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
  automake 1.14 and beyond), for as long as RHEL 5 remains a viable
  Enterprise-level distro.


I'm quite unconvinced of the value in trying to support this.  Developers
should just keep their tool reasonably up-to date IMHO; if they can't
do so through their package manager, they should do so by installing
from source.
Keeping autotools might be trivial in one-man-projects, but imposing 
that kind of requirement in larger teams is just causing head ache and 
friction, as most members wouldn't barely know what autotools are and 
even less interested in spending any time on upgrading tools that should 
just work under then hood.


Cheers,
Peter

Re: bug#13378: Backward-compatibility in the autotools

[Peter Johansson]

On 01/12/2013 04:45 AM, Stefano Lattarini wrote:

As a rule of thumb on when to remove a macro - I would personally like
  being able to write a configure script that works on both RHEL 5 (or
  CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
  automake 1.14 and beyond), for as long as RHEL 5 remains a viable
  Enterprise-level distro.


I'm quite unconvinced of the value in trying to support this.  Developers
should just keep their tool reasonably up-to date IMHO; if they can't
do so through their package manager, they should do so by installing
from source.
Keeping autotools might be trivial in one-man-projects, but imposing 
that kind of requirement in larger teams is just causing head ache and 
friction, as most members wouldn't barely know what autotools are and 
even less interested in spending any time on upgrading tools that should 
just work under then hood.


Cheers,
Peter

bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default, and only available one

[Peter Johansson]

Hi Stefano,

On 01/08/2013 08:18 AM, Stefano Lattarini wrote:

Actually no, the change tend to be much more extensive (as they've been
between 1.12 and 1.13, not always smoothly or pleasantly).  Maybe, to make
this clear, we should name release a 2.0 version instead of a 1.14?
No need, IMHO. Perhaps a brief document communicating what could be 
expected between versions such as a Makefile.am that works with 
Automake 1.14 will also compile with Automake 1.14.1; new warning might 
get introduced though But OTOH there are perhaps more important 
things to do than writing policies.


Cheers,
Peter

Re: Help2man and Parallel Make Race

[Peter Johansson]

On 11/20/12 8:44 AM, Neil T. Dantam wrote:

  That's the route that GNU coreutils has taken recently; in the unlikely
  case perl is absent on the the build system, dummy man-pages are
  generated.

This would also not work when cross-compiling, I think, since manpages
would always be regenerated when the binaries are built and the
cross-compiled binaries would not run on the build machine.

We decided we didn't wanted to ship (or require help2man), so when we 
converted to non-recursive Makefile, we solved this problem by added 
dependency


foo.1: foo$(EXEEXT)

but this dependency is only turned on if foo.1 is not present (at 
configure time) or if '.svn' is present. The latter indicating that we 
are not building from a tarball. These conditions are checked at 
configure time and propagated to the makefile via an AM_CONDITIONAL.


I'm not 100% happy with this solution though because it creates a 
different dependency graph for maintainers and users similar to 
AM_MAINTAINER_MODE.


Cheers,
Peter

--
Peter Johansson

Re: looking for a good example of non-recursive Make using project

[Peter Johansson]

On 11/20/12 7:16 AM, Bob Friesenhahn wrote:
A good paradigm for non-recursive make is to put Automake include 
fragments into each directory which support the files in that 
directory.  The top Automake.am then includes these fragments.  It 
would be useful if there was a syntax whereby the necessary 
subdirectory paths could be automatically inserted into Makefile 
variables and file paths based on the location of the Automake include 
file. 
That sounds like a good idea. That's exactly the setup I've ended up 
when changing from recursive to non-recursive Makefile. I also, however, 
often have Automake fragments in a directory 'am/' which are included 
into Makefile.am [in topdir]. For those fragment files, it would 
probably be confusing if paths were inserted into variables. Perhaps one 
could have a switch to turn that feature on.


Cheers,
Peter

--
Peter Johansson

Re: how to specify compile_et command in makefile.am

[Peter Johansson]

On 10/31/2012 04:57 PM, Coly Li wrote:

Is there any method that I can add something into Makefile.am, so that the 
generated Makefile can looks like:
--
foo_err.c foo_err.h: foo_err.et
compile_et prof_err.et
--



Sure add just that to Makefile.am and it should be copied to Makefile.

Peter

Re: [Automake] Including Shared Objects and other files in Makefile.am

[Peter Johansson]

On 10/03/2012 02:15 PM, Sujit Devkar wrote:

Dear Sir/Madam,

I am working on a C++ project in which I am trying to use autotools to 
make my project easy to deploy.
I have some .so files in a directory and some other files in different 
directory.
Before using autotools, I had a shell script to include files using 
options [ I ] and [ L ] as

g++ -I /usr/abc/inc -L /usr/dia/lib ...


Add

AM_CPPFLAGS = -I/usr/abc/inc

AM_LDFLAGS = -L/usr/dia/lib

and Automake should do what you expect (hopefully).

HTH,
Peter

help2man rule with non-recursive Makefile

[Peter Johansson]

Hi,

As I'm trying to convert to non-recursive Makefiles in my projects, I 
bumped into a problem that have been seen by many, so I wonder what the 
best solution is. The problem is that I have a rule to build the man 
page that looks like this:


# We would like to depend on binaries, but since svndigest.1
# is distributed it is recommended to depend on only distributed files
# (see automake manual 27.5).
# We depend on configure to catch VERSION changes, Makefile.in to
# catch rules changes, svndigest.x is an obvious dependency, and
# lib/.revision changes for every revision.
man_deps=$(top_srcdir)/configure $(srcdir)/Makefile.in \
$(srcdir)/man/svndigest.x $(top_srcdir)/.revision


$(srcdir)/man/svndigest.1: $(man_deps)
@$(HELP2MAN) --no-info -o $@ \
--include $(srcdir)/man/svndigest.x \
--version-option=--no-verbose --version \
$(top_builddir)/bin/svndigest$(EXEEXT)

This was never a problem because this rule was in directory 'man', which 
was traversed after 'bin' and 'bin/svndigest' existed. Converting this 
setup to a non-recursive Makefile, this assumption and no longer true, 
and in my first [naive] attempt, of course, I bumped into the problem 
that the rule was triggered before 'bin/svndigest' was built. What is 
the wisest solution for this problem? I can see that one could move the 
rule out from 'make all' or that one have different rules depending on 
building from VCS or tarball. Any thoughts?


Cheers,
Peter


--
Peter Johansson

Re: help2man rule with non-recursive Makefile

[Peter Johansson]

On 9/30/12 8:27 PM, Peter Johansson wrote:

Any thoughts?

I should read the manual before making noise. Sorry.

http://www.gnu.org/software/automake/manual/automake.html#Errors-with-distclean

--
Peter Johansson

bug#12495: AC_CONFIG_HEADERS with

[Peter Johansson]

On 9/24/12 6:18 PM, Hib Eris wrote:

Hi Peter,

Thanks for looking into this.

On Mon, Sep 24, 2012 at 8:29 AM, Peter Johanssontroj...@gmail.com  wrote:

I have the setup you describe, and I have not encountered the problem you
describe.

I have AC_CONFIG_HEADERS([config.h lib/config_public.h])

and there is no rule to create 'lib/config_public.h.in'. Am I missing
something?

I have attached an example setup.
After running 'autoreconf -fi', I get a lib/Makefile.in with an rule
to create $(srcdir)/config-public.h.in calling $(AUTOHEADER).


Yes, this looks like a bug IMVHO. The difference between your setup and 
mine is that I only have one Makefile. But I just recently converted to 
non-recursive makefiles, and haven't noticed this bug, which suggests 
this is a recent regression (1.12???).


Cheers,
Peter

--
Peter Johansson

should aclocal warn when picking up installed macros???

[Peter Johansson]

Hi,

I just helped a co-developer who experienced a mysterious

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory c++ to autoreconf
autoreconf: Entering directory `c++'
autoreconf: configure.ac: not using Libtool
autoreconf: running: /opt/local/bin/autoconf --force
configure.ac:43: error: possibly undefined macro: AC_MSG_FAILURE
  If this token and others are legitimate, please use 
m4_pattern_allow.

  See the Autoconf documentation.
autoreconf: /opt/local/bin/autoconf failed with exit status: 1


Line 43 in c++/configure.ac contained

YAT_CHECK_YAT([0.9.1], [], [AC_MSG_FAILURE([no yat found])])

which is a macro defined in c++/m4/yat.m4. After some investigation I 
realized the problem is that aclocal doesn't find 'yat.m4' and adding


ACLOCAL_AMFLAGS = -I m4

in c++/Makefile.am solved the problem as expected. The annoying thing is 
that I did not see this problem because my aclocal finds yat.m4 under 
/usr/local. I'm not sure what I'm asking for here, but it would be nice 
if I could have aclocal complain somehow in this scenario. Is it 
possible to tell aclocal to only pick up local files that it can 
m4_include into aclocal.m4? Only time I really wanna pick up installed 
m4 files is when I issue 'aclocal --install -I m4', or am I misusing 
aclocal?


Thanks,
Peter

Re: using $(wildcard) in EXTRA_DIST

[Peter Johansson]

On 09/19/2012 04:23 PM, Vincent Torri wrote:

Hey

our documentation provides some images files in a subdirectory  'img'.
So, in EXTRA_DIST, we have added:

$(wildcard $(srcdir)/img/*.*)

automake reports that warning:

doc/Makefile.am:35: wildcard $(srcdir: non-POSIX variable name
doc/Makefile.am:35: (probably a GNU make extension)

what is the correct way to add all the files, without listing them all
in EXTA_DIST ?


I would add $(srcdir)/img in EXTRA_DIST and then remove unwanted files 
with a dist-hook rule. But it sounds a bit fragile to me.


Cheers,
Peter

bug#12130: Fwd: bug#12130: sudo make install applies umask to new directories

[Peter Johansson]

[CC coreutils this is 
http://lists.gnu.org/archive/html/bug-automake/2012-08/msg1.html]


On 09/14/2012 07:29 PM, didi wrote:

You can already do this. You can, e.g., install packages with
  
  make install MKDIR_P=mkdir -p -m 700

Unfortunately this doesn't seem to work properly, as the parent directories
still retain the permissions of the user.

$ mkdir -p -m 755 foo/bar

drwx-- foo/
drwxr-xr-x bar/





Hi Didi,

That was unexpected and unfortunate IMVHO. I see the same behaviour on 
my local system, in other words,


mkdir -p -m 700 /tmp/foo/bar

creates bar with permissions 700 and bar with 776 (my umask). I wonder 
is that behaviour is mandated by some standard or if there is room for 
improvement in coreutils here (CC:ed).


Thanks,
Peter

bug#12130: Fwd: bug#12130: sudo make install applies umask to new directories

[Peter Johansson]

On 08/21/2012 02:46 PM, Jason Eisner wrote:

Better idea:

Have default 644 for files and 755 for directories, but let the user 
override this by explicitly specifying any of

* the desired file permissions
* the desired directory permissions for newly created directories
* the desired group owner for newly created files and directories
via command-line options on make install.



You can already do this. You can, e.g., install packages with

make install MKDIR_P=mkdir -p -m 700

Cheers,
Peter

distinguish automake 1.11 from 1.12+ at autoconf time

[Peter Johansson]

Hi,

I'd like to distinguish automake 1.11 from 1.12 (or later) at autoconf 
time. I wonder is there's any documented macro that was introduced in 
1.12 that I could use to m4_ifdef?


Cheers,
Peter

Re: distinguish automake 1.11 from 1.12+ at autoconf time

[Peter Johansson]

Hi Eric,

On 08/07/2012 09:36 AM, Eric Blake wrote:

On 08/06/2012 05:29 PM, Peter Johansson wrote:

Hi,

I'd like to distinguish automake 1.11 from 1.12 (or later) at autoconf
time. I wonder is there's any documented macro that was introduced in
1.12 that I could use to m4_ifdef?

If nothing else, the autoconf philosophy of feature checks being better
than version checks should guide your decision here.

What _specific_ feature are you using from 1.12 that wasn't present in
1.11?
Not really a feature but more of a bug that was fixed in 1.11.3 and 
described as follow in the 'NEWS':


The deleted header file problem for *.am files is avoided by stub
rules.  This allows `make' to trigger a rerun of `automake' also if
some previously needed `.am' file has been removed.

  Or put another way, either your configure.ac works equally well
with both versions (so you don't care which version), or there's
something you do with 1.12 that doesn't work with 1.11 and therefore you
are trying to make it conditional so that 1.11 can still process the
rest of the file.  Determine that feature, and we are that much closer
to helping you conditionalize your configure.ac to work with both versions.

I have a macro that generates .am snippets that are then included in 
Makefile.am. Currently the macro includes this in the output:


# stub rule to work around bug in Automake 1.11
\$(top_srcdir)/]$1[:

I was hoping to clean up this and only include it conditionally, but 
writing a feature test that runs at autoconf time seems more error 
prone. It's just a cosmetic fix anyway... and I should perhaps find 
better things to do;)


Cheers,
Peter

bug#12064: distclean failure with Automake 1.12.2

[Peter Johansson]

Hi automakers,

I was about to make a release when I discovered that distcheck suddenly 
didn't work anymore. The distclean rule failed with


Making distclean in doc
make[2]: Entering directory 
`/home/peterJo/projects/software/yat-0.8.x/yat-0.8.2/_build/doc'
Makefile:498: ../yat/classifier/doxygen.mk: No such file or directory
Makefile:499: ../yat/normalizer/doxygen.mk: No such file or directory

This was for a stable branch release so there had just been minor 
changes in two .cc files and no changes at all wrt the build system. 
After some investigation I found that Automake 1.12.2 has changed the 
order directories are traversed for clean rules. I must say I find it 
unexpected that behaviour like this is changed between 1.12.1 and 
1.12.2. I thought this kind of changes were only introduced when bumping 
versions from say 1.11 to 1.12 and not between stable releases.


The reason I got the failure is that files doxygen.mk are included into 
doc/Makefile. These files are generated in the corresponding Makefile 
and listed under DISTCLEANFILES so they are deleted during 'make 
distclean'. As SUBDIRS in top Makefile.am is SUBDIRS = doc yat that was 
not a problem before since doc was entered first during cleaning and 
doc/Makefile was already gone when the doxygen.mk files were removed. 
Perhaps a strange use case, but still I wanted to report it.


I think I've found a workaround so I can get out the release without 
needing to downgrade Automake.


Thanks,
Peter

Re: files left in build directory after distclean

[Peter Johansson]

On 05/30/2012 02:09 AM, Adam Mercer wrote:

On Wed, May 23, 2012 at 6:13 PM, Peter Johanssontroj...@gmail.com  wrote:


For me distcheck complains about no sed file which is because you call it
'sed -f git_version.sed' while it should be 'sed -f
$(srcdir)/git_version.sed' as the sed script is distributed (in srcdir).

But the script copies git_version.sed to $(builddir), and updates it
if appropriate,


That doesn't happen:

[peterJo:~/tmp/foo-0.1]$ mkdir build
[peterJo:~/tmp/foo-0.1]$ cd build
[peterJo:~/tmp/foo-0.1/build]$ ../configure
checking for a BSD-compatible install... /usr/local/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for gcc option to accept ISO C99... -std=gnu99
checking whether make supports nested variables... yes
checking for a Python interpreter with version = 2.6... python
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory... 
${prefix}/lib/python2.6/site-packages
checking for python extension module directory... 
${exec_prefix}/lib64/python2.6/site-packages

checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
[peterJo:~/tmp/foo-0.1/build]$ make V=1
/usr/bin/python ../generate_vcs_info.py .. $PWD
sed -f git_version.sed ../git_version.h.in  git_version.h.tmp
sed: couldn't open file git_version.sed: No such file or directory
make: *** [git_version.h] Error 4


so I want to use the version in $(builddir). Forcing
the use of the version in $(srcdir) could lead to incorrect version
information.


To have files with same name in both builddir and srcdir is to ask for 
problems, IMHO. What happens if srcdir and builddir are the same?


If you wanna generate $(builddir)/git_version.sed, don't distribute it 
as well. Or distribute it (in $(srcdir)) and don't generate it in 
$(builddir). Or distribute it but let the generated have a slightly 
different name. Btw, is the distributed script ever used if you intend 
to generate one anyway?


Cheers,
Peter

Re: files left in build directory after distclean

[Peter Johansson]

On 05/24/2012 02:59 AM, Adam Mercer wrote:


Hmm, distcheck is still complaining. I've attached a tarball
containing a striped down version of my project which illustrates the
problem. Can anyone see what I'm doing wrong?



Hi Adam,

For me distcheck complains about no sed file which is because you call it
'sed -f git_version.sed' while it should be 'sed -f 
$(srcdir)/git_version.sed' as the sed script is distributed (in srcdir).


Cheers,
Peter

Re: files left in build directory after distclean

[Peter Johansson]

Hi Adam,

On 05/24/2012 02:59 AM, Adam Mercer wrote:

On Wed, May 23, 2012 at 10:03 AM, Adam Mercerramer...@gmail.com  wrote:


Is 'git_version.sed' intended to be distributed?  If yes, you must place it in
EXTRA_DIST (and you have an usage error in that you've not done so).

Of course! Thanks, I imagined it'd be due to something trivial like that.

Hmm, distcheck is still complaining. I've attached a tarball
containing a striped down version of my project which illustrates the
problem. Can anyone see what I'm doing wrong?


By the way, I don't know your exact circumstances, but for me I got rid 
of a lot of head ache when I started building source files (.c) rather 
than header files (.h). The Automake manual discusses different 
approaches for building source code very well


http://www.gnu.org/software/automake/manual/automake.html#Sources

Cheers,
Peter

Re: bug#11356: automake 1.12 and (C) 2011

[Peter Johansson]

Hi Stefano,

Sorry about this late reply.

On 04/28/2012 12:34 AM, Stefano Lattarini wrote:

--- a/bootstrap
+++ b/bootstrap
@@ -77,6 +77,8 @@ dosubst ()
 {
   rm -f $2
   in=`echo $1 | sed 's,^.*/,,'`
+  current_year=`date +%Y`  test -n $current_year \
+|| { echo $me: cannot get current year2; exit 1; }
   sed -e s%@APIVERSION@%$APIVERSION%g \
   -e s%@PACKAGE@%$PACKAGE%g \
   -e s%@PERL@%$PERL%g \
@@ -84,6 +86,7 @@ dosubst ()
   -e s%@SHELL@%$BOOTSTRAP_SHELL%g \
   -e s%@VERSION@%$VERSION%g \
   -e s%@datadir@%$datadir%g \
+  -e s%@RELEASE_YEAR@%$current_year%g \
   -es%@configure_input@%Generated from $in; do not edit by hand.%g  \
   $1  $2
   chmod a-w $2
diff --git a/configure.ac b/configure.ac
index 22a158f..2829fd4 100644


IIUC, this implies that if I choose to boostrap Automake 1.12.1, in say, 
five years, $RELEASE_YEAR will be set to 2017. I'm not an expert on what 
these copyright years mean [legally], but I find this a bit odd as 
nothing has changed the last five four years (depending on when 1.12.1 
will be released). In my projects, I've used an approach that updates 
the copyright year only when something is modified according to the VCS. 
With subversion this is trivial and I suspect it wouldn't be harder with 
git. I store this information in a separate file, '.release_year', which 
is extracted at configure time although, in theory, it could be done at 
autoconf time, I guess.


Cheers,
Peter

Re: Wait, isn't rpath supposed to be set automagically?

[Peter Johansson]

On 2/26/12 11:31 PM, Miles Bader wrote:

I think it's desirable that it just work wherever it gets installed,
and no matter who installs it (e.g. prefix=$HOME should work, and
shouldn't require setting LD_LIBRARY_PATH).

In my case it did work with prefix=$HOME because in that case -rpath was 
set. Have you tried with ./configure --prefix=$HOME?


Cheers,
Peter

Re: Automake 1.11.1b test release

[Peter Johansson]

On 12/17/11 11:10 AM, Adam Mercer wrote:

On Sat, Dec 10, 2011 at 13:03, Stefano Lattarini
stefano.lattar...@gmail.com  wrote:


Please report bugs and problems tobug-autom...@gnu.org, and send
general comments and feedback toautomake@gnu.org.

On Mac OS X 10.7 (Lion)

All 826 tests behaved as expected (11 expected failures)



Similar on Mac OS 10.4:


All 865 tests behaved as expected (11 expected failures)
(46 tests were not run)


Cheers,
Peter

Re: minor error and a question

[Peter Johansson]

On 11/30/11 11:11 AM, Joakim Tjernlund wrote:

Question: make install always install all targets, even if some of then 
haven't been rebuilt
since last install. Is it possible to have some dependency sensitive install so 
only rebuilt
targets are reinstalled?

Hi Jocke,

In one of my projects I have the following snippet in top Makefile.am

# like the normal install target, but does not update header files
# (and their time stamps) if the content did not change.
install-modified:
$(MAKE) install $(AM_MAKEFLAGS) INSTALL_HEADER=$(install_sh_DATA) -C


It's useful when installing frequently and wanna avoid recompilations in 
downstream projects, but note that the install takes a bit longer time 
since it needs to compare all files to decide whether it should be 
copied instead.


It would be faster to use the time-stamp to make that decision but when 
I looked into it, it seemed dangerous. Unfortunately, I cannot remember 
the details from top of my head.


Cheers,
Peter

Re: Could automake-generated Makefiles required GNU make?

[Peter Johansson]

On 11/24/11 11:40 AM, Bob Friesenhahn wrote:

On Thu, 24 Nov 2011, Peter Rosin wrote:


There is one possibly hard bootstrapping problem. What if you want to
deploy some package that does not need a C compiler on some system that
lacks both a C compiler and GNU Make? You would have problems there for
sure. Some number-crunching fortran-centric piece comes to mind, or some
locked down financial system where a cobol compiler or something is
present, but no C compiler.


Is it possible to run baseline Autoconf configure without a working C 
compiler?  Automake depends on Autoconf.



Hi Bob,

You already know this, of course, but this is not about running 
Automake; this is about building projects that have Automake generated 
Makefile.in. You don't need Autoconf to accomplish this but only 
whatever is required for './configure  make' to work.


Thanks,
Peter

bug#9242: distcheck fails when having TEST in sub-directory

[Peter Johansson]

Hello automakers,

I have a non-recursive Makefile.am but keep the tests in sub-directory named
test. Surprisingly distcheck fails for me with this set up, which to me
seems to be caused by some VPATH issue.

Below is a trimmed down test case that fails for me with

make  check-TESTS
make[2]: *** No rule to make target `test/foo.test', needed by
`check-TESTS'.  Stop.
make[1]: *** [check-am] Error 2
make: *** [distcheck] Error 1


cat  configure.ac EOF
AC_INIT([foo], [1])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

cat  Makefile.am EOF
TEST_EXTENSIONS = .test
TESTS = test/foo.test
EOF

mkdir -p test
cat  test/foo.test EOF
echo hello world
exit 0
EOF
chmod 755 test/foo.test

autoreconf -ivf
./configure
make all
make check
make distcheck

Is this a bug or am I doing something wrong?

I'm using Automake 1.11.1

Thanks,
Peter

Re: ./configure can't find Boost headers

[Peter Johansson]

On 7/26/11 4:13 PM, myrdos2 wrote:

I have the following configure.ac file:

This is more of an Autoconf issue, so you may have better luck asking on 
autoconf at...

# Checks for header files.
AC_CHECK_HEADERS_ONCE([boost/asio.hpp boost/bind.hpp boost/function.hpp
inttypes.h zlib.h])


Why not use the AX_BOOST_* macros provided here
http://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros


And it will compile, as long as I link with -lboost_system. What could the
problem be?

I've often been helped by looking in config.log

Cheers,
Peter

bug#9026: Supporting $ACLOCAL_PATH?

[Peter Johansson]

Hi Bruno,

On 7/8/11 5:24 PM, Bruno Haible wrote:

+If you are using GNU @code{automake} 1.10 or newer, it is even easier:
+Add the line
+
+@example
+ACLOCAL_AMFLAGS = --install -I m4
+@end example
+
+@noindent
+to your top level @file{Makefile.am}, and run @samp{aclocal --install -I m4}.
+This will copy the needed files to the @file{m4/} subdirectory automatically,
+before updating @file{aclocal.m4}.
+
I used to do this as it is an easy way to stay up to date with 3rd party 
m4 files. I stopped doing this, however, after Ralf Wildenhues made me 
aware there is a risk doing so. The risk is that aclocal will copy 3rd 
party m4 files into m4 not only for you but also for your users if they 
happen to run aclocal. Say, e.g., that a user want to build a somewhat 
old version of your package from git; he bootstraps and as he has newer 
versions of the m4 files available on his system aclocal copies them 
into m4, which may cause problems as they are not necessarily compatible 
with your configure.ac. To avoid this from happen, I've removed the 
--install flag from my packages and calls aclocal --install -I m4 
frequently instead.


There is, obviously, a risk doing this way, as mentioned above in this 
thread, because if I'm not careful I may release a tarball with missing 
m4 files. Would distcheck detect a missing m4 file, or would it be 
possible to modify distcheck so it could warn about this case?


Cheers,
Peter

bug#7988: the manual suggests installing macro files to hard-coded location

[Peter Johansson]

Hello Stefano,

On 3/19/11 8:36 AM, Stefano Lattarini wrote:

On Saturday 05 February 2011, Peter Johansson wrote:


I find the last sentence a bit strange because to me that sounds like
Automake suggests that packagers should install macro files in a
hard-coded directory not relative to $(prefix).


Yes, this is exactly what it suggests.  Unfortunately, this is currently
the best way to allow aclocal to find the installed third-pary macro file;
for more information see:
  http://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html

With the same logic, the best way to intall header files would be to ask 
gcc about its search path and intall header files where gcc will find 
them - typically in `/usr/local/include'.


I think this would be suboptimal and a better way to do it is to install 
headers in `$(includedir)' and have this set to `${prefix}/include' as 
default but also give the installer the freedom to change this location 
if desired at configure time or even at make time.


IMVHO, that approach works also for m4 files. Install m4 files in 
`$(aclocaldir)', whose default value is `${datadir}/aclocal'. If that 
happens to be a place aclocal never heard of, the user can always supply 
'-I' flags as needed.


On one system at work I have aclocal installed in `/usr/bin/' and since 
I'm not root I can not install stuff into `/usr' and would find it 
annoying if packages insisted on installing m4 files into 
`/usr/share/aclocal' although I configure with `--prefix=$HOME'. And on 
top of that distcheck typically fails if one tries to install things to 
a location outside the $(prefix) tree.




Another viable approach would be to install the third-party macro file
in `$(third-party-prefix)/share/aclocal', and then extend the file
`$(aclocal-prefix)/share/aclocal/dirlist' to list that directory too; but
this would mean *modify* a possibly pre-existing file (and in a hard-coded
location too), and I'm not sure this is a wise move (but maybe might be
worth citing in the documentation anyway... Opinions?)

IMVHO that doesn't sound like an improvement. Say that I, e.g., install 
an old version of GSL with --prefix=/usr/local/gsl-1.6. That doesn't 
mean I want aclocal to look for m4 files in 
`/usr/local/gsl-1.6/share/aclocal'. And what happens with all the times 
I install my own package within distcheck, would that prefix 
(`pwd`/_inst) also be added in `dirlist'?



Finally, note that this problem should be ameliorated once the pending
patches introducing support for the ACLOCAL_PATH environment variable
are merged:
  http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html
At that point, a thid-party package providing macro files can install them
into `$(third-party-prefix)/share/aclocal', and then tell the user to
extend the system-wide definition of ACLOCAL_PATH accordingly (somewhat
similarly to what libtool install rules does with `LD_LIBRARY_PATH').


Sounds good.

Thanks,
Peter

Re: aclocal only picking up /usr/local/share and not /usr/share

[Peter Johansson]

[removing automake-patches]

On 3/17/11 10:39 AM, Maynard Johnson wrote:



you aclocal calls.  Also, in the next automake release, aclocal
will probably support a new 'ACLOCAL_PATH' environment variable
that would help solving this kind of problems

Well, you could always resort to adding proper `-I' option to
Except this happens when building a 3rd party package.  Yes, I have 
the source for that package, and, in fact, the first fix I did was to 
update it's autogen.sh (where aclocal is called) to add '-I 
/usr/share/aclocal'.  But that didn't seem like the right way to go 
either for the general case (i.e., I don't think that's an appropriate 
fix to contribute back to the package maintainer). I think the best I 
can do is to suggest an FAQ on that package's web site that documents 
the error and the solution.



I always copy third party m4 files to directory $(top_srcdir)/m4 and add
AC_CONFIG_MACRO_DIR([m4])
in configure.ac and
ACLOCAL_AMFLAGS = -I m4
in top Makefile.am. In that way there is never any problem for aclocal 
to find the files. Even if a new co-developer checks out a new copy from 
VCS he will have no problem but can just run

./bootstrap
./configure...

without even knowing what aclocal or it each path is.

I read the Automake manual
http://sources.redhat.com/automake/automake.html#Local-Macros
as that is the recommended way to set up things.

Cheers,
Peter

Re: $(srcdir)/foo is not generated because $(srcdir)/$(srcdir)/foo exists

[Peter Johansson]

Thanks Ralf for your quick reply,

On 2/13/11 2:44 AM, Ralf Wildenhues wrote:

I would prepend all lines of a rule with a TAB, not just those not
following a backslash-escaped newline.  I'm actually not totally sure
whether that was for portability to non-Posix make or so automake would
parse things reliably.



Thanks for your suggestions; I've implemented them.

else
## this is needed in 'svn export' build
$(srcdir)/.revision:
 echo   $@

I don't see why you should need this rule here.  The .revision file is
distributed, so it should already exist.  At most I'd add a stub target

   $(srcdir)/.revision:

here.  Maybe I'm missing something?



There are three ways you can get and build the package:

1) retrieve package.tar.gz and './configure; make'

2) svn checkout http://package.org/svn and do './bootstrap; ./configure; 
make'


Subversion provides a third way which is

3) svn export http://package.org/svn and do './bootstrap; ./configure; make'

The svn export command is a way to get what subversion refers to as a 
clean tree, i.e., only the files committed to the repository and no 
`.svn' directories with information about which revision which branch or 
anything. To be honest I'm not sure about the usefulness of this 
feature, but that discussion belongs elsewhere.


Anyway, in my case above: if a user chooses to 'svn export', file 
.revision is not there because it is not checked into the repository. 
And we can not use subversion to figure out what `.revision' since the 
tree holds no such information. Therefore, if we wanna support svn 
export builds we need to create the file `.revision' somehow although 
it cannot contain any useful information.


After sending my email yesterday I chose to move the creation of 
.revision to Autoconf time. That is if there is no .revision and no .svn 
directory I create a dummy .revision. This also removed my original 
problem referred to in the subject.


Thanks again,
Peter