Re: Producing MS Developer Studio Project files
Hi Benoit, Benoit SIGOURE wrote: [1] http://www.tsunanet.net/~tsuna/cccl [2] http://www.tsunanet.net/~tsuna/make-3.81-cygwin.patch http://www.tsunanet.net/~tsuna/make-3.81-cygwin_MAKE_expansion.patch Can't be bothered to find the related posts on GNU Make W32 ML archive, sorry. It seems that the last 2 links don't work. It said Forbidden You don't have permission to access /~tsuna/make-3.81-cygwin_MAKE_expansion.patch on this server. Regards Harri
Re: 'toolman_MANS' not supported?
Hi Ralf,
Ralf Wildenhues wrote:
Hello Harald,
* Harald Dunkel wrote on Mon, Apr 30, 2007 at 01:04:25PM CEST:
I have to install several manpages in separate
subdirectories. But it seems that something like
toolmandir = ${prefix}/tooldir/man
toolman_MANS = hello.1
does not work. Did I miss something in the documentation
here? (I am using Automake 1.9.6.)
I think http://sources.redhat.com/automake/automake.html#Man-pages
states that only manSECTIONdir is allowed, for a valid section named
SECTION.
Maybe you would agree that it is very easy to misunderstand
this part? The other primaries (e.g. DATA, SCRIPTS) do accept
a real directory variable, and yet the docu usually mentions
just bin_PROGRAMS.
I'd be curious as to what advantage there is to install manpages in a
location where the man program will not find them by default?
I am creating several binary modules from a single set of
source files. The generated code is supposed to be
installed in ${prefix}/mod1, ${prefix}/mod2, etc. Each
mod? directory becomes a seperate binary module (using
dpkg).
Of course these binmodules can (optionally) be installed
in a common directory tree later, as needed. But it is
important that the man pages are part of the binary modules
they belong to.
Currently I install the man pages using tooldir_DATA, of
course. Do you think it would be difficult to replace the
hardwired 'man' in automake.pl by a directory variable?
Regards
Harri
'toolman_MANS' not supported?
Hi folks,
I have to install several manpages in separate
subdirectories. But it seems that something like
toolmandir = ${prefix}/tooldir/man
toolman_MANS = hello.1
does not work. Did I miss something in the documentation
here? (I am using Automake 1.9.6.)
Regards
Harri
depcomp supporting MSVC's --showIncludes?
Hi folks, Does anybody know a patch for depcomp to support the -showIncludes flag of Microsoft's recent compiler? Regards Harri
Re: using VPATH in depend2.am?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Stepan,
Maybe you remember this story about correctly searching for
the files to compile looking at VPATH. I am using it for
quite some time without problems.
Do you think that this change could be included in a future
version of Automake?
Regards
Harri
===
Stepan Kasal wrote:
Hello,
On Fri, Oct 21, 2005 at 10:58:44PM +0200, Harald Dunkel wrote:
Stepan Kasal wrote:
`IFS=:; x=':$(VPATH)'; \
for d in $$x; do \
test -n $$d d=$$d/; \
test -f $${d}%SOURCE% echo $$d break;
done`%SOURCE%
I like this version.
well, I don't. :-)
I made at least two mistakes:
1) test -n $$d -- this is not correct when $d is empty.
2) x=':$(VPATH)' -- when VPATH is empty, the loop is run twice.
But if you look at the original depend2.am
in am 1.9.6, there were some tics around %SOURCES%, [...]
yes, they are there, but not consistently. There are things like
`test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
Unless we want to support whitespace or dollars in %SOURCE%, there is no
benefit from these quotes. It's better to omit them, the code is more
readable then. (The whole long line goes displayed by make.)
By the same reasoning, there is no benefit from the quotes around $(VPATH).
Suggested code for today: ;-)
`IFS=:; v=$(VPATH); \
for d in '' $$v; do \
test -n $$d d=$$d/; \
test -f $${d}%SOURCE% echo $$d break; \
done`%SOURCE%
It's tempting to have:
`IFS=:; v=$(VPATH); \
test -f %SOURCE% || \
for d in $$v; do test -f $${d}/%SOURCE% echo $$d/ break; \
done`%SOURCE%
but it seems that
a=
for f in $a; do ... done
is not interpreted correctly by some shells. The Autoconf manual doesn't
document it but Autoconf contains workaround for it. I'll ask at the
Autoconf list whether this is a myth or not.
Have a nice day,
Stepan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE6MtkUTlbRTxpHjcRAkgJAJ94O1bFHhcKCZODD+rR5fNO2MoUMwCePNTI
UhH3ETcJU1/YL1Fpz/Gbx+c=
=9dpz
-END PGP SIGNATURE-
question about DEFAULT_INCLUDES and -I.
Hi folks, it seems that DEFAULT_INCLUDES is set deeply within automake.pl to DEFAULT_INCLUDES = -I. -I$(srcdir) What is the reasoning here? Doesn't this undermine the difference between #include myheader.h and #include myheader.h ? Regards Harri
Re: question about DEFAULT_INCLUDES and -I.
Hi Ralf, Ralf Wildenhues wrote: Hi Harald, * Harald Dunkel wrote on Wed, Apr 26, 2006 at 10:44:55AM CEST: it seems that DEFAULT_INCLUDES is set deeply within automake.pl to DEFAULT_INCLUDES = -I. -I$(srcdir) Only if not using the Automake option `nostdinc'. I did not see this. I will try. Many thanx Harri
Re: autotools support for msvc
Hi Peter, Peter Ekberg wrote: Here's my current diff from libtool cvs head. I have been buried in work lately so I have not tested it in a while. Use at your own risk and all that... Many thanx. Harri
Re: useful bug reports
Hi Ralf, Ralf Wildenhues wrote: Erm. Before continuing on this road any further: have you tried using cccl? It's a wrapper script for MSVC designed to do exactly what looks like quite a bit of work inside the autotools. I'm not saying it can't be done, or should not be done, but it has been done already, and you won't have to wait for it (unless there are bugs, of couse) . ;-) http://cccl.sourceforge.net/ I had found wrapmsvc.exe, but I did not know this cccl yet. Will check. There might be yet another problem with supporting msvc: Bill's libraries are not built by 'ar cru', either. AFAIK they have to be built using link.exe, e.g. link.exe /lib /OUT:libmylib.lib foo.obj bar.obj Please note the missing space between '/OUT:' and the library name. The command line to build *.dll might be different. Currently I am using a small wrapper 'winar' for building libraries for msvc, and I redefine AR=winar ARFLAGS= Regards Harri #!/bin/bash # # link.exe /lib /OUT: # exec link.exe /lib /OUT:$@
Re: useful bug reports
PS: Sorry, I pasted the wrong Makefile.am into the EMail, see below. Harald Dunkel wrote: Hi Ralf, Ralf Wildenhues wrote: Harald, please consider *providing more and useful information* if you want help. I for one can't read your mind, and almost every first post of yours leaves me wanting for a crystal ball as to what has gone wrong. This makes me for one be less and less enthusiastic about replying. With newbies, or people where I do not know whether they are newbies or not, one cannot expect more, at least the first couple of times they post. But you bee given hints before. This is no service hotline. I heartily recommend reading this (available in several languages): http://www.chiark.greenend.org.uk/~sgtatham/bugs.html We have now again wasted 5 messages without getting to the point of the problem you encounter: I still have no clue what's going wrong on your side, and I bet you aren't happy about the situation either. Sorry for not being more precise. Here is a sample. #configure.ac: AC_INIT(package,version) AC_CONFIG_AUX_DIR([.]) AC_CANONICAL_HOST AM_INIT_AUTOMAKE([foreign subdir-objects no-define]) AC_PROG_CC AC_PROG_CPP AC_AIX AC_ISC_POSIX AC_MINIX AC_PROG_INSTALL AC_PROG_CXX AC_PROG_CXXCPP AC_PROG_RANLIB AC_HEADER_STDC AM_PROG_CC_C_O AM_PROG_LEX AC_PROG_YACC AC_CONFIG_FILES([Makefile]) AC_OUTPUT #Makefile.am: noinst_PROGRAMS = hello hello_SOURCES = hello.cxx Should be #Makefile.am noinst_PROGRAMS = hello hello_CPPFLAGS = -I/somedir hello_SOURCES = hello.cxx Autoconf is 2.59, plus Stepan's patch for c.m4, see attachment Automake is 1.9.6 platform is Linux build platform is Windows, using MSVC 7.1. The patch provided by Stepan some months ago fixes AM_PROG_CC_C_O for Windows and MSVC, i.e. configure recognizes that -c -o doesn't work as expected for Bill Gates' compiler. Looking into the generated Makefile I see CC = /somedir/compile cl.exe The compile script is necessary for both C and C++ code. But it is not copied by Automake. Nor does it set CXX accordingly. in the Makefile. The patch I had sent was an attempt to workaround the problem, but it is not sufficient. Any help would be highly appreciated. Regards Harri
[Patch] Re: compile not copied? Why?
Hi folks, Harald Dunkel wrote: Hi folks, What is the criteria for copying the compile script into the source directory tree? I have some *.cc code, it is mentioned in my Makefile.am file, configure detects that the compile script must be used, too, but Automake doesn't provide it. It seems that the compile script is only copied, if you have C code only. As soon as you have C++ code in your Makefile.am (with or without C code), compile is not copied into the source tree anymore. This breaks support for MSVC. Below you can find a patch. Regards Harri -- diff -urN automake-1.9.6.orig/automake.in automake-1.9.6/automake.in --- automake-1.9.6.orig/automake.in 2005-06-30 23:17:13.0 +0200 +++ automake-1.9.6/automake.in 2005-11-07 15:58:49.0 +0100 @@ -1138,7 +1138,7 @@ my $output_flag = $lang-output_flag || ''; $output_flag = '-o' if (! $output_flag - $lang-name eq 'c' + ($lang-name eq 'c' || $lang-name eq 'cxx') option 'subdir-objects'); # Compute a possible derived extension. @@ -1599,7 +1599,7 @@ $object = $dname . '-' . $object; require_conf_file ($am_file.am, FOREIGN, 'compile') -if $lang-name eq 'c'; +if $lang-name eq 'c' || $lang-name eq 'cxx'; prog_error ($lang-name . flags defined without compiler) if ! defined $lang-compile;
Re: [Patch] Re: compile not copied? Why?
Ralf Wildenhues wrote: Hi Harald, Please consider this thread: http://lists.gnu.org/archive/html/libtool/2005-10/msg00069.html How is this thread related to copying a missing script? Please note that C support is broken, too, as soon as there is some C++ code in your Makefile.am. Regards Harri
Re: building 32bit and 64bit libs with the same name
Hi Ralf,
Ralf Corsepius wrote:
On Tue, 2005-11-08 at 08:15 +0100, Harald Dunkel wrote:
Hi folks,
I would like to build 32bit and 64bit libraries within the
same Makefile.am. In the install directory tree the libs
should get the same name, but the 64bit library is supposed
to be installed in ${exec_prefix}/lib64, of course.
Obviously automake can't distinguish libraries in the
build directory using the destination directory name.
What is your suggested way to handle this in the
Automake style?
You either want to add multilib-support (cf. AM_ENABLE_MULTILIB,
config-ml.in) to your configuration or leave this case to the user (i.e.
let him build the package twice, with different CFLAGS and directories)
Many thanx for the hint. I will try to make it work.
Do you know whether this is in use somewhere, or
this this too experimental yet?
Regards
Harri
compile not copied? Why?
Hi folks, What is the criteria for copying the compile script into the source directory tree? I have some *.cc code, it is mentioned in my Makefile.am file, configure detects that the compile script must be used, too, but Automake doesn't provide it. ??? Any help would be highly appreciated. Harri
building 32bit and 64bit libs with the same name
Hi folks,
I would like to build 32bit and 64bit libraries within the
same Makefile.am. In the install directory tree the libs
should get the same name, but the 64bit library is supposed
to be installed in ${exec_prefix}/lib64, of course.
Obviously automake can't distinguish libraries in the
build directory using the destination directory name.
What is your suggested way to handle this in the
Automake style?
Regards
Harri
Re: AC_PROG_CC_C_O doesn't work with VC++
Hi folks, Stepan Kasal wrote: I committed the patch attached to this mail. Could you please apply the attached patch as well? It is necessary on Windows to detect '\' as a directory path separator. Many thanx Harri --- compile~ 2005-10-24 12:03:48.0 +0200 +++ compile 2005-10-26 13:46:47.0 +0200 @@ -103,7 +103,7 @@ fi # Name of file we expect compiler to create. -cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'` +cofile=`echo $cfile | sed -e 's|^.*[/\\]||' -e 's/\.c$/.o/'` # Create the lock directory. # Note: use `[/.-]' here to ensure that we don't use the same name
Re: compile with VC++
Stepan Kasal wrote: I looked at /usr/share/automake-1.9/compile and I cannot understand how this could happen. I think that the parametr to compile should look like some/path/main.c which becomes cfile, and then cofile is assigned as cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'` Unfrtunately $cfile is the output of 'cygpath -w ../hello.c' in this case, e.g. '\\somehost\somepath\hello.c'. So $cofile is set to '\\somehost\somepath\hello.o'. Surely not correct. How about this patch for compile? cofile=`echo $cfile | sed -e 's|^.*[/\\]||' -e 's/\.c$/.o/'` ^ If a user adds '\' into his Unix filenames and uses a compiler that doesn't understand -c -o, then he is out of luck. Regards Harri
Re: compile with VC++
Hi Stepan,
Stepan Kasal wrote:
I looked at /usr/share/automake-1.9/compile and I cannot understand
how this could happen.
I think that the parametr to compile should look like
some/path/main.c
which becomes cfile, and then cofile is assigned as
cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'`
Please check depend2.am. For the Windows compiler it
uses $(CYGPATH_W) to convert the source file pathname
even before 'compile ${CC}' is run. Currently I am looking
into the Windows part of the VPATH patch, so I had sent you
a strange compiler command line including the VPATH patch
of yesterday. But $(CYGPATH_W) is used by the unmodified
depend2.am, too.
Regards
Harri
Re: using VPATH in depend2.am?
Hi,
Stepan Kasal wrote:
Hello,
Suggested code for today: ;-)
`IFS=:; v=$(VPATH); \
for d in '' $$v; do \
test -n $$d d=$$d/; \
test -f $${d}%SOURCE% echo $$d break; \
done`%SOURCE%
Works for me, as it seems.
Regards
Harri
Re: using VPATH in depend2.am?
Hi Stepan, Stepan Kasal wrote: So I suppose something like this `IFS=:; for d in '' '$(srcdir)' $(VPATH); do \ test -n $$d d=$$d/; \ test -f $$d%SOURCE% echo $$d break; \ done`%SOURCE% Could you test whether this works for you? Something like IFS=:; for d in a:b; do echo $d; done works for Sun's /bin/sh, but not for Bash 2.05b (even if you use --posix). The Bash folks say that this has been done to fix a security hole. I have another concern: In your version $(srcdir) gets a higher priority than the $(VPATH) set in Makefile.am. If Automake instantiates the suffix rules to generate *.o files, then this is different, AFAICS. So how about this? `IFS=:; x=:$(VPATH); \ for d in $$x; do \ test -n $$d d=$$d/; \ test -f $$d%SOURCE% echo $$d break; done`%SOURCE% It allows the writer of Makefile.am to completely ignore $(srcdir), if he wants to. Regards Harri
Re: using VPATH in depend2.am?
Stepan Kasal wrote:
Your proposal looks good, except I think it might be better to use single
quotes around $(VPATH).
And the quoting around $d, which I introduced, is redundant.
That yields:
`IFS=:; x=':$(VPATH)'; \
for d in $$x; do \
test -n $$d d=$$d/; \
test -f $${d}%SOURCE% echo $$d break;
done`%SOURCE%
I like this version. But if you look at the original depend2.am
in am 1.9.6, there were some tics around %SOURCES%, too, i.e.
`IFS=:; x=':$(VPATH)'; \
for d in $$x; do \
test -n $$d d=$$d/; \
test -f $${d}'%SOURCE%' echo $$d break;
done`'%SOURCE%'
Rgards
Harri
Re: using VPATH in depend2.am?
Hi folks, Ralf Wildenhues wrote: What exactly does not work for you? I tried to use VPATH = $(srcdir):$(top_srcdir)/some/common/dir in Makefile.am. In what circumstances? I am not sure what you mean by circumstances. I am trying to build a C++ library (no libtool) using both local sources and source files in a common directory for the whole project. Creating symbolic links to the common sources is no option here. On which system, which `make', which automake version, RedHat 8, Autoconf 2.59, Automake 1.9.6, GNU make 3.80, m4 1.4.3, gcc 2.95.3 where's the reproducible example, See the attachement. To reproduce tar xpfz example.tar.gz cd example autoreconf -i mkdir build cd build ../configure make You will get an error message saying gcc: ../output.c: No such file or directory If you kick out hello_CPPFLAGS from Makefile.am, then some different build rules are included in the generated Makefile, VPATH suddenly works, and the error message is gone. which part of depend2.am are you actually talking about? See the attached patch. Using this new version VPATH works for the test case. Probably a very similar patch could be applied to the libtool and Windows sections in depend2.am. Have you studied the Autoconf manual section about portability yet? Yes. I hope this patch (or maybe an easier version) could be included into Automake. Many thanx Harri diff -ur am/depend2.am am.new/depend2.am --- am/depend2.am Tue Sep 20 19:49:59 2005 +++ am.new/depend2.am Wed Oct 19 13:56:34 2005 @@ -65,7 +65,8 @@ if %FASTDEP% ## In fast-dep mode, we can always use -o. ## For non-suffix rules, we must emulate a VPATH search on %SOURCE%. -?!GENERIC? if %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o %OBJ% `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%; \ +## ?!GENERIC? if %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o %OBJ% `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%; \ +?!GENERIC? if %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o %OBJ% `test -f '%SOURCE%' || (VPATH=$(VPATH); test $$VPATH || VPATH=$(srcdir); for i in \`IFS=:; set $$VPATH; unset IFS; echo $$@\`; do test -f $$i/'%SOURCE%' echo $$i/ break; done)`%SOURCE%; \ ?SUBDIROBJ??GENERIC? depbase=`echo %OBJ% | sed 's|[^/]*$$|$(DEPDIR)/|;s|\.o$$||'`; \ ?GENERIC? if %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o %OBJ% %SOURCE%; \ then mv -f %DEPBASE%.Tpo %DEPBASE%.Po; else rm -f %DEPBASE%.Tpo; exit 1; fi @@ -79,8 +80,10 @@ ?!-o? %COMPILE% %-c% %SOURCE% else !%?GENERIC% ## For non-suffix rules, we must emulate a VPATH search on %SOURCE%. -?-o? %COMPILE% %-c% %-o% %OBJ% `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% -?!-o? %COMPILE% %-c% `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% +##?-o? %COMPILE% %-c% %-o% %OBJ% `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% +##?!-o? %COMPILE% %-c% `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% +?-o? %COMPILE% %-c% %-o% %OBJ% `test -f '%SOURCE%' || (VPATH=$(VPATH); test $$VPATH || VPATH=$(srcdir); for i in \`IFS=:; set $$VPATH; unset IFS; echo $$@\`; do test -f $$i/'%SOURCE%' echo $$i/ break; done)`%SOURCE% +?!-o? %COMPILE% %-c% `test -f '%SOURCE%' || (VPATH=$(VPATH); test $$VPATH || VPATH=$(srcdir); for i in \`IFS=:; set $$VPATH; unset IFS; echo $$@\`; do test -f $$i/'%SOURCE%' echo $$i/ break; done)`%SOURCE% endif !%?GENERIC% endif !%FASTDEP% Only in am.new: depend2.am~ example.tar.gz Description: application/gzip
using VPATH in depend2.am?
Hi folks, Would it be possible to rely upon $(VPATH) in depend2.am? Instead of `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% something like this could work, too (not verified yet): `test -f '%SOURCE%' || (VPATH=$(VPATH); test $$VPATH || VPATH=$(srcdir); for i in \`IFS=:; set $$VPATH; unset IFS; echo $$@\`; do test -f $$i/'%SOURCE%' echo $$i/ break; done)`'%SOURCE%' This would be a big improvement for supporting dependencies. Currently I have to configure using --disable-dependency-tracking to make VPATH work. Regards Harri
question about installing libraries
Hi folks,
AFAICS libraries are installed using ${INSTALL_DATA}.
Wouldn't it be more consequent to use ${INSTALL_PROGRAMS}
here?
Both libraries and programs is something that could be
stripped, i.e. you could use 'install -s'. But defining
INSTALL_DATA to use 'install -s' doesn't work, of course.
Regards
Harri
Re: creating the $(SUBDIRS) at runtime?
Simon Richter wrote: Hi, Harald Dunkel wrote: I would like to create the directories for some $SUBDIRS as needed at runtime, e.g. erm, why? Unfortunately Automake complains about the missing directories in the source tree. Yes, because the structure of the source tree is supposed to be pretty much static (in fact, your package should be able to build with the source tree on read-only media), so it doesn't make sense to name directories that aren't there. Probably a misunderstanding. The actions performed in the build directory do not depend upon an empty directory in the source tree, so why do I have to create it? (Part of the problem is that CVS doesn't allow to rename files or directories, so I would like to avoid checking in empty directories.) Regards Harri
creating the $(SUBDIRS) at runtime?
Hi folks,
I would like to create the directories for some
$SUBDIRS as needed at runtime, e.g.
:
SUBDIRS = mydir
mydir/Makefile: FORCE
${INSTALL} -d mydir
generate $@
:
Unfortunately Automake complains about the missing
directories in the source tree.
Of course the workaround is easy, but I wonder why
Automake tries to verify whether a source directory
exists?
(Part of the problem is that CVS doesn't allow to
rename files or directories, so I would like to avoid
checking in empty directories.)
Many thanx
Harri
Re: Force -O0 flags, inhibit the default -O2 flags
Sander Niemeijer wrote:
On woensdag, sep 28, 2005, at 17:04 Europe/Amsterdam, Harald Dunkel wrote:
autoconf sets CFLAGS/CXXFLAGS to reasonable defaults, that's all. If
these defaults cause problems on your platforms, you have to override
them.
They cannot be called defaults, if they get a higher priority
than the flags set in my Makefile.am. And I do not think that
setting CXXFLAGS='-g -O2' is a reasonable default, unless autoconf/
automake's assumption is that the user is supposed to debug the
developer's code.
IMHO the priorities for setting build flags should be (highest
first):
1)user
2)developer
3)autoconf/automake
Surely it is OK that autoconf/automake can provide default build
flags somehow, but the flags set by the developer (e.g. AM_CXXFLAGS)
should get a higher priority, if they are set. And automake/autoconf
should provide just the bare minimum.
As a developer you have full control over both AM_xxxFLAGS and xxxFLAGS
variables. There is no ownership difference between these two types of
flags from a developer/autoconf point of view. If you don't like the
default for CXXFLAGS that autoconf choses then just replace it in the
way Ralph explained:
CXXFLAGS=${CXXFLAGS-your other settings}
Sorry, but you missed one point: Autconf/automake _should_ provide
default build flags, but with a lower priority then the flags set
by the developer. It should be possible for a developer to set in
his Makefile.am
AM_CXXFLAGS = -Wall
if he wants to extend Automake's default (-g -O2), or
AM_AM_CXXFLAGS =
AM_CXXFLAGS = -O3 -Wall
if he wants to ignore it. Just as an example.
Important is that control about the defaults provided by autoconf/
automake is moved to the developer, if he is interested. The user
should keep the final saying. I guess we all agree here.
Regards
Harri
Re: Force -O0 flags, inhibit the default -O2 flags
Ralf Corsepius wrote: On Tue, 2005-09-27 at 12:53 +0200, Harald Dunkel wrote: Ralf Corsepius wrote: Nope. You don't seem to have understood how things are working: AM_CFLAGS/AM_CXXFLAGS are supposed to take flags having been specified by a package's developer. Understood. CFLAGS/CXXFLAGS are suppoed to take flags having been specified by a package's installer. Here, -g -O2 are just sufficiently reasonable defaults, a package installer is supposed to override. So the user has to write make CFLAGS= CXXFLAGS= install to get the default flags (AM_CXXFLAGS, etc.) provided by the developer? Sorry, but this is weird. It's not weird at all. autoconf sets CFLAGS/CXXFLAGS to reasonable defaults, that's all. If these defaults cause problems on your platforms, you have to override them. They cannot be called defaults, if they get a higher priority than the flags set in my Makefile.am. And I do not think that setting CXXFLAGS='-g -O2' is a reasonable default, unless autoconf/ automake's assumption is that the user is supposed to debug the developer's code. IMHO the priorities for setting build flags should be (highest first): 1) user 2) developer 3) autoconf/automake Surely it is OK that autoconf/automake can provide default build flags somehow, but the flags set by the developer (e.g. AM_CXXFLAGS) should get a higher priority, if they are set. And automake/autoconf should provide just the bare minimum. According to the documentation you (as a developer) are not allowed to set CFLAGS/CXXFLAGS (Automake manual, 2.5, or GNU Coding Standards). Yes, you as a package developer, are supposed to let them pass through unchanged, if a user specifies them. The documentation says that these flags are reserved for the user. It does not say that these variables are reserved for the user and for Automake. As a development tool, autoconf/automake has to follow this rule, too. CXXFLAGS is off-limits. Or the documentation should mention that autoconf/automake might predefine these flags in an unpredictable manner (e.g. by adding -g to the compiler flags), and that the developer has no chance to override this without violating the GNU coding standard, or redefining Automake's internals. The GNU coding standard talks about developers and users only: http://www.gnu.org/prep/standards/standards.html#Command-Variables We have a 3rd party, namely autoconf/automake. IMHO the relation between autoconf/automake and developer should be similar to the relation between developer and user. The flags set by the developer (e.g. AM_CXXFLAGS) can be extended or overriden by the user (by setting CXXFLAGS). Similar to this it should be possible for the developer to extend or override the flags set by autoconf/automake (_CXXFLAGS) by setting his flags (AM_CXXFLAGS). This would mean that next to CXXFLAGS and AM_CXXFLAGS there should be a 3rd variable to be set by autoconf/automake, e.g. AM_AM_CXXFLAGS. The compile rules should be modified accordingly, e.g. CXXCOMPILE = $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) || \||/ \/ CXXCOMPILE = $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_AM_CPPFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) \ $(AM_AM_CXXFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) Regards Harri
Re: Force -O0 flags, inhibit the default -O2 flags
Ralf Corsepius wrote: Nope. You don't seem to have understood how things are working: AM_CFLAGS/AM_CXXFLAGS are supposed to take flags having been specified by a package's developer. Understood. CFLAGS/CXXFLAGS are suppoed to take flags having been specified by a package's installer. Here, -g -O2 are just sufficiently reasonable defaults, a package installer is supposed to override. So the user has to write make CFLAGS= CXXFLAGS= install to get the default flags (AM_CXXFLAGS, etc.) provided by the developer? Sorry, but this is weird. Are there any other flags the user has to reset to get the flags specified by the developer? Actually the developer doesn't know, because maybe the next version of autoconf redefines even more variables that he thought he had set savely in his Makefile.am. And surely the user doesn't know, either. IMHO it is not the job of configure to make any assumptions about the compiler flags the user would like to set. This assumption should be done by the developer, if he wants to. So my suggestion for autoconf/ automake is still to predefine AM_CXXFLAGS instead of CXXFLAGS. AM_CXXFLAGS could be overriden by the developer either in configure.ac or in Makefile.am. Now if you really want to hard-code -O0 (Something rarely useful, it indicates the code having real problems), you can either resort to per_file flags (lib_X_*) or have to process CFLAGS/CXXFLAGS somewhere (either inside of configure.ac or Makefile.ams). According to the documentation you (as a developer) are not allowed to set CFLAGS/CXXFLAGS (Automake manual, 2.5, or GNU Coding Standards). Setting lib_X_CXXFLAGS is just a special case for AM_CXXFLAGS. Usually you set -O0 in case of a buggy optimizer, or if the optimization takes too much time with just a minimum speed/size improvement, etc. A developer using Automake would have to put if AVOID_BUGGY_OPTIMIZER AM_CXXFLAGS=-O0 endif into his Makefile.am. Unfortunately it is overriden by configure on behalf of the user. Regards Harri
Re: Force -O0 flags, inhibit the default -O2 flags
Brian wrote: I have a need to force three files to not be optimized. I've followed the instructions in the manual for setting them up in their own library, and then using LIBADD to combine it with the original library. If I use AM_CXXFLAGS, the -O0 is superceded by a -O2. The same occurs if I use libx_la_CXXFLAGS. I am not allowed to override CXXFLAGS (and don't want to). Makefile.am http://Makefile.am sample (one or the other): - libx_la_CXXFLAGS = -O0 - AM_CXXFLAGS = -O0 According to the documentation AM_CXXFLAGS is ignored for building libx.la, if you set libx_la_CXXFLAGS. The problem is that something is defining CXXFLAGS. The manual says that this variable is reserved to be set by the user on the command line (AFAIR). CXXFLAGS has a higher priority than both AM_CXXFLAGS and libx_la_CXXFLAGS, i.e. whatever in autoconf/ automake is defining CXXFLAGS, it overrides the variables set by the writer of Makefile.am. I doubt that this is reasonable. IMHO autoconf/automake should predefine AM_CXXFLAGS instead. CXXFLAGS should be empty. (Actually I would be glad if automake would not set any variable to '-g -O2'.) Regards Harri
Re: *_DATA primaries tried twice during make install?
Stepan Kasal wrote: ad 1) The install-am - all-am dependency causes everuthing to be checked. ad 2) I see the fillowing dependencies in a Makefile.in: install-exec-am: install-binPROGRAMS install-libLTLIBRARIES install-binPROGRAMS: $(bin_PROGRAMS) install-libLTLIBRARIES: $(lib_LTLIBRARIES) Actually, I see no strong reason for _any_ of these two dependencies: To conclude: IMHO we could: z) leave it as it is a) remove dependency 2), for all primaries b) like a), plus remove the install - all dependency Would anyone see any big problem with any of these alternatives? I like option b). If I did a 'make check' to verify the generated files, then I want to install these files as they had been checked. And as Stepan mentioned, redefining prefix for 'make install' can have some unpredictable side effects, if it runs 'make all' first. Regards Harri
Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c
Bob Proulx wrote:
Harald Dunkel wrote:
Question about make depend:
If I set
SRCDIR = ../src
noinst_PROGRAMS = hello
hello_SOURCES = ${SRCDIR}/hello.c
Shouldn't you be using normal VPATH? That is, you are setting
hello_SOURCES = ../src/hello.c. But I don't think you want to do
that.
What are you trying to accomplish there? Everything else I will say
here is speculative and contingent upon this.
I have some common source files that I have to compile and link
several times in different contexts. Actually the Makefile.am
files look more like this:
hello_SOURCES = \
$(INTERFACE_DIR)/common_interface.c \
$(INTERFACE_DIR)/common_interface.h \
localfile1.c \
localfile2.c \
:
hello_CPPFLAGS = -D$(INTERFACE_FLAG) -I$(INTERFACE_DIR)
hello_CCFLAGS = -some -flags
There are several Makefile.am files of this kind (50).
Regards
Harri
Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c
Hi Ralf, Ralf Wildenhues wrote: How about using either - a convenience archive, or - one single large Makefile.am with subdir-objects (see info Automake Alternative) A convenience library doesn't work, because I have pretty many different CPP defines, probably set either in configure, or in a config file. And a single Makefile.am file instead of one file for each module is not modular. The set of modules to build is not constant, either. to solve this problem cleanly? Alternatively, you can cludge linked_sources = common_interface.c more.c even-more.c BUILT_SOURCES = $(linked_sources) $(linked_sources): list='$(linked_sources)'; for file in $$list; do \ rm -f $$file; $(LN_S) '$(INTERFACE_DIR)'/$$file $$file; \ done Of course I appreciate your workaround, but please remember that this thread is about generating a meaningfull error message for a construct that autoconf/automake cannot handle. But maybe there is a way to generate the *.Po files from the Makefile? Regards Harri
why does make install depend upon all?
Hi folks, Please see subject. Of course I would agree that this dependency is usually a good thing, but sometimes it might be helpfull to do a 'make install' for another prefix e.g. in your stow directory without verifying all the dependencies again. It would be easy to split the old install target into new targets 'install' and 'install-again' (doing the unconditional install) without loosing functionality: install-again-am: @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am install-am: all-am install-again-am .PHONY: install-again-am The targets 'install-again' and 'install-again-recursive' could be defined accordingly. Just a suggestion. Regards Harri
make install-strip
Hi folks, Would it be possible to strip libraries at install time? Or do I have to set CFLAGS/CXXFLAGS? Regards Harri
Re: how to extend the Makefile templates?
Hi Ralf, Ralf Wildenhues wrote: Hi Harald, * Harald Dunkel wrote on Tue, Aug 16, 2005 at 12:39:46PM CEST: I would need some way to add recursive targets to all generated Makefiles, without asking every owner of every Makefile.am to append some include statement or some keyword to be replaced by AC_SUBST_FILE. Hmm. I remember you asking a similar question before. Kevin Teich started a thread about this in April. But the issue wasn't resolve, AFAIR. What would be your suggestion to solve this? I don't have a good answer to your specific question at the moment (short of extending Automake). But I have a suggestion for questions such as yours: For other people (e.g. me), requirements such as above would be much easier to understand if a good reason for it was given as well. I mean, what is it that prevents you from doing something like this find $top_srcdir -name Makefile.am | while read file do echo 'include $top_srcdir/some_snippet.am' $file done This would assume that I am allowed to change the foreign Makefile.am files, it assumes that this command wasn't run before, and it assumes that there is no AC_CONFIG_SUBDIRS. If something like this is supposed to be run, then it should work on the generated Makefile.in files. (That would be the job of automake, anyway.) The some_snippet.am would have to be converted into some_snippet.in in $(top_srcdir), and this would break the $(top_srcdir) variable for all Makefiles in subdirectories. I would like to add recursive targets to extend the test framework (e.g. to not stop testing completely if a single unittest fails in a subdirectory deep inside), or to recursively create a coverage report, to add common build targets for the documentation, and so on. My suggestion would be something like this: Some macro in configure.ac AM_ADD_TARGET([mytarget],[dependencies], some program lines could go here ) It could be used to create targets mytarget and mytarget-am as for the existing recursive targets, to add mytarget-recursive to $(RECURSIVE_TARGETS), to add it to .PHONY, and so on. Of course this might introduce problems, too (e.g. when using recursive targets in the dependencies). It would be necessary to document the difference between install and install-am, for example. Regards Harri
Re: how to extend the Makefile templates?
Ralf Wildenhues wrote: This would assume that I am allowed to change the foreign Makefile.am files, Yes. What prevents this? The version control system, maybe? Code coming from another business units that I have to use as is? Or simply because it is read-only? and it assumes that there is no AC_CONFIG_SUBDIRS. Why? This is trivial to check, too. Oh, you mean you would need several copies of some_snippet.am? Well, you can adjust the path for subpackages. A bit more work, but still not much. Of course I can manually append include statements to all files, verify whether the include statement has been included before, or avoid some Makefile.am files when doing this. But I could run sed over some Makefile templates, or even write Makefiles on my own, too, so this no argument. Why not add this functionality to Automake? Processing the Makefile.am files is Automake's job, anyway. Surely I don't have as much experience in m4 processing as you, but I doubt that it is that difficult. If something like this is supposed to be run, then it should work on the generated Makefile.in files. (That would be the job of automake, anyway.) The some_snippet.am would have to be converted into some_snippet.in in $(top_srcdir), and this would break the $(top_srcdir) variable for all Makefiles in subdirectories. I don't understand this. Why can't you change Makefile.am before running automake? Is it because you are neither the packages' author nor do you have the tools to modify the package? I am not the owner of all the packages I want to include in my project. It is a modular environment, i.e. other projects might want to use the same modules, but with their own configure.ac. The module developers should not have to care about additional build targets we want to introcude for each project (e.g. how to handle the coverage reports, or to create purify executables, or to provide a common test framework for all). Please clarify the reason for your seemingly unreasonable constraints. To me, they make no sense, because here: I would like to add recursive targets to extend the test framework (e.g. to not stop testing completely if a single unittest fails in a subdirectory deep inside), or to recursively create a coverage report, to add common build targets for the documentation, and so on. What is the test framework composed of? Simple Automake TESTS/ check_* stuff, or Autotest, or DejaGNU, or something else? This is our own test framework (well, it would be, if there would be a way to push some common code into all Makefiles). My suggestion would be something like this: Some macro in configure.ac You suggest adding stuff to configure.ac. No, I would like to get a macro I can use in configure.ac. Why is it that you may adjust configure.ac (and possibly subpackages' configure.ac files?) but not Makefile.am files? I don't touch the configure.ac in the subpackages. The top level configure.ac is created by using information stored in the modules, in a file describing my own configuration parameters, in a project configuration file, plus some framework. AM_ADD_TARGET([mytarget],[dependencies], some program lines could go here ) It could be used to create targets mytarget and mytarget-am as for the existing recursive targets, to add mytarget-recursive to $(RECURSIVE_TARGETS), to add it to .PHONY, and so on. I can see the usefulness of something vaguely similar to this, but I don't see why you need it in the issue you describe. See above. Of course this might introduce problems, too (e.g. when using recursive targets in the dependencies). It would be necessary to document the difference between install and install-am, for example. To summarize: you still have not convinced me, that the problem you really want to solve is best solved the way you describe. If you can make the problem space clear, there may be a chance that someone can suggest a better way to solve it. I would like to have a modular solution for a problem that (in my experience) comes up very often: How to create your own recursive targets. I think we have the chance to improve Automake very much here. Regards Harri
how to extend the Makefile templates?
Hi folks, I would need some way to add recursive targets to all generated Makefiles, without asking every owner of every Makefile.am to append some include statement or some keyword to be replaced by AC_SUBST_FILE. What would be your suggestion to solve this? Regards Harri
EH: some warning message, please?
Hi folks, Would it be possible to tell Automake to print some warning message for this bad Makefile.am: bin_PROGRAMS += PreciousUtils_checker PreciousUtils_checker_SOURCES = precious/Utils/unittest/src/SLListTest.cc \ precious/Utils/unittest/src/DLListTest.cc \ precious/Utils/unittest/src/HandlePoolTest.cc \ precious/Utils/unittest/src/checker.cc PreciousUtils_checker_CPPFLAGS = \ -I$(MYLIB)/include PreciousUtils_checker_LDADD = \ -L$(MYLIB)/lib -lmylib I am sure you can see the problem immediatly. Hint: The error message I got was /usr/lib/crt1.o(.text+0x18): In function `_start': : undefined reference to `main' collect2: ld returned 1 exit status Many thanx Harri
Re: how to run a test file with command line options...
Ed Hartnett wrote: Howdy all! If I have some tests, and want to run them with command line options, how do I do it? For example, I have to have a shell script to run tst_parallel below, because it needs to be called with the poe command, and some env vars set. In other cases, I need to call test program with some command line options. check_PROGRAMS = tst_parallel TESTS = run_par_test.sh Where run_par_test.sh is: MP_TASKS_PER_NODE=4 MP_PROCS=4 poe ./tst_parallel Since Automake is based on Perl it should be pretty easy to do some cgi-style replacement, e.g. TESTS = MP_TASKS_PER_NODE=4%20MP_PROCS=4%20poe%20./tst_parallel Pretty ugly and error-prone, of course, but it would be more or less backward compatible, and better than nothing. Justanidea. Regards Harri
Re: How to extend automake?
Bruno Haible wrote: Harald Dunkel wrote: It would be pretty cool if Automake could append this automagically when generating the Makefile.in files. How could it know to which Makefile.ins it should append it? There are typically several Makefile.ams for one configure.ac. I just would like to append a common Makefile fragment to all Makefile.in files, e.g. to provide an extended test scheme. Regards Harri
Re: How to extend automake?
Tom Howard wrote: Hi Bruno, I used ax_add_mk_macro in ax_dist_rpm.m4 so that in my projects I can run make dist-rpm to create an rpm distribution. Using these macros, all I have to add to the Makefile.am is @INCLUDE_MK@ at the end. It would be pretty cool if Automake could append this automagically when generating the Makefile.in files. Regards Harri
Re: BUILT_SOURCES too clumsy
In the meantime I have patched automake, e.g. diff -ur automake-1.9.5/lib/am/library.am automake-1.9.5.new/lib/am/library.am --- automake-1.9.5/lib/am/library.am2003-06-02 09:08:40.0 +0200 +++ automake-1.9.5.new/lib/am/library.am 2005-05-22 20:22:51.0 +0200 @@ -15,6 +15,7 @@ ## along with this program; if not, write to the Free Software ## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA ## 02111-1307, USA. +$(%XLIBRARY%_OBJECTS): $(%XLIBRARY%_PREDEPEND) %LIBRARY%: $(%XLIBRARY%_OBJECTS) $(%XLIBRARY%_DEPENDENCIES) %DIRSTAMP% -rm -f %LIBRARY% $(%XLIBRARY%_AR) %LIBRARY% $(%XLIBRARY%_OBJECTS) $(%XLIBRARY%_LIBADD) It makes sure that the stuff in $(libmy_a_PREDEPEND) gets built before the library objects. The patches for *_LTLIBRARIES and *_PROGRAMS look the same. What do you think? Would you expect any problems with this? Regards Harri
BUILT_SOURCES too clumsy
Hi folks, The targets in BUILT_SOURCES are unconditionally built for 'make all' and 'make install' and 'make check'. Very clumsy. I would like to generate some code for an optional convenience library exactly when needed. Would there be a way to introduce a derived variable libmylib_a_PREDEPEND, similar to BUILT_SOURCES, but bound to the primary to build? Regards Harri
Re: Automake and makedepend
Stan Guillory wrote: 2) Is there a way to force automake to set the depmode to makedepend? What happens if you run make CCDEPMODE=depmode=makedepend CXXDEPMODE=depmode=makedepend ? If it works as expected, then you might add a test for the compiler version to your configure.ac, and AC_SUBST these variables. Good luck Harri
Re: abs_top_builddir not working?
Stepan Kasal wrote:
Hello,
On Mon, May 09, 2005 at 06:02:24PM +0200, Harald Dunkel wrote:
I tried to replace $(top_builddir)
in a Makefile.am by $(abs_top_builddir), but the new
Makefile did not define this macro.
Actually, this is a bug/feature of Automake, that these variables
are not propagated by default.
A possible workaround is to place
AC_SUBST([abs_top_builddir])
to your configure.ac.
It was easier to patch header-vars.am. See below.
builddir is not set, so I skipped top_builddir, too.
Regards
Harri
---
diff -ur ../automake-1.9.5/lib/am/header-vars.am ./lib/am/header-vars.am
--- ../automake-1.9.5/lib/am/header-vars.am 2003-06-02 09:08:40.0
+0200
+++ ./lib/am/header-vars.am 2005-05-10 10:26:44.0 +0200
@@ -18,7 +18,9 @@
## 02111-1307, USA.
srcdir = @srcdir@
+abs_srcdir = @abs_srcdir@
top_srcdir = @top_srcdir@
+abs_top_srcdir = @abs_top_srcdir@
VPATH = @srcdir@
@SET_MAKE@
@@ -38,6 +40,7 @@
## Location of top build directory relative to this one.
top_builddir = %TOPDIR%
+abs_top_builddir = @abs_top_builddir@
am__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR) cd
INSTALL = @INSTALL@
why removing configure substitutions for myprog_DEPENDENCIES?
Hi folks, I have a question about how the *_DEPENDENCIES are computed from *_LDADD: If I write a Makefile.am bin_PROGRAMS = myprog MYLIB = liba.a myprog_LDADD = \ $(MYLIB) \ libb.a \ -Lsomepath \ -lother then liba.a is added to myprog_DEPENDENCIES as expected. But if I set MYLIB to the same value using a configure substitution instead, then the dependency to liba.a is gone. The man page says: The automatically-assigned value is the contents of `prog_LDADD', with most configure substitutions, `-l', `-L', `-dlopen' and `-dlpreopen' options removed. Why are the configure substitutions removed? Where is the difference in this context between defining a configure substitution, and running 'make MYLIB=liba.a'? Regards Harri
Re: why removing configure substitutions for myprog_DEPENDENCIES?
Stepan Kasal wrote: Hello, On Tue, Apr 19, 2005 at 02:50:03PM +0200, Harald Dunkel wrote: Why are the configure substitutions removed? because they are not known at the time when automake runs. Understood. Would it be possible to compute myprog_DEPENDENCIES at make's runtime instead? At that time the real set of library names is known, even for 'make MYLIB=liba.a'. Maybe something like myprog_DEPENDENCIES = $(patsubst -%,,$(myprog_LDADD)) Probably this is too much gmake, but surely you get the meaning. Regards Harri
Re: 'make clean' is removing too many files
Warren Young wrote: Harald Dunkel wrote: If I add something like lib_LIBRARIES = /some/static/old/lib2install.a ...then you're probably doing something wrong. That should probably go in LDADD. No, LDADD does not help. I have some 3rd party libraries to include into the install target. Currently I cannot add them to lib_LIBRARIES, because then make clean removes them (or at least it tries). What I would need is either some noclean_ prefix for the primaries, or I have to copy all files that are going to be installed into a local directory. I don't like neither of these options. Regards Harri
'make clean' is removing too many files
Hi folks, If I add something like lib_LIBRARIES = /some/static/old/lib2install.a to my Makefile.am, then the generated Makefile includes /some/static/old/lib2install.a in the list of files to remove for the clean target. This is certainly not correct. Only targets that are built by this Makefile should be removed during 'make clean'. See the documentation paragraph 12, What Gets Cleaned. Is there a workaround for this problem? Maybe some external_lib_LIBRARIES variable? Regards Harri
Re: Easy way to have a make target that omits some files?
Ralf Wildenhues wrote: Stab in the dark: Idea 1) Put only everything to be installed both times in bin_PROGRAMS etc, the other stuff in noinst_PROGRAMS etc. Use install-data-local and install-exec-local for installing the extra stuff within `make install', but only if some variable, say, RELEASE is not set. Then make your release target like release: release-data release-exec release-data: RELEASE=X $(MAKE) install-data etc. This looks too much like a special case to me. I would be interested in a more general solution included with autoconf/automake. Something that doesn't have to be reinvented with every new project. For your own install rules, look at how Automake writes them, they are a bit tricky. You will have problems if you use Libtool libraries, though, and need to adjust (hint: -rpath). Further trouble might loom elsewhere. Especially I don't want to write my own m4 macros to create additional install targets (speaking as a user of autoconf/ automake). The list of installation directories (predefined plus defined by the user) combined with the corresponding primaries should keep sufficient information for automake to provide the install targets. Actually the install targets created by Automake can install all files. Somehow it distinguishes between the different installation directories, too. To me it seems that it just needs some cleanup. Tell us how it goes (I have not tried the above at all). Idea 2) If you don't have to be able to do a `make release' from the same build tree as you do `make install', you can just use Automake conditionals and then if RELEASE bin_PROGRAMS = ... else noinst_PROGRAMS = .. endif Both ideas imply to edit all Makefile.am files if somebody responsible for the top level Makefile.am would like to introduce yet another install target like 'make api' or whatever. I would prefer a more modular solution. and adjust configure.ac (use AM_CONDITIONAL). This path will surely be much less error-prone if it suits your needs. release: install_bin install_lib install_include install_data The old install target could work as before. This already exists almost like you want: make install-data, make install-exec. but no make install-include, install-lib, etc. If I put something like api_includedir='$(prefix)/api/include' AC_SUBST([api_includedir]) into my configure.ac, and add api_include_HEADERS = \ src/booltype.h to a Makefile.am, then automake generates some targets install-api_includeHEADERS: $(api_include_HEADERS) and uninstall-api_includeHEADERS: The only thing missing is to generate another target listing all primaries for the installation dir, e.g. install-api_include: install-api_includeHEADERS uninstall-api_include: uninstall-api_includeHEADERS And this scheme should be followed for the default install dirs, too. Regards Harri
Re: builddir vs. srcdir
Stepan Kasal wrote: Hello, On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ || (rm -f foo.c foo.h ; exit 1) This rule can break with parallel make. You can solve the second issue by adding the dependency: foo.c: foo.h Whats about a more general case SOMEFILES=a b c d e $(SOMEFILES): srcfile buildsomehow srcfile $(SOMEFILES) || (rm -f $(SOMEFILES); false) ??? Regards Harri
