Re: Automake and new tar
Hi Roger, Thanks for the tip! This solved the issue for me. Christian On Sat, 2004-11-27 at 15:44 +, Roger Leigh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Fredrik Kalager Schaller [EMAIL PROTECTED] writes: I have been unable to 'make dist' gnome-themes-extras on Fedora due to tar complaining: tar: gnome-themes-extras-0.8.0/Gorilla/icons/scalable/mimetypes/gnome- mime-application-vnd.sun.xml.impress.svg: file name is too long (max 99); not dumped I was told today that the problem is that the new tar actually follows the spec for the method that automake wants to use. So automake needs to be fixed to not use the -o option to tar. The current automake release (1.9.3) allows one to select the tar format to use. It conservatively defaults to the old v7 format, but you can select a more up-to-date format which supports longer filenames. For example, in one of my projects which has very long pathnames, I use AM_INIT_AUTOMAKE([1.9 tar-ustar]) to use POSIX tar. You could also use tar-pax to use the new POSIX PAX format (but this is rather new if you need to care about portability). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFBqKDpVcFcaSW/uEgRAkHrAJ9Gk/mkF7b0FJuUWiZGC1nF3+RvaACfSEN4 DW/wg8nDrfRm3QT3ABH8Sa8= =YQd4 -END PGP SIGNATURE-
Re: Error because README is missing
%% Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl Hi Paul, Paul == Paul Smith [EMAIL PROTECTED] writes: Paul In the GNU make package I don't have a README file when Paul it is first checked out from CVS. Paul This used to work but now automake is failing: adl What version(s) used to work, and which one is failing? I'm not sure which ones used to work, but I know 1.8 and 1.9 both fail. I think what used to happen is I would get warnings, but automake would still succeed so I could just ignore the warning and continue on, and by the time I actually got around to building a distribution everything would be fine. Paul There is a README.in which is translated into a README, Paul replacing the version info etc. adl When and how? This turns out to be the key question. My setup is a little odd; I'm willing to change/fix it if someone can suggest a better way to do what I'm doing. The README file is created with a makefile target, but it isn't in Makefile.am (see the description below). I actually solved the README problem by putting a dummy target in my Makefile.am, like this: README: Now automake doesn't complain about this anymore. However, I actually had a second error that I didn't mention because I figured it would be the same problem... but it's not. The second error is this: $ automake --add-missing --no-force configure.in:398: required file `build.sh.in' not found This file is being created with this in my configure.in file: if test -f $srcdir/build.sh.in; then AC_CONFIG_FILES(build.sh) fi Adding an empty target for build.sh.in into Makefile.am doesn't help in this situation, I guess because it's referenced in configure.in, not Makefile.am. Is there any way to get automake to work in this situation? --- What I have is a Makefile.am that's pretty straightforward. Then at the bottom of that file I have: @MAINT_MAKEFILE@ I also have a file maintMakefile which contains a bunch of maintainer-only rules for building GNU make from CVS, etc., and this makefile is written in non-portable GNU make. The Makefile.am does _NOT_ list the maintMakefile in the list of files to be distributed, so when I create a dist tarball it's not there. In configure.in I have some text like this: # Include the Maintainer's Makefile section, if it's here. MAINT_MAKEFILE=/dev/null if test -r $srcdir/maintMakefile; then MAINT_MAKEFILE=$srcdir/maintMakefile fi AC_SUBST_FILE(MAINT_MAKEFILE) The goal behind this is: * Allows me to write some complex rules using GNU make features. * Allows maintainer-only targets to be automatically added to the makefile when you have a CVS version, but automatically _NOT_ added to the makefile when you're building a real distribution. * You need GNU make to build from CVS, but not to build a dist tarball. The problem is that the rule to build the README file is in the maintMakefile, not in the Makefile.am. As an experiment I moved it to Makefile.am and sure enough, my error went away. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: Error because README is missing
Paul D. Smith [EMAIL PROTECTED] writes: However, I actually had a second error that I didn't mention because I figured it would be the same problem... but it's not. The second error is this: $ automake --add-missing --no-force configure.in:398: required file `build.sh.in' not found This file is being created with this in my configure.in file: if test -f $srcdir/build.sh.in; then AC_CONFIG_FILES(build.sh) fi AC_CONFIG_FILES is a declaration-like macro, you can't execute it conditionallyon the shell level. If you want to make it conditional on the existence of the input file you need to do that on the m4 level. Untested code ahead. m4_syscmd([test -f build.sh.in])dnl m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)]) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, 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.
RFC for new FAQ entry: Flag Variables Ordering
There have been questions and even bug reports about this lately. So here is an attempt to document the difference between CFLAGS, AM_CFLAGS, and mumble_CFLAGS, how they are ordered, and how they should be (or not be) used. Suggestions, clarifications, and corrections most welcome. 26.5 Flag Variables Ordering What is the difference between `AM_CFLAGS', `CFLAGS', and `mumble_CFLAGS'? Why does `automake' outputs `CPPFLAGS' after `AM_CPPFLAGS' on compile lines? Shouldn't it be the converse? My `configure' adds some warning flags into `CXXFLAGS'. In one `Makefile.am' I would like to append a new flag, however if I put the flag into `AM_CXXFLAGS' it is prepended to the other flags, not appended. This section attempts to answer all these questions. We will mostly discuss `CPPFLAGS' in our examples, but actually the answer holds for all the compile flags used in Automake: `CCASFLAGS', `CFLAGS', `CPPFLAGS', `CXXFLAGS', `FCFLAGS', `FFLAGS', `GCJFLAGS', `LDFLAGS', `LFLAGS', `RFLAGS', and `YFLAGS'. `CPPFLAGS', `AM_CPPFLAGS', and `mumble_CPPFLAGS' are three variables that can be used to pass flags to the C preprocessor (actually these variables are also used for other languages like C++ or preprocessed fortran). `CPPFLAGS' is the user variable, `AM_CPPFLAGS' is the default Automake variable, and `mumble_CPPFLAGS' is the variable specific to the `mumble' target (we call this a per-target variable). Automake always uses two of these variables when compiling C sources files. When compiling an object file for the `mumble' target, the first variable will be `mumble_CPPFLAGS' if it is defined, or `AM_CPPFLAGS' otherwise. The second variable always is `CPPFLAGS'. In the following example, bin_PROGRAMS = foo bar foo_SOURCES = xyz.c bar_SOURCES = main.c foo_CPPFLAGS = -DFOO AM_CPPFLAGS = -DBAZ `xyz.o' will be compiled with `$(foo_CPPFLAGS) $(CPPFLAGS)', (because `xyz.o' is part of the `foo' target), while `main.o' will be compiled with `$(AM_CPPFLAGS) $(CPPFLAGS)' (because there is no per-target variable for target `bar'). The difference between `mumble_CPPFLAGS' and `AM_CPPFLAGS' being clear enough, let's focus on `CPPFLAGS'. `CPPFLAGS' is a user variable, i.e., a variable that users are entitled to modify in order to compile the package. This variable, like many other, is documented at the end of the output of `configure --help'. For instance someone who needs to add `/home/my/usr/include' to the C compiler's search path would configure a package with ./configure CPPFLAGS='-I /home/my/usr/include' and this flag would be propagated to the compile rules of all `Makefile's. It is also not uncommon to override a user variable at `make'-time. Many installers to this with `prefix', but this can be useful with compiler flags too. For instance if, while debugging a C++ project, you need to disable optimization in one specific object file, you can run something like rm file.o make CXXFLAGS=-O0 file.o make The reason `$(CPPFLAGS)' appears after `$(AM_CPPFLAGS)' or `$(mumble_CPPFLAGS)' on the compile command is that users should always have the last say. It probably makes more sense if you think about it while looking at the `CXXFLAGS=-O0' above, that should supersede any other switch from `AM_CXXFLAGS' or `mumble_CXXFLAGS' (and this of course replaces the previous value of `CXXFLAGS'). You should never redefine a user variable such as `CPPFLAGS' in `Makefile.am'. Use `automake -Woverride' to diagnose such mistakes. Even something like CPPFLAGS = -DDATADIR=\$(datadir)\ @CPPFLAGS@ is erroneous. Although this preserves the configure value of `CPPFLAGS', the definition of `DATADIR' will disappear if a user attempts to override `CPPFLAGS' from the `make' command line. AM_CPPFLAGS = -DDATADIR=\$(datadir)\ is all what is needed here if no per-target flags are used. You should also not add options to these variables from inside `configure', for the same reason. Occasionally you need to modify these variables to perform a test, but you should reset their value afterward. What we recommend is that you define extra flags in separate variables. For instance you may write an Autoconf macro that computes a set of warning options for the C compiler, and `AC_SUBST' them in `WARNINGCFLAGS'; you may also have an Autoconf macro that determines which compiler and which linker flags should be used to link with library `libfoo', abd `AC_SUBST' these in `LIBFOOCFLAGS' and `LIBFOOLDFLAGS'. Then, a `Makefile.am' could use these variables as follows: AM_CFLAGS = $(WARNINGCFLAGS) bin_PROGRAMS = prog1 prog2 prog1_SOURCES = ... prog2_SOURCES = ... prog2_CFLAGS = $(LIBFOOCFLAGS) $(AM_CFLAGS) prog2_LDFLAGS = $(LIBFOOLDFLAGS) In this example both programs will be compiled with the flags substituted into
