Re: Changing mkinstalldirs to avoid using mkdir -p
Nathanael Nerode [EMAIL PROTECTED] writes: +# Solaris 8's mkdir -p isn't thread-safe! If you mkdir -p a/b and +# mkdir -p a/c at the same time, both will detect that a is missing, +# one will create a, then the other will try to create a and die with +# a File exists error. So we have to disable this code on Solaris 8. +# +#case $dirmode in +# '') +#if mkdir -p -- . 2/dev/null; then +# echo mkdir -p -- $* +# exec mkdir -p -- $@ +#fi +#;; +# *) +#if mkdir -m $dirmode -p -- . 2/dev/null; then +# echo mkdir -m $dirmode -p -- $* +# exec mkdir -m $dirmode -p -- $@ +#fi +#;; +#esac Does anybody see a way to disable this only when needed? An idea would be to skip this code if 1. -$MAKEFLAGS matches ` -[BdeikrRsSw]*j' or ` ---?jobs' and 2. `mkdir -p --help' doesn't work. That way we would always GNU's mkdir -p, and we would ignore other mkdir -p implementations only in parallel builds. Unfortunately, the problem is not only in mkinstalldirs, it is also in AM_PROG_MKDIR_P, and we cannot check $MAKEFLAGS there. I presume we will end up setting `mkdir_p = mkdir -p' only if mkdir supports --help. I find this quite frustrating. If you consider a system such as Solaris 8, whose make does not support parallel builds, there is no reason not to use `mkdir -p'. The problem only exist when users mix tools, doesn't it? It's a bit of a shame, we have to disable `mkdir -p' everywhere because of such setups. Other ideas? -- Alexandre Duret-Lutz
installing headers files in /usr/local/include...
Hello all, I have written (I am still writing actually) an application and use automake/autoconf. I would like to have my headers to be installed under /usr/local/include when applying make install. I wonder if someone can help me how to reach this with automake. Thanks for any contribution.
Re: installing headers files in /usr/local/include...
Eric Tchepannou [EMAIL PROTECTED] writes: Hello all, I have written (I am still writing actually) an application and use automake/autoconf. I would like to have my headers to be installed under /usr/local/include when applying make install. I wonder if someone can help me how to reach this with automake. include_HEADERS = Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
AM_INIT_AUTOMAKE Call in Automake 1.7
Hi, everyone, Replies I got from this group with regards to a problem I was having in my build environment (that used Automake 1.4) led me to request a version upgrade. I am now able to use Automake 1.7. (Better, eh?) After running automake on my existing configure.in, I received the following error: quote configure.in:10: your implementation of AM_INIT_AUTOMAKE comes from an configure.in:10: old Automake version. You should recreate aclocal.m4 configure.in:10: with aclocal and run automake again. /quote This surprises me, because I made the changes to my configure.in as specified in the online documentation: quote If your configure.in has: AC_INIT(src/foo.c) AM_INIT_AUTOMAKE(mumble, 1.5) you can modernize it as follows: AC_INIT(mumble, 1.5) AC_CONFIG_SRCDIR(src/foo.c) AM_INIT_AUTOMAKE /quote My old format (AM_INIT_AUTOMAKE(package, version)) failed, and now the new format is failing with Automake 1.7, as well. What is the correct usage of this macro call? Thanks, Scott
RE: AM_INIT_AUTOMAKE Call in Automake 1.7
From: [EMAIL PROTECTED] I'm not sure, but I think another possibility might be that the right aclocal program is still finding the old 1.4 macros. Hmmm... I think you're on to something. The previous build owner added some additional macros to the default source of aclocal macros. He put them in m4 files in the same directory. As such, when I have the new aclocal point to the new macro source location (using --acdir), autoconf fails (additional macros not found). When I have it point to the old source, automake fails (AM_INIT_AUTOMAKE fails). I've tried playing around with different combinations (and sequences) of --acdir and -I, hoping that I could get an invokation that would get the 1.7 macros and the original ones provided by the build maintainer, to no avail. It seems that as long as the original --acdir directory is specified (either with --acdir or -I), automake fails with the same problems. Any ideas on how I can just use the right files in the old aclocal config directory? FWIW, the brute force method of copying out all files that the previous owner added to the aclocal config directory to another directory does work. So, I have a solution to this problem, and am on to another one. Also, what exactly is the difference between --acdir and -I? Thanks, Scott
