Re: Post-Processing Step
Hello Mike, * Mike Melanson wrote on Fri, Sep 29, 2006 at 02:55:55AM CEST: Is there an easy, official way to add a post-processing step to a Makefile.am? Specifically, after the primary build target is linked via autotool magic, how can I specify an extra 'objcopy' command to be executed on the linked binary? My best guess on this would be hijacking the 'all' target. Better solution? You can use the all-local target to extend it. In order to be safe for parallel make, it should depend on the files it needs, though. Something similar to this: all-local: mybinary objcopy mybinary mynewbinary Some ideas to improve this: - you can make a separate rule for mynewbinary. This isn't only nicer for clarity, it also helps `make' to remove the output file in case you interrupt it during rule execution. - objcopy is not portable (many GNU/Linux systems do not have it installed), so maybe it would be better to have a configure test that checks this and sets OBJCOPY to objcopy or to `:', or some other replacement method to create the new from the old (dunny if `cp' as a replacement would be good enough). Using AC_CHECK_TOOL, as in AC_CHECK_TOOL([OBJCOPY], [objcopy], [:]) would even help to find a cross-compile objcopy (I realize these notes may be marginal for you; but this list is for others to read as well). - In case this should be portable to cross-compilation from a unixy host to a w32 system, the manual rules should use $(EXEEXT) So we'd end up at something like all-local: mynewbinary$(EXEEXT) mynewbinary$(EXEEXT): mybinary$(EXEEXT) $(OBJCOPY) mybinary $@ Cheers, Ralf
install-local - uninstall-local
It would probably make sense to have a warning in case a Makefile.am has install-*-local rules but no uninstall-local. BTW, I must say I don't really understand why, at least to keep symmetry, all the install-*-local targets are mapped to a single uninstall-local one. That there is one is nice, but I find it clearer to have perfect symmetry btw install/uninstall. Just a remark, not a demand :)
autotools FAQ (was: how to turn off shared library notice in output of make install?)
[ dropping bug-libtool; apologies for the resend ] Assorted answers and corrections to your the first half of your proto FAQ: * Kent Boortz wrote on Thu, Sep 28, 2006 at 06:00:12AM CEST: * General questions Q: When do I want to use aufoconf? When automake? When libtool? What combinations? Is there ever an idea to use libtool without the other tools? To use automake without libtool? If you are asking about whether and when the three packages should be used at all or not, these sections in the Autoconf manual provide help: http://www.gnu.org/software/autoconf/manual/html_node/Introduction.html http://www.gnu.org/software/autoconf/manual/html_node/The-GNU-Build-System.html If you are asking about at what time exactly to run the programs named `autoconf', `automake', and `libtool', then the answer is a completely different one. (Not expanding on this because I don't think this was the question.) Q: The auto in the name of automake and autoconf, does this mean I can create the build environment on one platform and the build will work on all Unix/Linux platforms? A: Unfortunately not. Well, at least that is one goal: to help you to create such a build environment so that it works everywhere. Libtool is kind of a script with collectively built in knowledge built up over time, so yes it will in most cases solve the problem how to link and create executables and libraries on all platforms. It knows things, as it has its own (a bit unstructured) database over what to do. But for a new platform it might be lost. For a new unix-like platform unknown to Libtool, it should still be able to create static libraries. Please report a bug if you find one where that is not the case. Autoconf threoretically will find out what is right by doing tests instead of relying on any built in knowledge. Tests to try find out things about your compiler, linker and operating system. And there is a library of macros you can use to customize what tests you want it to perform. Still, in most cases this is not enough. You will find yourself writing new tests for things not covered, and for each new platform you start building on, find yourself doing tweaks. If you google around you will find most configure.in scripts to be quite messy and many of them buggy. So this is not easy and definitely not automatic. For many problems, there are rather complete tests out there. Be encouraged to take a look at gnulib and the Autoconf Macro archive: http://www.gnu.org/software/gnulib/ http://autoconf-archive.cryp.to/ Automake is more like a toolbox where someone else has written many tests saving you time. Not really. Automake is there to help you create portable makefiles. The aclocal program (that is unfortunately part of the Automake package) can help to manage third-party macro test files, but the program itself does not provide many tests; it's third-party packages that provide them. Automake will from a simplified make file, Makefile.am, that try to look like a specification, create portable make files Makefile.in. When the user unpack he runs the configure script it will fill in the last parts to create the actual Makefile. This sounds ok. Automake works well in most cases. But it is easy to write unmaintainable Makefile.am files as well. A sentence such as this one makes me choke. Are you trying to scare the reader? Or are you putting down on the users, stating that they write bad Makefile.am files? I know and agree that some things are not easily solved in Makefile.am files, but still, an unqualified warning does not seem very helpful. Q: If I run into problems and need to call for help, what is the rule of thumb for what is to send to automake@gnu.org, autoconf@gnu.org and libtool@gnu.org? A: See the diagram at the page ., but in general (I'm sure the maintainers doesn't agree, but for me they are really one package and I would be happy if they were distributed as one package ;-) ) Here's a stab at a diagram, though not in diagram form, to be applied in order. In the following, TOOL can mean any of autoconf, automake, or libtool. If an error message tells you to write to [EMAIL PROTECTED], then write there. If you are currently building or testing one of these tools, and encounter an error during this work, then write to its bug address, [EMAIL PROTECTED] If you have found a bug in one of the tools, and even know how to fix it, send a patch to [EMAIL PROTECTED] (In this case you will know which TOOL is the right one. ;-) If you have some problem in some package that uses the autotools, and are not sure which of them to write to, here are some less clear hints: If your issue revolves around the creation and usage of shared libraries, then most likely, libtool@gnu.org is the best place. If you have issues with building
Re: Problem finding TPO dependency file
Hello John, * John Ling wrote on Thu, Sep 28, 2006 at 08:43:56PM CEST: I am running on an IBM P690 SMP PowerPC64 running Linux 2.6.9-34.0.2.EL. The dependency style selected during configure was gcc3 (see output of configure below). There are no other errors prior to the one I sent. I have tested with 1.9.6 and the problem also shows up with that version of automake. The latest automake and aclocal version that work is 1.8.5. More questions: Can you make the package, as it exposes the breakage with 1.9.6, available somehow? Either by putting it up on a website somewhere temporarily, or by sending a tarball to me (off-list, please)? Which sed do you use? sed --version should answer that, if it's GNU sed. Do you have the environment variable POSIXLY_CORRECT set? Using automake 1.9.1 and higher, I get the following error below. I do not get this error if I switch to automake 1.8.5. So what is the change between 1.8.5 and 1.9.1 that causes it to be unable to generate this TPO file? What do I have to do to resolve this problem? shared/cpp/src/fasta/Fasta.cpp:192: fatal error: opening dependency file shared/cpp/src/fasta/.deps/Fasta.Tpo: No such file or directory compilation terminated. This error message comes from g++. Most likely the directory shared/cpp/src/fasta/.deps was not created in your build tree. Can you confirm that after running configure, the directory does not exist? It should exist, and if this is a new build tree, then it should contain a file Fasta.Plo that contains a `# dummy' line. If the directory does exist, is it maybe unwritable by you for some weird reason unknown to me? The issue seems to be with Automake's _AM_OUTPUT_DEPENDENCY_COMMANDS macro. If you can't make the package available, can you post the relevant Makefile.am parts that are responsible for dealing with Fasta.cpp? Thanks, Ralf
Re: Problem finding TPO dependency file
* John Ling wrote on Thu, Sep 28, 2006 at 08:43:56PM CEST: shared/cpp/src/fasta/Fasta.cpp:192: fatal error: opening dependency file shared/cpp/src/fasta/.deps/Fasta.Tpo: No such file or directory compilation terminated. Wait... Does the Makefile.am file use quotes for the source names? As in foobar_SOURCES = ... src/fasta/Fasta.cpp ... If yes: please remove the double quotes, rerun automake-1.9. Does that fix it? Cheers, Ralf
Re: autotools FAQ (was: how to turn off shared library notice in output of make install?)
Hello, I haven't read the whole post, but I'd like to make a few quick comments: On Fri, Sep 29, 2006 at 09:34:42AM +0200, Ralf Wildenhues wrote: Q: The auto in the name of automake and autoconf, does this mean I can create the build environment on one platform and the build will work on all Unix/Linux platforms? A: Unfortunately not. well, before autoconf, one had to fill in a long questionarie of C defines to describe one's system. The questions might be diffucult; it may not be sufficient to execute man several times. Autoconf means that this questionarie is automated: all the admin has to do is to run configure. I believe this is the `auto' in `autoconf'. So the goal to free the admin which builds the package from these problems was reached, the effort on his side is minimal. But the maintainer of the package still has to keep the portability problems in their mind, so this ``goal'' was not ``reached'', there is still space for imporovement. (Though the knowledge collected in autoconf, libtool, automake, and gnulib, give a great chance that the package will build on many platforms out-of-the-box, without a need to test it there.) Automake is [...] Not really. Automake is there to help you create portable makefiles. Thank you, Ralf, this is true, of course. But from a more theoretical standpoint, the answer might differ: `GNU Coding Stabdards' contain requirements and recommendations for how should the configuration and build of each package work. These include not only the usual make targets (all install, clean, distclean, etc.), but also features like the VPATH build (srcdir != builddir), the DESTDIR variable for installation, etc. It might be very laborous and/or tricky to support all of that in one's makefile. A natural reaction is to cutpaste all this from other projects, but such a ``solution'' in a way to hell (I mean, it's not unmaintainable). Automake's goal is to provide all of this for free; you just describe your project: which programs it contains, what are the source files for each, etc. I believe this is the `auto' in Automake. One can imagine two ways to achieve that: 1) require GNU make to be installed before the build 2) write makefile which can be interpreted by any make Automake takes the latter way, and generates portable makefiles. But that's not the goal, that's a means to achive the goal. Have a nice day, Stepan
Passing command lines in Makefile.am
Hi, Currently I'm trying to compile an application in fltk with autotools. I'm having an problem with my Makefile.am that I can't find solution on the web. The problem is that fltk must be application that uses fltk API must be linked against the fltk library, but for this they give an command line tool that returns the needed compilation/linker options. For example fltk2-config --cxxflags - gives the compile command options fltk2-config --ldflags- gives the linking command options For this I supposed that I could make a simple Makefile.am like this - FLTK_CXXFLAGS = `fltk2-config --cxxflags` FLTK_LDFLAGS = `fltk2-config --ldflags` AM_CPPFLAGS = $(FLTK_CXXFLAGS) bin_PROGRAMS = demo demo_SOURCES = demo.cpp demo_LDADD = $(FLTK_LDFLAGS) But this gave me the output Makefile.am:10: linker flags such as `--ldflags`' belong in `demo_LDFLAGS If I subtitute the FLTK_LDFLAGS value with the command line output: - FLTK_LDFLAGS = -L/usr/local/lib -lfltk2 -L/usr/X11R6/lib -lX11 -lXi -lXinerama -lXft -lpthread -lm -lXext -lsupc++ -- I get no problem in linking and compiling my example. For me, the strange is that I can give the compilation flags in the normal way, but the in linking problem I get errors. What can I do to change this? Thanks in regards Pedro Sousa
Re: Passing command lines in Makefile.am
Hello Pedro, * Pedro Sousa wrote on Fri, Sep 29, 2006 at 01:22:38PM CEST: fltk2-config --cxxflags - gives the compile command options fltk2-config --ldflags- gives the linking command options For this I supposed that I could make a simple Makefile.am like this - FLTK_CXXFLAGS = `fltk2-config --cxxflags` FLTK_LDFLAGS = `fltk2-config --ldflags` Put this in configure.ac: FLTK_CXXFLAGS=`fltk2-config --cxxflags` AC_SUBST([FLTK_CXXFLAGS]) FLTK_LDFLAGS=`fltk2-config --ldflags` AC_SUBST([FLTK_LDFLAGS]) and then just use $(FLTK_CXXFLAGS) and $(FLTK_LDFLAGS) in Makefile.am. Cheers, Ralf
Re: autotools FAQ
Hello Stepan, * Stepan Kasal wrote on Fri, Sep 29, 2006 at 12:33:19PM CEST: On Fri, Sep 29, 2006 at 09:34:42AM +0200, Ralf Wildenhues wrote: Automake is there to help you create portable makefiles. Thank you, Ralf, this is true, of course. But from a more theoretical standpoint, the answer might differ: [ Automake helps create GCS compliant makefiles ] Yes, this is definitely a better answer from the point of view why Automake was created, and why it does some things the way it does. Thanks for the correction and the nice explanation, Ralf
Re: Problem finding TPO dependency file
Hi Ralf, I'll send you a tar of the package separately. To answer your questions: sed --version reports GNU sed version 4.1.2 The environment variable POSIXLY_CORRECT is not set. The shared/cpp/src/fasta/.deps does not exist after running configure. And yes the Fasta.Plo contains only # dummy. But I am able to manually create the .deps directory in that location so at least my user account that I use isn't the cause of the inability to create the directory. Thanks, John Ralf Wildenhues wrote: Hello John, * John Ling wrote on Thu, Sep 28, 2006 at 08:43:56PM CEST: I am running on an IBM P690 SMP PowerPC64 running Linux 2.6.9-34.0.2.EL. The dependency style selected during configure was gcc3 (see output of configure below). There are no other errors prior to the one I sent. I have tested with 1.9.6 and the problem also shows up with that version of automake. The latest automake and aclocal version that work is 1.8.5. More questions: Can you make the package, as it exposes the breakage with 1.9.6, available somehow? Either by putting it up on a website somewhere temporarily, or by sending a tarball to me (off-list, please)? Which sed do you use? sed --version should answer that, if it's GNU sed. Do you have the environment variable POSIXLY_CORRECT set? Using automake 1.9.1 and higher, I get the following error below. I do not get this error if I switch to automake 1.8.5. So what is the change between 1.8.5 and 1.9.1 that causes it to be unable to generate this TPO file? What do I have to do to resolve this problem? shared/cpp/src/fasta/Fasta.cpp:192: fatal error: opening dependency file shared/cpp/src/fasta/.deps/Fasta.Tpo: No such file or directory compilation terminated. This error message comes from g++. Most likely the directory shared/cpp/src/fasta/.deps was not created in your build tree. Can you confirm that after running configure, the directory does not exist? It should exist, and if this is a new build tree, then it should contain a file Fasta.Plo that contains a `# dummy' line. If the directory does exist, is it maybe unwritable by you for some weird reason unknown to me? The issue seems to be with Automake's _AM_OUTPUT_DEPENDENCY_COMMANDS macro. If you can't make the package available, can you post the relevant Makefile.am parts that are responsible for dealing with Fasta.cpp? Thanks, Ralf
