Re: bug in perl formline in automake
Hello, * Stepan Kasal wrote on Mon, Nov 09, 2009 at 03:52:29PM CET: Files which are automatically distributed, if found: Use of uninitialized value in formline at /usr/bin/automake line 8334. ABOUT-GNU README config.rpath ltcf-gcj.sh for the reconrd, this was a Fedora-specific bug in perl; details in http://bugzilla.redhat.com/528572 Sorry for the noise, Stepan Kasal
bug in perl formline in automake
Hello, automake --help contains this: Files which are automatically distributed, if found: Use of uninitialized value in formline at /usr/bin/automake line 8334. ABOUT-GNU README config.rpath ltcf-gcj.sh ABOUT-NLS THANKS config.sub ltconfig The error line comes to the terminal through stderr, not stdin. Does any of the readers here understand perl formlines? Thanks for any hint, Stepan
Re: Failure of `make.test'
Hello, On Tue, Jul 01, 2008, Ludovic Courtès wrote: Yes, actually I had forgotten that NixOS' GNU Make package is modified to produce additional output suitable for the `nix-log2xml' tool. The extra output [*] is (1) one line per goal sent to stderr, and (2) an additional \e[p sequence to stdout when `-w' is used: [*] Patch available at: https://svn.nixos.org/viewvc/nix/nixpkgs/trunk/pkgs/development/tools/build-managers/gnumake/log.patch?revision=10849view=markup well, this change sounds dangerous. It's a common practice to parse the output of make, and inserting invisible tty control sequences is not friendly to that practice. If you require such a dangerous feature, it should not be switched on by default. And since GNU make often adds -w automatically (see the manual for details), binding that feature to -w amouts as swithing on by default. Here is what can easily happen: At first, ./configure detects GNU make includes correctly. But later on, a developer changes configure.ac. The rules in Automake-generated makefiles ensure that ./configure is run again. But at that time, ./configure is called from make, perhaps from recursive make, so it is called with -w sitched automatically on. Consequently, the reconfigure would not detect the include directive, automatic dependencies would be disabled. It would be very hard to detect this bug, because it appear only under certain conditions, and it regularly disappears each time ./configure is run explicitly from command line. Actually it would take ages before the bug was _described_ accurately, not speaking about fixing it. The net result would just be that the Nix community would spread the rumour that the automatic rebuilds provided by autotools are not as reliable as advertised. Well, luckily, configure clears MAKEFLAGS= during its initialization. So yes, the above horror is a fiction. Yet I'm worried some variant of it *could* happen in reality. In short, I'd recommend that NixOS reconsider the patch. Stepan
Re: Failure of `make.test'
Hello, to reproduce what the test does, try the following: mkdir test.dir cd test.dir cat configure.ac \EOF AC_INIT(foo,0,np) AM_INIT_AUTOMAKE(foreign) AM_MAKE_INCLUDE AC_OUTPUT(Makefile) EOF touch Makefile.am autoreconf -i MAKE='make -w' ./configure In my case, the configure output contains (near the end): checking for style of include used by make -w... GNU But in your case, it will probably be: checking for style of include used by make -w... none Attached below please find a test similar to that pefofrmed by configure. Could you please try it? What is the output? Have a nice day, Stepan #!/bin/sh am_make='make -w' cat confinc 'END' am__doit:; @echo done .PHONY: am__doit END # If we don't find an include directive, just comment out the code. echo -n checking for style of include used by $am_make... am__include=# am__quote= _am_result=none # First try GNU make style include. echo include confinc confmf # We grep out `Entering directory' and `Leaving directory' # messages which can occur if `w' ends up in MAKEFLAGS. # In particular we don't look at `^make:' because GNU make might # be invoked under some other name (usually gmake), in which # case it prints its new name instead of `make'. if test `$am_make -s -f confmf 2 /dev/null | grep -v 'ing directory'` = done; then am__include=include am__quote= _am_result=GNU fi # Now try BSD make style include. if test $am__include = #; then echo '.include confinc' confmf if test `$am_make -s -f confmf 2 /dev/null` = done; then am__include=.include am__quote=\ _am_result=BSD fi fi echo $_am_result rm -f confinc confmf
Re: Failure of `make.test'
Hello, On Tue, Jul 01, 2008 at 05:39:27PM +0200, Ludovic Courtès wrote: to reproduce what the test does, try the following: Unfortunately, I can't run it with the in-tree Automake, because `autoreconf' won't find $prefix/share/aclocal-1.10, for instance. How can I make it use the in-tree files? the build tree creates wrappers in the tests/ subdir and then defs adds that to the beginning of PATH. But it does not matter here, since: Attached below please find a test similar to that pefofrmed by configure. Could you please try it? What is the output? It displays none. It means that make -w behaves strange on your platform. (Try replacing make -w with make at the top of the script; then the answer will be GNU, right?) You should report it to the vendor of your platform (NixOS). OTOH, AFAIK, make -w is not used much, so it is quite probable that this problem does not affect you in practical life at all. Have a nice day, Stepan
Re: question using VPATH'S ...
Hello, On Wed, Jul 02, 2008 at 02:07:36AM +1930, Roberto Alejandro Espí Muñoz wrote: Ok, I thinks I didn't explain myself correctly then ... From what I saw there I can use either bindir, libdir or includedir for when I'm installing the completed targets. What I want to do is to locate them before that moment. What I would like to do is determine exactly where my targets end up in my project directory before I install them. All my binaries on a bin subdirectory for example, or my shared objects in a lib directory, my object files in a obj directory. we hear this a lot, since many people are accustomed to this type of setup. Automake does not support this: the object file is placed next to each source file, or better in a correcponding directory in the build tree. When you are going to build for more platforms, you just create several build trees and run configure on each platform in a separate subdirectory. We believe that this style is more practical than the one with subdirs bin lib, etc., once you get accustomed to it. In any case, this style is an integral part of Automake design and it's hard to talk Automake into something else. I noticed that all my libs and binaries are ending up in a hidden .libs directory. Oh, that! That seems confusing, and it looks as if it did not corresponded to what I said above. This is done by libtool. Libtools is dedicated to portable build and install shared libraries. Not all platforms use GNU linker: some platforms cannot handle dependecies of dynamic libraries, so the complete recursively evaluated list has to be present on the command line; some platforms even require special change to the linked dynamic library when it is installed, depending on the desttination directory. Libtool is able to transparently handle all of this. But the price for this is that you have to use *.lo files as handles for object files, and *.la files as handles for linked libraries. The la file is a common handle for static and dynamic library; actually, this is another benefit: you do not have to think about static and dynamic library separately, the *.la file represents both. And since the compile options for static and dynamic libraries often differ, the *.lo is often also representing two physical object files. The real objeck files and static and dynamic libraries are hidden in subdir .libs/, but you should pretend you do not know. ;-) The game is that you are using *.la and *.lo files all the time, and that you use ./libtool compile and ./libtool link as your compiler and linker, respectively. (Yes, some distributions have a rule that *.la files may not be part of the resulting package, but that has little to do with this---you just remove *.la from the installed tree at the very end of your build.) The above paragraphs cannot teach you how to use libtool, but I hope they help to clear the confusion: .libs is in no way similar to the bin lib setup you mentioned in another part of your mail. Have a nice day, Stepan
Re: Dependencies: non-standard path to system headers
Hello, On Tue, Jul 01, 2008 at 06:12:15AM +, Ineiev wrote: WinAVR gcc produces dependencies that shall confuse `make', like these: sampler.o: ../../../stribog/sw/auxilia/coil/sampler.c \ c:/winavr-20080512/lib/gcc/../../avr/include/avr/io.h \ c:/winavr-20080512/lib/gcc/../../avr/include/avr/sfr_defs.h \ [...] perhaps my first question is a bit naive, but why does this confuse your make? It's a long time since I last used cygwin, but aren't these paths correct? If cygwin does not understand c:/ then it surely has something like /magicwordforsuperroot/c/winavr-20080512/ Couldn't WinAVR be patched so that it produces this type of paths, to be compatible with its host environment? sed s/ -MD / -MMD / Makefile Makefile.tmp ... This run successfully, but I'm afraid such a description of dependencies is not reliable. Well, first you are depending on Automake internals, so you are at risk that things may break with future versions of Automake. I suggest to test the feature each time you upgrade to new Automake API, i. e., Automake 1.11, 1.12, etc. Then let me note that you can also patch Makefile.in, which is generated by Automake before you create a distribution tarball. You could perhaps call sed in dist-hook, so all tarballs would contain modified Makefile.in (see the Automake manual for details about dist-hook). This might be less fragile, in the sense that if it breaks, it would be during make dist which is on _your_ machine, not on the machine of your user. HTH, Stepan
Re: Iperf build break with emake.
Hello, On Wed, Jun 18, 2008 at 02:26:47PM -0700, Kamaljit Singh wrote: All I've been able to trace is that emake (probably) runs the configure script on one of its agents and that creates the conftest.make file but when configure invokes make (really emake) over this conftest.make file that gets hived off to another agent and that doesnt know anything about this file since this is not an explicitly stated generated file ... Checkout the macro expansion in configure. And no I havent been able to work around this problem so far. If you rerun emake after this error, it generally reruns correctly ... I infer that emake is a distributed make implementation, which interprets standard POSIX makefile language. In that case, emake would be the new one in the game, and consequently if a situation is encountered where its behaviour is not equivalent to that of a standard POSIX make, then it should be reported to emake developers first. Hope this helps, Stepan Kasal
Re: Troubles with pkgdata_DATA primary...
Hello, On Wed, Jun 18, 2008 at 10:42:10AM -0600, John Calcote wrote: Never mind ... duh ... I forgot to take the docs directory out of the EXTRA_DIST variable when I added it to the SUBDIRS variable. Thus (I'm guessing) the distdir code was trying to create files that were already in place, and marked read-only by the distcheck code. indeed. The test performed bu distcheck looks like this: make dist # to create the tarball distdir=ftk-1.1 # unpack the tarball chmod -R a-w $(distdir); chmod a+w $(distdir) mkdir ftk-1.1/_build cd ftk-1.1/_build ../configure # ... make dist So you are doing a make distdir with a VPATH build (i.e., with build tree != source tree) and the source tree is flagged readonly. And this does not sometimes work if EXTRA_DIST contains a directory, see below for technical details. Please note that Automake manual discourages distributing a whole directory---instead, all regular files should be listed in Makefile.am. (Yes, I know this limitation is not always convenient.) Now the technical details: During make distdir, all to-be-distributed files are collected and copied to a separate tree. If a file is present in the build tree, it is taken from there; otherwise, it is taken from the source tree. But if there is a directory in the EXTRA_DIST variable and that directory is present in both trees, then make distdir has to call cp -pR for both, to merge the content of both trees. In the above scenario, the source tree is _flagged_ read-only, and that flag is copied to distdir. If the two trees overlap, and the same file comes from build tree, then it cannot overwrite the read-only flagged one, and make distdir fails. When I think about it, I recognize that this crash does not reflect a real world problem (in real world, the source tree is read-only because it is mounted read-only, not because it is _flagged_ read-only), so it is a bug in distcheck, which should be fixed somehow... Let me think... Stay tuned. Have a nice day, Stepan
Re: autoconf-2.62: `make install' fails if file system is case insensitive
Hello make makers, I hope you won't mind if I expand on this: and it looks like case-insensitive GNU make is treating 'make install' and 'make ./INSTALL' as synonyms. [...] Indeed it seems weird when install is identified with ./install even though install is declared as a phony target. (I don't know how hard it would be to change this, because the .PHONY can appear at the end of the makefile.) Similarly, if a target is declared as phony, it perhaps should be treated as case sensitive even though make is configured as case insensitive. What do you think? Stepan Kasal
Re: preprocessor output target
Hello, was wondering if there is already a macro that will create Makefile targets for getting the preprocessor output. For example, if I have a source file called init.c, I would like to be able to type something like 'make init.i' and get the output of the preprocessor only (e.g., gcc -E). The main I'm not aware about anything like that. For my debugging needs, for example, it was always enough to cut and paste the command which failed, with -E, without -c -o something.o and direct the output to less. Stepan Kasal
Re: Need Help Writing a Rule
Hello, On Sun, May 25, 2008 at 07:49:51PM -0700, Bobby Dill wrote: %.cpp: %.png uic -embed colortool $? -o $@ image_collection.cpp: images/designer_widgetstack.png \ images/designer_d_table.png \ images/designer_d_iconview.png well, this is more aquestion about make itself, not automake. The second rule is a rule without any command and it's presence means the pattern rule is not used. The pattern rule expresses that the cpp file is to be created from .png file with the same base file name. This does not seem to be what you meant. The following might be a solution: image_collection.cpp: images/designer_widgetstack.png \ images/designer_d_table.png \ images/designer_d_iconview.png uic -embed colortool $? -o $@ (The last line has to start with TAB.) HTH, Stepan
Re: How to install doxygen-generated HTML documentation?
Hello, On Tue, May 13, 2008 at 07:37:15PM +0200, Peter Simons wrote: The 'dist' and 'install' targets should work, but 'distcheck' fails with a permission denied error. If you can figure out how to remedy the problem, then that would be really great. well. First, I sucessfully reproduced the problem: autoreconf -i ./configure make distcheck fail. Then I analyzed where it failed. distcheck does this: - creates a tarball - unapcks it - flags the unpacked tree read-only - configures it in a subdirectory called _build - runs make dist there So, basically, the problem is that for a vpath build with read-only source tree, make dist does not work. In practice, this is not a big problem, so you can just ignore it. (If you want to keep the advantage of using distcheck, add a hack for this situation [1], or mask this individual problem, see [2] below.) From a bit broader picture, this is a conflict between source dir and build dir; perhaps it would be better to create the documentation in the $(srcdir). But again, if you re-create the docs each time dist is called, you will have problems with running make dist with a read-only source. You can either use a stamp file to eliminate unnecessary calls of doxygen (see also [3] below) or, again, use [1] or [2]. Yet another way, not discussed so far, is to generate list of files for Automake, eliminating the need for a directory in EXTRA_DIST. See [4] below. This is the outline of your options, hope it helps! Now to the details: [1] a hack. Apply the patch Makefile.patch (attached to this mail). It removes the duplicate files from the build tree, avoiding the clash described above. (When srcdir=builddir, the file is the same, cmp succeeds, but you cannot delete it. Instead of inventing a check whether srcdir is the same as buildir, I used the trick with test -w.) With this modification, your tarball passes distcheck. [2] You can avoid running your html-local within the distcheck. You need to enclose that part of Makefile.am to if ENABLE_DOXYGEN and add something like this to configure.ac: AC_ARG_ENABLE([doxygen], [AS_HELP_STRING([--disable-doxygen], [disable doc generation])]) AM_CONDITIONAL([ENABLE_DOXYGEN], [test x$enable_doxygen != xno]) And then you can add DISTCHECK_CONFIGURE_FLAGS = --disable-doxygen to the (top-level) Makefile.am. [3] The stamp file might be something like html/stamp, but perhaps html/index.html might work. Something which is touched each time the docs are refreshed. It would depend on all the source files which contribute to the docs. (Yes, that would be a long list, hard to maintain. Generating this list comes to mind, but then the question is if it is woth it, perhaps [4] below is then easier.) [4] Another angle is to understand that Automake really wants to have a complete list of distributed files, and it really is possible even in this case. This list of files is not convenient to maintain manually, but you can generate a file doxygen_files.make containing: doxygen_files = \ html/index.html \ html/this...html \ html/that...html \ [etc] include doxygen_files.make This include is processed by automake, so the list is pasted into the generated Makefile.in. You can then use $(doxygen_files) in dist_pkgdata_DATA eliminating all the hacks discused in this thread. But you have to be careful when defining the rule for doxygen_files.make and for docs generation. You need to avoid a situation where documents, including doxygen_files.make, are rebuilt even when they are up-to date, which could even get you to an infinite loop. I'm not able to work out an example here. --- At the end a few comments about your Makefile.am. Using $(builddir) does not make much sense, it's always . MAINTAINERCLEANFILES = configure etc. Many people want a clean which would leave only the source files, without autoconfigury. Unfortunately, twisting maintainer-clean that way is not compatible with GNU Coding Standards. OTOH, users do not use maintainer-clean, so you do not do much harm by breaching that part of the standard. Uff, rather lenthy mail, I hope at least some parts of ot will help you. Stepan Kasal --- Makefile.am 2008-05-13 19:32:10.0 +0200 +++ ../test-Makefile.am 2008-05-14 16:23:23.0 +0200 @@ -3,13 +3,15 @@ html-local: $(MKDIR_P) $(builddir)/html for f in a b; do \ - echo $$f $(builddir)/html/$$f; \ + file=$(builddir)/html/$$f; \ + echo $$f $$file; \ + test ! -w $(srcdir)/html/$$f cmp $(srcdir)/html/$$f $$file rm $$file || :; \ done install-data-local:html-local $(MKDIR_P) $(DESTDIR)$(datadir)/$(PACKAGE)/html for f in a b; do \ - $(INSTALL_DATA) $(builddir)/html/$$f $(DESTDIR)$(datadir)/$(PACKAGE)/html/; \ + $(INSTALL_DATA) $(srcdir)/html/$$f $(DESTDIR)$(datadir)/$(PACKAGE)/html/; \ done uninstall-local:
Re: Typo in manual
Hello, On Tue, May 13, 2008 at 01:08:24PM +0100, Reuben Thomas wrote: almost staled - almost stalled Thanks. I added my small collection of typos. Attached below. Could someone please commit? thanks. Stepan Kasal From d02669b611ac91885ebf8ec0c94723394ecdf50a Mon Sep 17 00:00:00 2001 From: Stepan Kasal [EMAIL PROTECTED] Date: Tue, 13 May 2008 14:46:39 +0200 Subject: [PATCH] Fix typos. * doc/automake.texi (Timeline): Reported by Reuben Thomas. * lib/am/remake-hdr.am: A few typos in comments. Signed-off-by: Stepan Kasal [EMAIL PROTECTED] --- ChangeLog|6 ++ doc/automake.texi|2 +- lib/am/remake-hdr.am | 10 +- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index e134e4a..9eea7e5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2008-05-13 Stepan Kasal [EMAIL PROTECTED] + + Fix typos. + * doc/automake.texi (Timeline): Reported by Reuben Thomas. + * lib/am/remake-hdr.am: A few typos in comments. + 2008-04-10 Eric Blake [EMAIL PROTECTED] Prefer a released version of autoconf. diff --git a/doc/automake.texi b/doc/automake.texi index baf5c77..a8f3403 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -11280,7 +11280,7 @@ lasts. @item 1996-11-26 David [EMAIL PROTECTED] releases Autoconf 2.12. -Between June and October, the Autoconf development is almost staled. +Between June and October, the Autoconf development is almost stalled. Roland McGrath has been working at the beginning of the year. David comes back in November to release 2.12, but he won't touch Autoconf anymore after this year, and Autoconf then really stagnates. The diff --git a/lib/am/remake-hdr.am b/lib/am/remake-hdr.am index 2d6eaeb..6e3ebcd 100644 --- a/lib/am/remake-hdr.am +++ b/lib/am/remake-hdr.am @@ -39,21 +39,21 @@ if %?FIRST% ## Whenever $(AUTOHEADER) has run, we must make sure that ## ./config.status will rebuild config.h. The dependency from %STAMP% ## on %CONFIG_H_DEPS% (which contains config.hin) is not enough to -## express his. +## express this. ## ## There are some tricky cases where this rule will build a ## config.hin which has the same timestamp as %STAMP%, in which case -## ./config.status will not be rerun (meaning that users will use in +## ./config.status will not be rerun (meaning that users will use an ## out-of-date config.h without knowing it). One situation where this -## can occurs is the following: +## can occur is the following: ## 1. the user updates some configure dependency (let's say foo.m4) -##and run `make' +##and runs `make' ## 2. the rebuild rules detect that a foo.m4 has changed, ##run aclocal, autoconf, automake, and then run ./config.status. ##(Note that autoheader hasn't been called yet, so ./config.status ##outputs a config.h from an obsolete config.hin.) ## 3. Once Makefile has been regenerated, make continues, and -##discover that config.h is a dependency of the `all' rule. +##discovers that config.h is a dependency of the `all' rule. ##Because config.h depends on stamp-h1, stamp-h1 depends on ##config.hin, and config.hin depends on aclocal.m4, make runs ##autoheader to rebuild config.hin. -- 1.5.4.5
Re: MKDIR_P vs. mkdir_p and automake versions
Hello, On Mon, 2008-05-12 at 11:22 -0400, David Bruce wrote: MKDIR_P is recommended but requires automake-1.10 or higher. [...] is there an acceptable workaround? forgive me stating the obvious, but the workaround is to use $(mkdir_p). It will work in Automake 1.10.x, perhaps even longer. sure that the custom rules in your `Makefile's use `$(MKDIR_P)' and not `$(mkdir_p)'. Even if both variables still work, the latter should be considered obsolete. When you encounter a problem with $(mkdir_p) in a future version of Automake, AM_INIT_AUTOMAKE([1.10]) will probably be no longer an issue. HTH, Stepan Kasal
Re: How to install doxygen-generated HTML documentation?
Hello again, Peter, On Mon, May 05, 2008 at 07:07:54PM +0200, Peter Simons wrote: Another way is to do all the necessary work manually: defining install-data-local, uninstall-local, etc. That should be safer. Thank you for the recommendation. I tried it. Both 'dist' and 'install' work fine with those local hooks, but unfortunately 'distcheck' won't. I tried the simplese example, where the top-level Makefile.am were: EXTRA_DIST = html install-data-local: $(MKDIR_P) $(DESTDIR)$(datadir)/$(PACKAGE)/html for f in a b; do \ $(INSTALL_DATA) $(srcdir)/html/$$f \ $(DESTDIR)$(datadir)/$(PACKAGE)/html; done uninstall-local: rm $(DESTDIR)$(datadir)/$(PACKAGE)/html/[ab] -rmdir $(DESTDIR)$(datadir)/$(PACKAGE)/html And make distcheck passed. Could you please post the error message from distcheck? Or even better, could you post a self-contained example made from your project which I could edit to get it through distcheck? [When I get to it. No promises, sorry.] Have a nice day, Stepan
Re: MKDIR_P vs. mkdir_p and automake versions
On Tue, May 13, 2008 at 07:55:26AM -0400, David Bruce wrote: On Tuesday 13 May 2008 04:37:16 am Stepan Kasal wrote: On Mon, 2008-05-12 at 11:22 -0400, David Bruce wrote: MKDIR_P is recommended but requires automake-1.10 or higher. [...] is there an acceptable workaround? forgive me stating the obvious, but the workaround is to use $(mkdir_p). It will work in Automake 1.10.x, perhaps even longer. Well, of course. What I meant was that I wanted the code in the svn repository to be as correct as possible, so I used MKDIR_P. My thought was whether there was some sort of autotools conditional that would allow this to work with automake 1.9 (i.e. if automake version 1.10, define MKDIR_P to be mkdir_p). Try this in configure.ac: AC_DEFUN([MY_MKDIR_P], [ m4_ifdef([AC_PROG_MKDIR_P], [AC_REQUIRE([AC_PROG_MKDIR_P])]) ]) MY_MKDIR_P or m4_ifdef([AC_PROG_MKDIR_P], [AC_PROG_MKDIR_P]) The latter might mean that the macro is expanded second time, which does not actually matter, but is somewhat inelegant. But if you put that line before AM_INIT_AUTOMAKE, you might get the first and the only expansion. The former has to use AC_DEFUN because yoiu cannot have AC_REQUIRE directly in configure.ac. This was an interesting excercise; yet I believe $(mkdir_p) is the solution. Every project has certain small probability that it will break on Automake upgrade to 1.11, 1.12, etc. $(mkdir_p) is not something which would increase that probability much. And the above hack is not safer--just a small fraction, but non-zero. HTH, Stepan
Re: patch and dist rules
Hello Jack, a few humble ideas: On Sat, May 03, 2008 at 05:59:44PM -0700, Jack Bates wrote: patch: patch-stamp patch-stamp: patches/* cat patches/* | patch -p0 touch $@ Please note that this rule is not perfect; when one of the patches is deleted, the rule does not notice it. You should rather use a stamp on the server side, too. That file might also contain a version number, or perhaps it could be a shell script which would apply the patches... This rule works OK: The first time `make patch` is called, it applies all our local patches. As long as the patches have not changed, subsequent calls to `make patch` result in Nothing to be done. When patches are changed, user intervention is required to revert changes to the working copy of the framework before applying our updated patches. if your only goal is to work for the first time and require user intervention when the set of patches is updated, you could as well do this: 1) incorporate the command cat patches/*|patch -p0 touch patches-stamp to your bootstrap script which each user runs after the checkout of the svn repository. 2) implement a check in makefiles, which would warn the user if new patches arrived: dist-hook: patches-stamp patches-stamp: patches/* echo please re-apply the patchset 2 exit 1 Since manual intervention is required, it should not matter much that we hook near the end of dist. The manual work will take more time that that failing dist. Any suggestions how to ensure automake's dist rule generates a tarball with our patches applied? I would use a wrapper GNUmakefile which would first apply patches and then call the same target; something like that: all: apply-patches: ... do what necessary %: apply-patches @$(MAKE) $(MAKEFLAGS) -f Makefile $@ .PHONY: apply-patches That GNUmakefile would not be distributed, so the created tarball would not contain it; it's OK, since it would contain the current patched buildsystem. You need to implement apply-patches somehow so that it ensures the build-system is up-to-date, see the comment above. I hope this helps, Stepan
Re: BUILT_SOURCES doesn't seem to work
Hello Bobby, a few comments: On Sat, May 03, 2008 at 11:38:08PM -0700, Bobby Dill wrote: When I try to compile my app, I get a message stating that sigcreatedlg.h does not exist, so the files in BUILT_SOURCES are not generated before the rest of my app is compiled. What's the right way to do this? BUILT_SOURCES is just a list of targets which get built at the beginning of target all (and a few other targets). This means that it has no influence if you call make pkgmaker. You have to call make all. See also this for deatils about built sources: http://www.gnu.org/software/automake/manual/html_node/Built-sources-example.html pkgmaker/Makefile.am:12: `%'-style pattern rules are a GNU make extension How do I modernize these rules? Well, it's actually the opposite of modernization. Automake does produce portable makefiles, which work with many implementations of make, not only with GNU make. That's why it does not use %-rules. The rules get copied to the resulting Makefile, but Automake does not understand them. So, to make your Makefile.am more portable, using the fact that Automake can support new extensions (.ui) once you define how to build an object file from them (in this case, indirectly, through .cpp), you can do this: .ui.h: $(UIC) -o $@ $ .ui.cpp: $(UIC) -o $@ -impl $*.h $ bin_PROGRAMS = pkgmaker pkgmaker_SOURCES = pkgmaker.cpp sigcreatedlg.ui # Create this before make all BUILT_SOURCES = sigcreatedlg.h # we cannot rely that UIC is available on the customer's machine: EXTRA_DIST = sigcreatedlg.h sigcreatedlg.cpp pkgmaker_SOURCES = pkgmaker.cpp $(pkgmaker_UI) BUILT_SOURCES = $(pkgmaker_UI) ... CLEANFILES = $(BUILT_SOURCES) These two are contradictory: If files $(pkgmaker_UI) are in pkgmaker_SOURCES, then they are distributed, so they will be included in the tarball. But then they should not be in CLEANFILES nor in DISTCLEANFILES, since make clean or make distclean shouldn't usually clean files originating from the tarball. The question is: can you suppose that $(UIC) is available on each machine where you want to unpack and build the tarball? If not, then you need the EXTRA_DIST as in my examle above. If yes, then that EXTRA_DIST should probably be changed to CLEANFILES. INCLUDES= $(all_includes) This can be modernized: s/INCLUDES/AM_CPPFLAGS/ Hope these notes are helpful, Stepan
Re: How to install doxygen-generated HTML documentation?
On Sat, May 03, 2008 at 01:08:16AM +0200, Peter Simons wrote: Warren Young writes: dist_pkgdata_DATA = html/* When I try that, I get the following error message: | make[1]: *** No rule to make target `html/*', needed by `all-am'. Stop. well, that's because all-local is not hooked to dist. A workaround is to build always before make dist. Or you can force that by a make wrapper, say GNUmakefile calling $(MAKE) -f Makefile inside. Or you can use a simple hack: html/*: $(DOXYGEN) Anyway, it still seems that uninstall does not work... Another way is to do all the necessary work manually: defining install-data-local, uninstall-local, etc. That should be safer. HTH, Stepan
Re: Questions on 'make dist'
Good afternon Della, On Wed, Mar 19, 2008 at 02:02:17PM -0400, NightStrike wrote: On Tue, 11 Mar 2008, NightStrike wrote: I had intended to do everything with non-recursive make, but as [Ralf] pointed out once, non-recursive is also considered harmful. [thread:] http://lists.gnu.org/archive/html/automake/2007-11/msg00049.html well, my interpretation of what Ralf said is that it's not healthy to obey the non-recursive-make rule too rigidly. I agree with that, though we might disagree in certain cases. In particular, it's useful to put certain libraries to a common subdirectory, _just because_ it allows you to use a different AM_CFLAGS in the Makefile.am there. The readability achieved from this hack may overweight the breaking of the rule. Back to the problem which started this thread: /trunk/ /trunk/mingw-w64-crt/ /trunk/mingw-w64-doc/ /trunk/mingw-w64-headers/ I guess you should have configure.ac at the top level (trunk). Then the top-level Makefile would contain SUBDIRS = mingw-w64-crt mingw-w64-doc mingw-w64-headers and the mingw-w64-crt/Makefile.am would perhaps also contain SUBDIRS, just for the purpose of the hack with local AM_CFLAGS. It's good to have as few makefiles as possible, it is important to remember that one makefile should _normally_ cover the whole subtree, but it's good to use SUBDIRS whenever it helps. BTW: Why do you insist on the layout described above? I would have one top-level directory and make doc and headers (or perhaps hdr) subdirs. These subdirectories wouldn't need its own makefiles, as it is not too obtrusive to repeat the short directory name: dist_doc_DATA = doc/manual.txt include_HEADERS = \ hdr/mingw-one.h \ hdr/mingw-two.h \ hdr/etc.h Hope this helps you to find the right mix for your project, Stepan
Re: Building multiple versions of the same program
Hello, On Wed, Mar 19, 2008 at 10:51:28AM -0700, iamcamiel wrote: For those interested; [...] and for the readers of the archive. prog_a_CXXFLAGS = -DVAR_A A typo: _CPPFLAGS (C PreProcessor), CXX stands for C++. Other than that, it's a perfect solution. Stepan Kasal
Re: Questions on 'make dist'
Hello, On Wed, Mar 19, 2008 at 03:13:06PM -0400, NightStrike wrote: On 3/19/08, Stepan Kasal [EMAIL PROTECTED] wrote: BTW: Why do you insist on the layout described above? I would have one top-level directory and make doc and headers (or perhaps hdr) subdirs. The mingw-w64-headers directory contains headers that are required to use the resulting gcc toolchain. They are not required to build anything under mingw-w64-crt. I think that is why Kai chose to separate them out. thanks for explanation. So you can do somethig like: mingw-w64/crt mingw-w64/doc mingw-w64/hdr so that you can easily describe the doc/something and hdr/something in the top level makefile, or you just keep this structure and let make recurse to all three subdirs. I do not think you should have more than one configure script, and it should be in the top level directory. Stepan
Re: Questions on 'make dist'
Hi, On Wed, Mar 19, 2008 at 03:55:55PM -0400, NightStrike wrote: mingw-w64/crt mingw-w64/doc mingw-w64/hdr ... So I guess the choices boil down to: 1) Change the directory structure 2) Recursive make to a small degree Is that about right? actually, I recommend recursive make to a small degree in any case. Even if you modify the tree as quoted above, you has to prefix everything in the real build with crt/, which is hardly convenient. So you would have to additionally move the contents of crt/ to the top level directory, to get only one Makefile. If you modify the structure, you might get away with only two makefiles: the top level (which would also handle doc and hdr) and crt/Makefile. (And perhaps a third one for the AM_CFLAGS trick from the other thread.) But I guess it might be more convenient for you to keep the directory structure as it is and having: Makefile mingw-w64-crt/Makefile mingw-w64-doc/Makefile mingw-w64-headers/Makefile Returning back to the article Recursive make considered harmful, the worst thing is something like lib/Makefile and src/Makefile, where the C code from lib/ and src/ forms the main program. Having a separate doc/Makefile is obviously much less harmful. Stepan
Re: Autoconf's copy of ChannelDefs.pm
Hello, On Sat, Mar 15, 2008 at 02:24:34PM +0100, Ralf Wildenhues wrote: * Stepan Kasal wrote on Fri, Mar 14, 2008 at 03:20:53PM CET: several of the lib/Automake/*.pm files are used by Autoconf as lib/Autom4te/*.pm. Why isn't ChannelDefs.pm among them. ... Hmm. Would it make sense to even have 'automake -Wcross'? Well, it's hard to imagine that Automake would ever issue a warning of category cross. I thought that automake could have listed an anused category... If not, then adding it would be a false promise to users. ... but now I admit that was a bad idea. Consequently: [...] we could just sync it now for all except the -Wcross stuff That's the answer. I'll post a patch in a few hours. Stepan
Autoconf's copy of ChannelDefs.pm
Hello,
several of the lib/Automake/*.pm files are used by Autoconf as
lib/Autom4te/*.pm. Why isn't ChannelDefs.pm among them.
autoconf/.../ChannelDefs.pm has accumulated several small changes
which should go to lib/Automake/
The only question is about -Wcross. Shall Automake have this new
category of warnings, even though it does not use it currently?
Attached please find a patch which would sync the two clones.
Are you willing to apply?
Have a nice day,
Stepan Kasal
2008-03-14 Stepan Kasal [EMAIL PROTECTED]
* lib/Automake/ChannelDefs.pm: Import changes from Autoconf.
--- lib/Automake/ChannelDefs.pm 2008-02-05 15:10:22.0 +0100
+++ lib/Automake/ChannelDefs.pm 2008-03-14 15:03:05.904510600 +0100
@@ -25,7 +25,7 @@
use Automake::ChannelDefs;
- Automake::ChannelDefs::usage ();
+ print Automake::ChannelDefs::usage (), \n;
prog_error ($MESSAGE, [%OPTIONS]);
error ($WHERE, $MESSAGE, [%OPTIONS]);
error ($MESSAGE);
@@ -34,12 +34,12 @@
verb ($MESSAGE, [%OPTIONS]);
switch_warning ($CATEGORY);
parse_WARNINGS ();
- parse_warning ($OPTION, $ARGUMENT);
+ parse_warnings ($OPTION, $ARGUMENT);
Automake::ChannelDefs::set_strictness ($STRICTNESS_NAME);
=head1 DESCRIPTION
-This packages defines channels that can be used in Automake to
+This package defines channels that can be used in Automake to
output diagnostics and other messages (via Cmsg()). It also defines
some helper function to enable or disable these channels, and some
shorthand function to output on specific channels.
@@ -78,7 +78,7 @@
=item Cerror-gnu/warn
-Errors related to GNU Standards that should be warnings in `foreign' mode.
+Errors related to GNU Standards that should be warnings in foreign mode.
=item Cerror-gnits
@@ -88,6 +88,10 @@
Internal errors. Use Cprog_error to send messages over this channel.
+=item Ccross
+
+Constructs compromising the cross-compilation of the package.
+
=item Cgnu
Warnings related to GNU Coding Standards.
@@ -140,6 +144,7 @@
\n),
footer = \nPlease contact [EMAIL PROTECTED].;
+register_channel 'cross', type = 'warning', silent = 1;
register_channel 'gnu', type = 'warning';
register_channel 'obsolete', type = 'warning', silent = 1;
register_channel 'override', type = 'warning', silent = 1;
@@ -156,13 +161,14 @@
=item Cusage ()
-Display warning categories.
+Return the warning category descriptions.
=cut
sub usage ()
{
- print Warning categories include:
+ return Warning categories include:
+ `cross' cross compilation issues
`gnu' GNU coding standards (default in gnu and gnits modes)
`obsolete' obsolete features or constructions
`override' user redefinitions of Automake rules or variables
@@ -172,8 +178,7 @@
`all' all the warnings
`no-CATEGORY' turn off warnings in CATEGORY
`none' turn off all the warnings
- `error' treat warnings as errors
-;
+ `error' treat warnings as errors;
}
=item Cprog_error ($MESSAGE, [%OPTIONS])
@@ -232,7 +237,7 @@
=item Cswitch_warning ($CATEGORY)
If C$CATEGORY is Cmumble, turn on channel Cmumble.
-If it's Cno-mumble, turn Cmumble off.
+If it is Cno-mumble, turn Cmumble off.
Else handle Call and Cnone for completeness.
=cut
@@ -291,21 +296,22 @@
}
}
-=item Cparse_warning ($OPTION, $ARGUMENT)
+=item Cparse_warnings ($OPTION, @ARGUMENT)
Parse the argument of C--warning=CATEGORY or C-WCATEGORY.
-C$OPTIONS is C--warning or C-W, C$ARGUMENT is CCATEGORY.
+C$OPTIONS is C--warning or C-W, C@ARGUMENT is a list of
+CCATEGORY.
-This is meant to be used as a argument to CGetopt.
+This can be used as an argument to CGetopt.
=cut
-sub parse_warnings ($$)
+sub parse_warnings ($@)
{
- my ($opt, $categories) = @_;
+ my ($opt, @categories) = @_;
- foreach my $cat (split (',', $categories))
+ foreach my $cat (map { split ',' } @categories)
{
msg 'unsupported', unknown warning category `$cat'
if switch_warning $cat;
Re: How to test if a autoconf macro exists?
Hello, [this would better fit to [EMAIL PROTECTED], but the difference is not always easy to understand] On Mon, Feb 04, 2008 at 11:35:59AM +0100, Santiago Capel Torres wrote: So, it looks like I can not use AM_PATH_XML2 before installing libxml2-devel, so I can not test if it is installed :( you are confusing two roles here: - the user who gets the tarball of your project should be ablo to install it easily by configure, make, make install In this case the configure script, which is part of the tarball, is flexible enough to detect if libxml2 is installed, and many other aspects of the system which is going to be used for the build. - Developpers, who get the minimal set of the primary sources from the CVS, need full range of developper tools to be able to build from the minimal tree, and to build the tarball for others (make dist) Those people are supposed to be able to install libxml2-devel, or the needed .m4 file alone, to satisfy the requirements of the autotools. Moreover, you are probably writing a bootstrap script for them, so you can check the tools for known errors and add hints for them. For people who are only supposed to test the latest snapshot, it is always safer to provide a daily snapshot tarball, generated by make dist on an up-to-date comp. [Back to your question: yes, you can do something like m4_ifdef([AM_PATH_XML2], [AM_PATH_XML2([])]) But this solution would confuse aclocal and the macro AM_PATH_XML2 would not get to aclocal.m4 even if it is available. So please do not use m4_ifdef in this case.] Hope this clarifies the situation, Stepan Kasal
Re: Automatically Handling Tools that Produce Many Outputs
Hello, On Tue, Nov 27, 2007 at 12:30:31AM +, Olly Betts wrote: Handling Tools that Produce Many Outputs. However, these recipes require a lot of boilerplate code which annoyingly obscures [...] It's just struck me that automake is good at inserting lots of boilerplate code into makefiles! [...] Sounds right. data.c data.h::: data.foo foo data.foo But this looks like too much magic for a feature which is not used that much. Moreover, the extended syntax should rather describe the pair of rules .foo.c: an .foo.h: because there may be more *.foo. I understand that this enhancement would be somewhat helpful, but I do not know how it should be designed. Let's hope for a comment from one of the more experienced Automake developers. ;-) Cheers, Stepan
Re: make distcheck and the /etc dir
Hello Jason, On Mon, Jun 04, 2007 at 07:25:16PM +0200, Jason Curl wrote: Sounds like my best solution would be to use the sysconf_DATA option. this was also the fist solution which came to my mind. Any ideas how to take 'sysconfdir' and somehow import it into my program so it knows where the default configuration files are? See `info Autoconf FAQ defining' for general instructions. A correction, though: I'd use AM_CPPFLAGS = -DDATADIR='$(datadir)' instead of modifying CPPFLAGS. I think it is OK to use the default value of sysconfdir and let the user configure with --sysconfdir=/etc if that is what they want. (GNU/Linux distributions often set that in their build scripts.) It is possible to do some hacks in configure.ac so that the default is /etc. (And you can then use DISTCHECK_CONFIGURE_FLAGS to revert that change for distcheck, so that it passes.) I'm also concerned about overwriting a users old configuration file. So any ideas how I can operate on any existing files before they're overwritten? For example, I might try a merge, or just copy the files as a backup before overwriting them. I guess that in that case it might be best to foget about sysconf_DATA, and use install-exec-local for the installation of the config file. (You would use EXTRA_DIST to distribute your default config file, of course.) This thread got quite a big quickly; if a particular question remained unansewered, feel free to post it again, under a new subject. Have a nice day, Stepan Kasal
Re: 'make clean' removing doc/shishi.ps
Hello, On Wed, May 23, 2007 at 11:34:08AM +0200, Simon Josefsson wrote: Is there some other way to achieve what I want (i.e., ship manuals in many formats and have them stick around after 'make clean') that I've missed? looking at the source (automake.in) or installed automake script, one can see that it's hardwired: procedure output_texinfo_build_rules returns the *.ps and others, and the caller adds them to texi_cleans. You can always patch automake and submit the change, but if your needs are special, there is little chance that your change gets accepted. Or you can resort to a hack: configure would make a bacup copy at configure time, and that copy would be used by mostlyclean-local to restore the just-deleted files. Or you can put the ``official'' docs separatey, not in the place where they are usually built, and tell users about it. HTH, Stepan Kasal
Re: What is `aclocal' trying to tell me? ``error: m4_defn: undefined macro: _m4_divert_diversion''
Hello, On Wed, May 09, 2007 at 07:42:54PM +0200, Thomas Schwinge wrote: All this is supposed to be compatible to Automake 1.9, I think? well, 1.9.* are compatible, but the newer ones _are_ supposed to contained bug fixes. Which seems to be the case here. ;-) Hope this explains it, Stepan Kasal
Re: info_TEXINFOS should not assume source file exists
Hello, On Wed, May 09, 2007 at 12:06:17PM +0100, Noah Slater wrote: Thank you both for getting back to me. I share Ralf's feelings, but I do not see many options here: - you may generate a *.texi stub, as you suggest - you may compute foo.texi is from foo.dbk in bthe bootstrap script - or you may refrain from using info_TEXINFOS and put the rules to Makefile.am I will play around with your suggestions to see what fits. I do not want to generate the texi file from the bootstrap as I want the users to be able to regenerate the documentation from the original sources - I agree that the makefile has to contain a rule for foo.texi. What I had in mind was that the same command might be called from the bootstrap script. (But yes, then you have to make sure that the two are synced.) On a second thought: another way to work around the problem: create a small foo.texi with @setfilename and @include foo-main.texi which would be the real one generated from foo.dbk. Then you shall also add to Makefile.am: foo_TEXINFOS = foo-main.texi to tell Automake about the dependency of foo.info on this texinfo file. [...] I also have no problem distributing the DocBook or texi files as I do not want the users to HAVE TO HAVE makeinfo or docbook2x-texi installed. In that case I would say that the workaround you suggested is the best one available. Considering that my situation is not an unreasonable one, would you consider this a bug? Sorry if it was not clear from my previous mail: Yes, I considered this a bug. Now, when you made me to think more about it, I would be more exact: - it is very unfortunate limitation that Automake cannot handle generated Texinfo sources adequately. - it is a bug that this limitation is not documented in the manual; patches welcome. Have a nice day, Stepan Kasal
LTLIBRARIES omitted in doc
Hi,
I noticed that `LTLIBRARIES' is missing in the list of the
primaries in node Uniform. Please apply the attached patch.
Stepan
2007-05-03 Stepan Kasal [EMAIL PROTECTED]
* doc/automake.texi (Uniform): Add `LTLIBRARIES' to the list
of primaries.
Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.166
diff -u -r1.166 automake.texi
--- doc/automake.texi 23 Apr 2007 16:36:58 - 1.166
+++ doc/automake.texi 3 May 2007 08:53:52 -
@@ -1953,10 +1953,11 @@
objects are not installed either.
The current primary names are @samp{PROGRAMS}, @samp{LIBRARIES},
[EMAIL PROTECTED], @samp{PYTHON}, @samp{JAVA}, @samp{SCRIPTS}, @samp{DATA},
[EMAIL PROTECTED], @samp{MANS}, and @samp{TEXINFOS}.
[EMAIL PROTECTED], @samp{LISP}, @samp{PYTHON}, @samp{JAVA}, @samp{SCRIPTS},
[EMAIL PROTECTED], @samp{HEADERS}, @samp{MANS}, and @samp{TEXINFOS}.
@vindex PROGRAMS
@vindex LIBRARIES
[EMAIL PROTECTED] LTLIBRARIES
@vindex LISP
@vindex PYTHON
@vindex JAVA
Re: 'toolman_MANS' not supported?
Hello Harald,
* Harald Dunkel wrote on Mon, Apr 30, 2007 at 01:04:25PM CEST:
...
toolmandir = ${prefix}/tooldir/man
toolman_MANS = hello.1
does not work. Did I miss something in the documentation here?
I agree with Ralf that this behaviour corresponds to the documentation.
But `toolman_MANS' is silently ignored, as is `mam_MANS' or
`gee_TEXINFOS'. IOW, the usual check for typos or undefined geedir
variable is not performed for these two primaries.
There is definitely a space for improvement here; as usual, patches
are welcome. ;-)
The implementation problem is that MANS and TEXINFOS are not
processed by `am_primary_prefixes' beacuse they do not fit well into
the dir_PRIMARY scheme explained in
http://sources.redhat.com/automake/automake.html#Uniform
The reason is that the semantics of these two primaries does not
really fit into the uniform naming scheme, there is too much magic
added.
With the `MANS' primary, we have this:
man_MANS installs into subdirs of mandir, manX_MAN
(where X stands for a section name) changes the name of the file
and installs into manXdir.
It looks like two discrete kind of magic. Which of the two shall
apply to general foo_MANS?
It seems that even writing a specification for the genreal `MANS'
primary presents some work, even before any line of code is written.
Again, volunteers are welcome.
Have a nice day,
Stepan Kasal
Re: 'toolman_MANS' not supported?
Hi Harald, [answering, though not asked] On Thu, May 03, 2007 at 12:48:08PM +0200, Harald Dunkel wrote: Hi Ralf, [...] Do you think it would be difficult to replace the hardwired 'man' in automake.pl by a directory variable? I'm afraid it is relatively difficult. Prove that I'm wrong! ;-) Stepan
Fix typos, but think twice
Hello,
on 2002/12/18, a bunch of typos in the Automake source tree was
fixed. At least one of the typos was intentional, though.
The patch automake-20070502-no-typo.patch fixes that.
And when I'm at it, I'm submitting my own collection of typos,
see automake-typos.patch .
Have a nice day,
Stepan Kasal
2007-05-02 Stepan Kasal [EMAIL PROTECTED]
* automake.in (am_primary_prefixes): Keep the intentional typo there.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1644
diff -u -r1.1644 automake.in
--- automake.in 29 Mar 2007 23:01:59 - 1.1644
+++ automake.in 2 May 2007 13:24:54 -
@@ -6756,7 +6756,7 @@
#
# As a side effect, it looks for misspellings. It is an error to have
# a variable ending in a reserved suffix whose prefix is unknown, e.g.
-# bin_PROGRAMS. However, unusual prefixes are allowed if a variable
+# bni_PROGRAMS. However, unusual prefixes are allowed if a variable
# of the same name (with dir appended) exists. For instance, if the
# variable zardir is defined, then zar_PROGRAMS becomes valid.
# This is to provide a little extra flexibility in those cases which
2007-05-02 Stepan Kasal [EMAIL PROTECTED]
* automake.in, doc/automake.texi, lib/Automake/Rule.pm: Fix typos.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1641
diff -u -r1.1641 automake.in
--- automake.in 16 Oct 2006 05:24:17 - 1.1641
+++ automake.in 9 Jan 2007 14:53:49 -
@@ -372,7 +372,7 @@
# Where version is defined.
my $package_version_location;
-# TRUE if we've seen AC_ENABLE_MULTILIB.
+# TRUE if we've seen AM_ENABLE_MULTILIB.
my $seen_multilib = 0;
# TRUE if we've seen AM_PROG_CC_C_O
Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.164
diff -u -r1.164 automake.texi
--- doc/automake.texi 27 Jan 2007 16:32:11 - 1.164
+++ doc/automake.texi 9 Mar 2007 19:57:02 -
@@ -3764,7 +3764,7 @@
@cindex autoupdate
Although using some of the following macros was required in past
-releases, you should not used any of them in new code. Running
+releases, you should not use any of them in new code. Running
@command{autoupdate} should adjust your @file{configure.ac}
automatically (@pxref{autoupdate Invocation, , Using
@command{autoupdate} to Modernize @file{configure.ac}, autoconf, The
Index: ./lib/Automake/Rule.pm
===
RCS file: /cvs/automake/automake/lib/Automake/Rule.pm,v
retrieving revision 1.12
diff -u -r1.12 Rule.pm
--- lib/Automake/Rule.pm20 Oct 2006 17:17:56 - 1.12
+++ lib/Automake/Rule.pm13 Mar 2007 20:22:25 -
@@ -482,7 +482,7 @@
return 0;
}
-=item Crule ($rulename, $cond
+=item Cruledef ($rulename, $cond)
Return the CAutomake::RuleDef object for the rule named
C$rulename if defined in condition C$cond. Return false
Re: rewrite of m4/depout.m4
Hello, On Tue, Apr 17, 2007 at 07:02:13PM +0200, Ralf Wildenhues wrote: The motivation to do this was to work towards allowing non-static content in *_SOURCES variables, so that it works even with subdir-objects. IOW, one stepping stone to eventually allow bin_PROGRAMS = foo mydir = foo/bar foo_SOURCES = $(mydir)/a1.c The patch is missing documentation stating that, for a makefile named $Makefile, a temporary file named t$Makefile will be created and removed during the `depfiles' stage. No, I don't really want this applied. I think the killer argument against this change is the point that a buggy Makefile has worse consequences, starting from spurious errors at config.status time, and not ending in an infinite configure recheck loop. well, this is a pity: running make from config.status would be cool. :-( But we could apply a more minimalistic approach: we might try to grep only the variables which are needed to evaluate the directory names and then run make with that specially crafted makefile. We are using awk already, so we can use it for this task, too. But since we have got _that_ far, we might also use awk to perform the recursive evaluation of the directory name, and output the list of the directories to be created. What do you think? Have a nice day, Stepan
Re: renamed objects and other languages
Hello Florian,
* Florian Briegel wrote on Mon, Apr 23, 2007 at 11:59:10AM CEST:
Am Montag, 23. April 2007 schrieb Benoit Sigoure:
Is there any reason why you would not want to do this?
Simplicity.
aaa_SOURCES = foo.x
is much more easy to handle [...]
indeed. I believe you have found a bug, and I believe it is
desirable to fix it.
Though I'm not able to write a patch right now, I can write down some
hints: perhaps they will inspire someone to contribute a patch. ;-)
First, let's start with a completely different example:
wow_SOURCES = boo.cc baux.h bleah.zz
.zz.cc:
cp $ $@
Then the generated Makefile.in contains:
am_wow_OBJECTS = boo.$(OBJEXT) bleah.$(OBJEXT)
wow_OBJECTS = $(am_wow_OBJECTS)
Why? Obviously, Automake knows there is a .cc.o rule, which results
in boo.o. Automake also knows there is no rule to compile *.h to an
object file, so there is no baux.o in the list.
Most interestingly, Automake is able to discover that *.zz will be
eventually compiled into *.o, via a *.cc file.
Look at the procedure derive_suffix in automake/automake.in.
For example, derive_suffix('.zz', '$(OBJEXT)') evaluates to '.cc'.
So back to your example:
I believe Automake knows foo.cc is the last step before foo.o, and I
believe the code should be fixed to use foo.cc instead of foo.x in
the `aaa-foo.o' rule.
If you are willing to make a first iteration of the patch, I believe
it would be welcome. The next step would be to run make check with
that patch.
Hope this helps,
Stepan
Re: Sablotron and Autotools?
Hello, On Wed, Apr 25, 2007 at 02:46:55PM -0500, Robert J. Hansen wrote: What is the canonical way to test for the existence of libsablot with autoconf 2.60? well, this question shall better go to [EMAIL PROTECTED] I think you can use AC_CHECK_LIB to check for the library. Since GNU/Linux distributions often deliver the devel part separately, you shall also check for a header by AC_CHECK_HEADER. HTH, Stepan
Re: generated files in CVS
Hi,
On Tue, Apr 24, 2007 at 06:36:22PM -0600, Eric Blake wrote:
Is there any reason that doc/{stamp-vti,version.texi} are stored in CVS?
a quick check: Autoconf does not have these files in the CVS.
So it seems safe to leave them out.
Stepan
Re: Lost in automatic dependencies
Hello, On Wed, Apr 11, 2007 at 09:57:44PM +0200, Stephane Bortzmeyer wrote: Ralf Wildenhues [EMAIL PROTECTED] wrote Just making sure: you said you removed config.cache, but what about $prefix/var/tmp/config.cache? You're right. I deleted config.cache, $prefix/var/tmp/config.cache, restored my config.site and rebuilt everything and it works. I now have automatic dependencies. Thanks again. but, if I understand the situation correctly, your config.site was the root of your problem: keeping one common cache for all projects does not work. (Or, at least, is not tested.) It seems that some time ago, you configured a project with --disable-dependency-tracking, and then this seting was stored in the cache. (You might say that this is a bug in Automake, but in any case, this is something which is note ready and does not work.) Have a nice day, Stepan Kasal
Re: autoheader, fortran, and comments
Hello, On Mon, Apr 09, 2007 at 03:47:46AM -0700, j y wrote: config.h: stamp-h1 @if test ! -f $@; then \ rm -f stamp-h1; \ $(MAKE) stamp-h1; \ else :; fi sed -i '/\/\*|\*\//s/^/!/' config.h Is there any way to do this by adding a macro or something to configure.ac? sure there is, use a second parameter to AC_CONFIG_HEADERS, e.g.: AC_CONFIG_HEADERS([config.h], [mv config.h config.hx sed '/\/\*/,/\*\//s/^/!/' config.hx config.h rm config.hx]) (not tested, sorry) The option -i to sed is GNU-specific, so I replaced it to increase portability. And I changed the sed cmd to adapt for comments which span more than two lines. Have a nice day, Stepan Kasal
Re: mdate-sh borks on uid/gid containing a space
Hello, On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote: On 29 March 2007 00:26, Ralf Wildenhues wrote: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2730/focus=2740 Eric's patch seems to indicate that line 92 needs changed, too. (I haven't tested any on w32.) I don't quite understand that myself; ISTM that having -n in $ls_command should do the job for both cases. A wild guess: Though the current situation is this (quoting Eric): $ \ls -ld / drwxrwx---+ 14 eblake Users 0 Feb 2 07:58 / $ \ls -lLd doc/m4.texinfo -rw-r--r-- 1 eblake Domain Users 221922 Mar 1 14:50 doc/m4.texinfo it might be possible that even the user or group owner of / would have a blank it its name. (With Cygwin, one never knows.) So it is safer to use -n with ls /, too. Just guessing, I'm not a Cygwin user. Stepan Kasal
Re: mdate-sh borks on uid/gid containing a space
Hello again, On Thu, Mar 29, 2007 at 04:12:11PM +0100, Dave Korn wrote: On 29 March 2007 15:38, Stepan Kasal wrote: On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote: On 29 March 2007 00:26, Ralf Wildenhues wrote: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2730/focus=2740 Eric's patch seems to indicate that line 92 needs changed, too. [...] So it is safer to use -n with ls /, too. Umm, yes, that's true, but not relevant; what I was pointing out is that the -n gets added to the $ls_command variable, so it would already be included in the command invoked on line 92, and if you take a second look at the patch, you'll notice that the change to line 92 isn't about adding -n, it's about taking away -l and -d. I took a second look, and it did not help: @@ -89,7 +93,7 @@ # words should be skipped to get the date. # On HPUX /bin/sh, set interprets -rw-r--r-- as options, so the x below. -set x`ls -l -d /` +set x`$ls_command /` # Find which argument is the month. month= Cheers, Stepan
Re: shell pwd: non-POSIX variable name ??
Hi, On Thu, Mar 29, 2007 at 02:25:31PM +0200, Jules Colding posted an Automake question to the Autoconf list. (Understandable mistake, of course.) I suppose the question can be deduced from my answer. :-) What is the recommended and portable way of doing what I do above to avoid the warnings and to be nice to automake? OBJS= $(patsubst %.c,%.o,$(STUB_SRC)) this can ce written portably as: OBJS = $(STUB_SRC:.c=.o) EXTRA_DIST = $(pkgconfig_DATA:-$(LIBBRUTUS_CURRENT).$(LIBBRUTUS_REVISION).pc=.pc.in) It is not portable to use immersed variable expansion. But if LIBBRUTUS_CURRENT and LIBBRUTUS_REVISION are AC_SUBSTed variables, you can use the @...@ form here: EXTRA_DIST = $(pkgconfig_DATA:[EMAIL PROTECTED]@[EMAIL PROTECTED]@.pc=.pc.in) CWD = $(shell pwd) BARE_NAMES = $(notdir $(IDL_FILES)) LOCAL_IDL_FILES = $(addprefix $(CWD)/,$(BARE_NAMES)) I do not know any easy way to replace these. You would have to change the logic of the makefile. Needless to say that all of this worked without any warnings prior to automake-1.10. To switch these warnings off for a particular Makefile.am, use AUTOMAKE_OPTIONS = -Wno-portability To switch them off glibally, use AM_INIT_AUTOMAKE([-Wno-portability]) in your configure.ac. For your information, I found this comment in Automake 1.9.5: (and I believe is was there since 1.7 till 1.9.6) # FIXME: 'portability' warnings are currently disabled by default. # Eventually we want to turn them on in GNU and GNITS modes, but # we don't do this yet in Automake 1.7 to help the 1.6/1.7 # transition. # # Indeed there would be only two ways to get rid of these new # warnings: # 1. adjusting Makefile.am # This is not always easy (or wanted). Consider %-rules or # $(function args) variables. # 2. using -Wno-portability # This means there is no way to have the same Makefile.am # working both with Automake 1.6 and 1.7 (since 1.6 does not # understand -Wno-portability). # # In Automake 1.8 (or whatever it is called) we can turn these # warnings on, since -Wno-portability will not be an issue for # the 1.7/1.8 transition. Have a nice day, Stepan Kasal
Re: Overriding suffix based implicit rules
Hello, On Tue, Mar 27, 2007 at 05:40:06AM -0700, Artus wrote: What should I write in Makefile.am to inform automake that .c files in this specific directory are C++ source files and not C files? I tried the following with no sucess (and I do not want to rename the files). no success is far from a good description of your problem. Anyway: # Makefile.am .c.o: $(CXX) $(CXXFLAGS) -c $ -o $@ lib_LTLIBRARIES = libadn.la libadn_la_SOURCES = adn.h adn.c tim.c cyto.c since you are using lib_LTLIBRARIES, it's .c.lo which is involved here, not .c.o Another solution: Even though you cannot use the right names permanently, you can use them temporarily. Try this Makefile.am: lib_LTLIBRARIES = libadn.la libadn_la_SOURCES = adn.h adn.c tim.c cyto.c .c.lo: .c.cc: $(LN_S) $ $@ EXTRA_PROGRAMS = fake nodist_fake_SOURCES = fake.cc I tested this, and it works. The fake program is there to drag in C++ support. Please note that though the *.cc files are temporarily created, make delets them at the end, because they are intermediate. (Use info '(make)Chained Rules' to read details.) Could you live with this? Have a nice day, Stepan Kasal
Re: Shouldn't the definition of maintainer-clean be changed?
Hello Bob, On Sat, Mar 17, 2007 at 10:44:42AM -0600, Bob Proulx wrote: First off let me say that I was perfectly aware of the standards for make maintainer-clean when I posted my response to that message. There is no standard target to perform the desired operation. That poster had a very particular set of needs. My suggestion there did not in any way reflect a standard use of automake or use of the gnu standards. It was a very targeted (ab)use of the tool. I knew that. I'm sorry that I accused you and Ralf that you misinterpret the target; I was wrong in both cases. In the course of the preceding year or two, whenever I heard about mainatiner-clean, it was misinterpreted this way. (That's why I reacted so hysterically when I saw your hint on the automake list.) I cannot agree that the need is very particular. Virtually every projects' CVS build instructions start with point 1. get a clean checkout. And if the build does not work, the user wants to get back to that clean checkout. I was afraid that if we let the rumour spread, this will soon become the de-facto standard for half of the projects, and the name maintainer-clean will no longer have any meaning. So I wanted to see how do the standard makers feel about it. It would be good to have some improved functionality in this area. See also my posting asking for a clean target for generated source files. [All it needs is someone to actually do the work. :-)] http://lists.gnu.org/archive/html/automake/2007-03/msg1.html OK, so if want to do something about this, I should first implement --clean, and then start recommending it as the right tool for the purpose. Finally, a minor clarification: If `make maintainer-clean', then the GNU Standards should be changed to reflect this. The obvious disadvantage is that if the bootstrapconfigure does not finish, maintainer-clean is not usable. If configure does not finish then no Makefile based target is usable. Which may have been your point. But I think it is safe to assume a working system and in an working system configure will finish and Makefile targets will be available. It is common that a configure script ends with an error message that ``package foo is needed to build this project''. (Yes, these configure scripts are badly written, as the AC_MSG_ERROR is meant to notify about ``an error that prevents `configure' from completing,'' as the manual says. Yet is is often used in situations which prevent the build from completing.) So, in practice, one has to collect all of the pre-requisites of the projects, before a working Makefile is available. Thanks, Stepan Kasal
Re: [Autogen-users] Shouldn't the definition of maintainer-clean be changed?
Hello Bruce and all. [Omitting autogen-users, I'll send a patch submission there in a separate mail.] I started this thread with an unfortunate mail. Allow me to my current understanding of situation. On Mon, Mar 19, 2007 at 10:00:05AM -0700, Bruce Korb wrote: [...] maintainer-clean semantics do not change. [...] Yes, that was the main answer I got from the list. The definition of maintainer-clean should not change. My mail sounded that I'm in favor of changing the definition. Actually, I was under the impression that no one takes the definition seriously, so I was trying to ask: 1) Is this meant seriously? 2) If yes, how are we going to defend it? Though I failed to formulate the questions properly, I think I got my answers: 1) Yes, and it is used in practice. 2) By implementing auto* --clean which would match people's need for un-bootstrap. * How about having autoreconf (aka bootstrap) take an option: autoreconf --clean bootstrap --clean As said above, I gather that this is the way to go. Have a nice day, Stepan Kasal
Shouldn't the definition of maintainer-clean be changed?
Hello, the standards define `maintainer-clean' as a target which is only a slightly different from distclean. Besides files cleaned by distclean, it delets *.c files generated by bison, manual pages generated by latex2man, etc. For details, see my post here: http://lists.gnu.org/archive/html/autoconf/2007-03/msg00043.html But people tend to guess that this target must be the opposite to bootstrapping from CVS. I witnessed that such a great names as Bob Proulx and Ralf Wildenhues interpreted maintainer-clean this way, see the thread cited above. Moreover, I noticed that AutoGen tries to use maintainer-clean in this twisted way. Another example: when I submitted a patch that removed Makefile.in from MAINTAINERCLEANFILES to HAL, I got told that using `maintainer-clean' to delete everything generated by autotools has become a ``common practice'': http://lists.freedesktop.org/archives/hal/2007-March/007667.html I'm afraid that this might become a big mess. I think that the GNU standardization crew might help here. There is a strong need for an un-bootstrap. Which command shouls fill the gap? If `make maintainer-clean', then the GNU Standards should be changed to reflect this. The obvious disadvantage is that if the bootstrapconfigure does not finish, maintainer-clean is not usable. Or we could implement --clean options to autoconf, automake, ... all the way until we have `autoreconf --clean' and until it is trivial to implement `bootstrap.sh --clean'. I'm looking forward to hear your opinions. Have a nice day, Stepan Kasal
Re: MAINTAINERCLEANFILES in srcdir
Hello Ralf,
On Thu, Mar 15, 2007 at 09:11:37AM +0100, Ralf Wildenhues wrote:
* Stepan Kasal wrote on Wed, Mar 14, 2007 at 01:34:06PM CET:
-test -n $(MAINTAINERCLEANFILES) \
rm -f $(MAINTAINERCLEANFILES) \
cd $(srcdir) rm -f $(MAINTAINERCLEANFILES)
Then make it something like this, please:
-test -z $(MAINTAINERCLEANFILES) || \
{ rm -f $(MAINTAINERCLEANFILES) \
cd $(srcdir) rm -f $(MAINTAINERCLEANFILES); }
I'm not sure I understand why you ask for it.
Do you mean that we should write the command as if it were without the -?
Can this make any difference?
On a second thought, the two rm calls should be independent:
-test -z $(MAINTAINERCLEANFILES) || \
{ rm -f $(MAINTAINERCLEANFILES) ; \
cd $(srcdir) rm -f $(MAINTAINERCLEANFILES); }
Have a nice day,
Stepan
MAINTAINERCLEANFILES in srcdir
Hello, the target maintainer-clean contains -test -z $(MAINTAINERCLEANFILES) || rm -f $(MAINTAINERCLEANFILES) which means that the files are cleaned only in the build tree. But the files which are cleaned by maintainer-clean, but not distclean, are usually distributed, because it is supposed that the ``special tools'' needed to created them are not available on the user's machine. Could we perhaps change the above command to: -test -n $(MAINTAINERCLEANFILES) \ rm -f $(MAINTAINERCLEANFILES) \ cd $(srcdir) rm -f $(MAINTAINERCLEANFILES) (I'm willing to implemement this eventually.) Stepan
Re: generated ChangeLog
Hello, i apologize that I reply to myself. I found out there is one nit: If you write the rule for ChangeLog to Makefile.am, then Automake complains that the file does not exist at the time Automake is run. Actually, Automake suppresses the message if a rule named ChangeLog is found. But I think the right name for the target is $(srcdir)/ChangeLog, since it is a distributed file. Does this mean this is a bug in Automake? And if yes, then current implementations cannot rely on the feature, so how can one handle generated ChangeLog with current Automake? Thanks, Stepan
Re: How to include COPYING and COPYRIGHT in make install
Hello,
one nit:
On Wed, Jan 24, 2007 at 08:00:59PM +0100, Ralf Wildenhues wrote:
Please note that the docdir variable is new in Autoconf-2.60, so if you
happen to use an older Autoconf version together with your Automake,
then you also need something along the lines of
docdir = ${datadir}/doc
rather
docdir = $(datadir)/doc/$(PACKAGE)
Or have I missed something?
Have a nice day,
Stepan
ac_aux_dir not set
Hello, I encountered a problem with a configure script which used ac_aux_dir before it was set. I found out that the macro AM_AUX_DIR_EXPAND supposes that ac_aux_dir is ready. The natural way to express this assumption is: AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT]) This bug does not hit in the usual case when AM_INIT_AUTOMAKE is called before any other AM_* macros, and the above AC_REQUIRE is brought in by AC_PROG_INSTALL. In my case, AM_PROG_CC_C_O was called before AM_INIT_AUTOMAKE. I looked quickly to the Automake manual, and I haven't found the rule that AM_INIT_AUTOMAKE should be the first AM_* macro; is it really there? In any case, I suppose the attached patch should not hurt. Thanks, Stepan Kasal 2007-01-10 Stepan Kasal [EMAIL PROTECTED] * m4/auxdir.m4 (AM_AUX_DIR_EXPAND): Require AC_CONFIG_AUX_DIR_DEFAULT. Index: m4/auxdir.m4 === RCS file: /cvs/automake/automake/m4/auxdir.m4,v retrieving revision 1.7 diff -u -r1.7 auxdir.m4 --- m4/auxdir.m49 Jan 2005 14:46:21 - 1.7 +++ m4/auxdir.m49 Jan 2007 14:59:40 - @@ -47,6 +47,7 @@ AC_DEFUN([AM_AUX_DIR_EXPAND], [dnl Rely on autoconf to set up CDPATH properly. AC_PREREQ([2.50])dnl +AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl # expand $ac_aux_dir to an absolute path am_aux_dir=`cd $ac_aux_dir pwd` ])
Re: How do I *conditionally* add to INSTALL_DIRS ?
Hello, On Wed, Jan 10, 2007 at 08:19:38AM +0900, atoz wrote: if WANT_MAN_PAGES cp fooman.8 $(foomandir) fi ... and it leads to the following error ... Makefile.am:175: unterminated conditionals: WANT_MAN_PAGES_TRUE this question is easy: Automake conditionals are ended by endif, not fi. Does this solve the problem? Please post a summary of problems remaining after applying Ralf's and my hints. Regards, Stepan
Re: Preprocessing C++ only
Hello, On Mon, Jan 08, 2007 at 03:09:13PM +, Alan Larkin wrote: Tim Van Holder wrote: # Not sure if this is needed for automake; but it's needed by GNU make # (without it it will not try the .cpp.i rule). .SUFFIXES: .i this is what make understands, Automake writes it to Makefile.in automatically. Do not override it in Makefile.am. SUFFIXES = .i This is how one tells Automake about additional suffixes. But if the suffixes has the standard form (one dot, then some non-dot characters), then Automake recognizes it, so the SUFFIXES variable is not necessary (though harmless). Have a nice day, Stepan Kasal
Re: automake-1.9.6 check FAILURE: 32 of 553 tests failed...
Hello, On Tue, Dec 12, 2006 at 05:31:48PM -0800, Linda Walsh wrote: Says to report failures -- attached is output log. I'd assume there should be some other file(s) to attach? Yes, could you please cd to automake-1.9.6/tests after the failure and run: env -e VERBOSE=x TESTS=gettext.test gettext2.test ldadd.test ldflags.test \ libobj13.test libtool.test libtool2.test libtool3.test \ libtool5.test libtool6.test libtool7.test libtool8.test \ listval.test ltcond.test ltcond2.test ltconv.test \ ltdeps.test ltlibobjs.test ltlibsrc.test nobase.test \ pr72.test pr211.test pr300-ltlib.test pr307.test reqd2.test \ stdlib2.test subcond.test subobj9.test suffix2.test \ suffix5.test suffix8.test suffix10.test make -e check Then please post the output. It might be better to compress it before posting. OTOH, attaching the 1.0MB rpm to the bug report was not a good idea. I've run this a few times, few different ways. Seem to come up the same. I might have some out of date tools...not real clear at this point. It might be clear from the output of the command quoted above. Perhaps you might be able to fix some of the problems before you send the updated message? (In that case please remove the fixed tests from the list.) Have a nice day, Stepan Kasal
Re: no rule to make asm targets
Hello, On Fri, Dec 08, 2006 at 01:05:14PM +0200, Jari Strand wrote: I am sorry that I have to post again but I am still stuck with this problem. Was it so that the problem should have been fixed after changing the code to use the global target flags? I hope I have just done something wrong now, but I need to know in order to figure what to try next. Do you have any suggestion for solving this issue, can I post other files? when I saw your last reply, I tried to look to your original post, but I was not able to identify any other problem which I could look at. So I suggest that you make a tarball that shows where you are right now, put it somewhere and post an URL. (Or you can attach it to your mail, if it is small.) It might help if you simplify the example, but it is not necessary. It is much more important that you make the example as self-contained as you can, with a clear description which commands to invoke, what is the result you observe and what is the expected result. List all dependencies on the installed packages, so that it is possible to reproduce your problem. And then hope that a reader of this list will find spare time to look at the issue. (Yes, there is no guarantee that the work you invest into formulating the question will pay off, unfortunately. :-( ) Sorry that we were not able to provide better help. (At least not yet.) Have a nice day, Stepan Kasal
Re: how to exclude the COPYING file
Hello, On Fri, Dec 08, 2006 at 11:00:09AM +0100, Presario Smith wrote: AUTOMAKE_OPTIONS = foreign I'd prefer AM_INIT_AUTOMAKE([foreign]) in configure.ac, as this is a global option, affecting the whole project. But that's just a nit. Have a nice day, Stepan Kasal
Re: no rule to make asm targets
Hello, On Wed, Dec 06, 2006 at 06:21:09AM +0200, Jari Strand wrote: For example, does bin_PROGRAMS really contain only one program? Yes, [...] OK, in that case there is no need to use per-target flags. Let me show an example: bin_PROGRAMS = first second third first_SOURCES = first.c second_SOURCES = second.c third_SOURCES = third.c AM_CFLAGS = ... second_CFLAGS = ... In this example, `AM_CFLAGS' is used for all programs, with one exception: when compiling program `third', `third_CFLAGS' is used instead. This `third_CFLAGS' is called per-target variable, and overrides the corresponding general one AM_CFLAGS. The mechanism is the same in your case, when you are using *_CPPFLAGS instead of *_CFLAGS. Since you have only one program, you can set `AM_CPPFLAGS' as needed for the program `editorD', and there is no need to use the override mechanism. Then, because of some internal mechanisms of Automake, the suffix rule `.asm.o' will be used, and you can redefine it if you like. Start with the following code, adding back the things you removed to simplify the example. bin_PROGRAMS = editorD TLIB_PATH = /home AM_CPPFLAGS = -I$(TLIB_PATH)/openal/LINUX -I$(TLIB_PATH)/lungif \ -I$(TLIB_PATH)/lungif -I$(TLIB_PATH)/opengl2d3d \ -I$(TLIB_PATH)/zlib -I$(TLIB_PATH)/lpng -I$(TLIB_PATH)/ljpeg \ -I$(TLIB_PATH)/vorbis/include -DEDITOR_BUILD editorD_SOURCES = someSource.cc someAsm.asm .asm.o: $(NASM_PATH) -o $@ -f elf -dLINUX $ Have a nice day, Stepan Kasal
Re: sysconf_DATA v. dist_sysconf_DATA
Hello Ralf and all,
[sorry for the delay, I forgot this in my postponed folder]
On Fri, Nov 10, 2006 at 01:35:54PM +0100, Ralf Wildenhues wrote:
* Stepan Kasal wrote on Fri, Nov 10, 2006 at 12:40:18PM CET:
[...] So it seems that distcheck would
catch more bugs if `_build' were not a subdirectory of the expanded
tarball tree.
It would possibly catch a different set of bugs. There isn't a strict
inclusion ordering on the set of all imaginable bugs; maybe if bugs are
weighted by the likelihood by which they happen, I haven't looked into
that enough.
When srcdir is .. (or ../.. or some such), it represents a
relative path which is valid in many places.
So it is possible that the relative path would be applied to a wrong
place, probably because of the VPATH mechanism.
This can mask an error, as we observed in this thread.
OTOH, this could discover another type of error in the build scripts
of the package; I cannot imagine an actual example, but I admit it is
possible.
But I think that the former case is more common, and thus the
disadvantage overweight the advantage.
If the srcdir is ../_dist/$(distdir) or some such, it is not
probable that it would apply relatively to a wrong directory.
Would you accept the patch attached below?
Stepan Kasal
2006-12-05 Stepan Kasal [EMAIL PROTECTED]
* lib/am/distdir.am (distcheck): Move the srcdir below
`$(distdir)/_dist', so that `_build' and `_inst' are not
below it.
* tests/insthook.test: Do not depend on the actual
implementation of `distcheck'.
Index: lib/am/distdir.am
===
RCS file: /cvs/automake/automake/lib/am/distdir.am,v
retrieving revision 1.69
diff -u -r1.69 distdir.am
--- lib/am/distdir.am 15 Oct 2006 16:37:22 - 1.69
+++ lib/am/distdir.am 5 Dec 2006 18:31:05 -
@@ -315,26 +315,25 @@
# tarfile.
.PHONY: distcheck
distcheck: dist
- case '$(DIST_ARCHIVES)' in \
+ mkdir $(distdir)
+ mkdir $(distdir)/_dist
+ $(am__cd) $(distdir)/_dist case '$(DIST_ARCHIVES)' in \
*.tar.gz*) \
- GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz | $(am__untar) ;;\
+ GZIP=$(GZIP_ENV) gunzip -c ../../$(distdir).tar.gz | $(am__untar) ;;\
*.tar.bz2*) \
- bunzip2 -c $(distdir).tar.bz2 | $(am__untar) ;;\
+ bunzip2 -c ../../$(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.Z*) \
- uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
+ uncompress -c ../../$(distdir).tar.Z | $(am__untar) ;;\
*.shar.gz*) \
- GZIP=$(GZIP_ENV) gunzip -c $(distdir).shar.gz | unshar ;;\
+ GZIP=$(GZIP_ENV) gunzip -c ../../$(distdir).shar.gz | unshar ;;\
*.zip*) \
- unzip $(distdir).zip ;;\
+ unzip ../../$(distdir).zip ;;\
esac
## Make the new source tree read-only. Distributions ought to work in
-## this case. However, make the top-level directory writable so we
-## can make our new subdirs.
- chmod -R a-w $(distdir); chmod a+w $(distdir)
+## this case.
+ chmod -R a-w $(distdir)/_dist
mkdir $(distdir)/_build
mkdir $(distdir)/_inst
-## Undo the write access.
- chmod a-w $(distdir)
## Compute the absolute path of `_inst'. Strip any leading DOS drive
## to allow DESTDIR installations. Otherwise $(DESTDIR)$(prefix) would
## expand to c:/temp/am-dc-5668/c:/src/package/package-1.0/_inst.
@@ -344,8 +343,8 @@
## create very long directory names.
dc_destdir=$${TMPDIR-/tmp}/am-dc-/ \
?DISTCHECK-HOOK? $(MAKE) $(AM_MAKEFLAGS) distcheck-hook \
- cd $(distdir)/_build \
- ../configure --srcdir=.. --prefix=$$dc_install_base \
+ $(am__cd) $(distdir)/_build \
+ ../_dist/$(distdir)/configure --srcdir=../_dist/$(distdir)
--prefix=$$dc_install_base \
?GETTEXT? --with-included-gettext \
## Additional flags for configure. Keep this last in the configure
## invocation so the user can override previous options.
Index: tests/insthook.test
===
RCS file: /cvs/automake/automake/tests/insthook.test,v
retrieving revision 1.12
diff -u -r1.12 insthook.test
--- tests/insthook.test 14 May 2005 20:28:55 - 1.12
+++ tests/insthook.test 5 Dec 2006 18:31:06 -
@@ -40,7 +40,7 @@
installcheck-local:
test -f $(bindir)/foo
test -f $(bindir)/foo-$(VERSION)
- : $(top_srcdir)/../ok
+ test -n $$stampdir : $$stampdir/ok
END
echo 1 foo
@@ -50,7 +50,7 @@
$AUTOMAKE
./configure
-$MAKE distcheck
+stampdir=`pwd` $MAKE -e distcheck
# Sanity check to make sure installcheck-local was run.
test -f ok
Re: no rule to make asm targets
Hello, On Mon, Dec 04, 2006 at 02:19:35PM +0100, Ralf Wildenhues wrote: In a plain Makefile, you'd do that with this line: .SUFFIXES: .asm .o In a Makefile.am, you instead write this: SUFFIXES = .asm .o but it is not necessary in normal cases[*], Automake can deduce the suffixes from the rules, and generate the .SUFFIXES: line. Have a nice day, Stepan Kasal Footnote: [*] Normal case means here that each suffix starts with a dot and does not contain any other dot.
Re: Circular dependency
Hello, On Thu, Nov 30, 2006 at 09:31:19AM +0100, Guillaume Rousse wrote: Stepan Kasal wrote: You specified the dependency: corelib/camlimages.ml -- Makefile This is not correct. You should specify the ultimate primary sources instead of `Makefile'. Prehaps `Makefile.am' is enough? It was to catch configure runs, so I used config.status instead. so it looks like this now: Makefile -- Makefile.in -- .depend -- corelib/camlimages.ml -- -- config.status There is still a problem with this setup, you are breaking the rule that distributed files should not depend on non-distributed ones. Let me explain: Imagine you release a tarball of your package, and someone unpacks it and runs the usual ./configure ; make to build it. config.status was created, so automake has to be run to refresh Makefile.in. This is not the expected behaviour: Makefile.in is supposed to stay unmodified. This cas cause real-world problems: when someome performs two VPATH builds from the same source tree, the two rebuilds of Makefile.in coming from the two builds present a race condition. I'm afraid it can be easy to avoid this problem, though. One solution is to enhance Automake so that it does dependency tracking of ML programs. A kludge might be to emulate the dependency tracking by using make-time includes. If you are willing to do it portably, you need the ugly lines with @am__quote@, mentiend by Ralf. Or, if you are willing to limit the users to GNU make, you could hide the include directive like this: MY_DEPENDENCIES = include make.deps $(MY_DEPENDENCIES) HTH, Stepan
Re: Circular dependency
Hello, On Thu, Nov 30, 2006 at 10:24:19AM +0100, Guillaume Rousse wrote: So, to get back at my original question, what's the proper way of expressing dependencies for a generated source file through configure-time substitution: foo: foo.in config.status or, as in autoconf documentation: foo: foo.in Makefile if the you have AC_CONFIG_FILE([foo]) in configure.ac, then the former is the proper way, and it is created automatically by automake so you usually do nothing. If, OTOH, you have special needs, you have to put something like this in your Makefile.am: EXTRA_DIST = foo.in foo: foo.in Makefile sed 's/THIS/$(THAT)/g' $(srcdir)/foo.in $@ Using Makefile instead of config.status causes rebuild not only upon reconfigure, but also when you edit this Makefile.am, perhaps modifying the sed command. Have a nice day, Stepan
Re: Circular dependency
Hello, On Tue, Nov 28, 2006 at 03:39:37PM +0100, Guillaume Rousse wrote: Ralf Wildenhues wrote: The automake one happens at the time 'automake' is run, the included file is literally put into Makefile.in. a nit: the automake-included file does not neceserilly get copied to Makefile.in. Is is processed as if it were part of the Makefile.am. But I still didn't understood how to force generation at dependencies using a specific depcomp mode at configure time. I sent a mail regarding this issue to the list, I didn't received any answer sofar. In my previous mail, I did not try to solve your problem, I do not understand it. I was answering just the particular question why a circular dependency was reported. I'm suspecting email issues, however, as I don't saw your reply on the list (I only received the direct reply), and I didn't saw Stepan's answer neither. My answer was CC'ed to you, but your servers refuse connections from my computer. Have a nice day, Stepan Kasal
Re: Circular dependency
Hello, On Mon, Nov 27, 2006 at 05:10:46PM +0100, Guillaume Rousse wrote: Ralf Wildenhues wrote: * Guillaume Rousse wrote on Thu, Nov 23, 2006 at 04:46:50PM CET: However, make keep complaining about a circular dependency issue: make[1]: Circular corelib/camlimages.ml - Makefile dependency dropped. I guess it's because generated makefile has itself a rule triggering configure again, but I can't find where it's related to corelib/camlimages.ml, neither how to break the loop. You're providing too little information for me to be able to deduce the loop. Can you post the whole Makefile.am (and whatever changes you made to Automake, if any)? Here it is. I did no special modification tu automake. The circular dependency is this: Makefile -- Makefile.in -- .depend -- corelib/camlimages.ml -- -- Makefile Comments: * Makefile.in -- .depend This is because automake creates Makefile.in from Makefile.am and all included files. Your Makefile.am includes .depend. * .depend -- corelib/camlimages.ml via the $(OCAMLSOURCES) You specified the dependency: corelib/camlimages.ml -- Makefile This is not correct. You should specify the ultimate primary sources instead of `Makefile'. Prehaps `Makefile.am' is enough? I hope this hint helps you to find a fix. Have a nice day, Stepan Kasal
Re: adding libraries and header file directories
Hello Ralf,
On Fri, Nov 10, 2006 at 05:50:18PM +0100, Jim Rainville wrote:
+ aclocal-1.10 -I m4
...
configure.ac:80: warning: macro `AM_LIBTOOLFLAGS' not found in library
On Sun, Nov 12, 2006 at 06:43:44PM +0100, Ralf Wildenhues wrote:
The warning shouldn't be there. Please post the configure.ac code that
deals with this, so we can find out whether there is a bug in automake.
just a quick inspection of the code shows that there is a bug in
aclocal. Observe:
; echo 'AC_SUBST( AM_CFLAGS, value)' configure.ac ; aclocal
configure.ac:1: warning: macro `AM_CFLAGS' not found in library
;
If my guess is right, then the workaround is easy; use
AC_SUBST([AM_LIBTOOLFLAGS], [value])
which is the proper quoting anyway.
The code in aclocal.in looks like this:
if (! search /(^|\s+)(AM_[A-Z0-9_]+)($|[^\]\)=A-Z0-9_])/)
{ ...
msg (..., warning: macro `$2' not found in library);
}
Actually, I think this whole `if' can be deleted. As a comment in
add_macro in aclocal.in puts it:
# Ignore unknown required macros. Either they are not really
# needed (e.g., a conditional AC_REQUIRE), in which case aclocal
# should be quiet, or they are needed and Autoconf itself will
# complain when we trace for macro usage later.
Have a nice day,
Stepan
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Fri, Nov 10, 2006 at 11:27:18AM -0700, David Everly wrote: I have been working to follow this. It seems however that I need dist_TESTS, but this seems to not work so perhaps I should do this instead: EXTRA_DIST = $(TESTS) yes, that is fine. One nit about style: I would rather use dist_check_SCRIPTS = $(TESTS) Or perhaps the other way round. Let me give a more general example; perhaps some of the tests are compiled programs, some are built stripts and some are distributed scripts. Then you would have: check_PROGRAMS = foo bar foo_SOURCES = foo.c bar_SOURCES = bar.c baz.c nodist_check_SCRIPTS = this # this is created from this.in by configure dist_check_SCRIPTS = that another TESTS = $(check_PROGRAMS) $(nodist_check_SCRIPTS) $(dist_check_SCRIPTS) Have a nice day, Stepan Kasal
Re: Using automake in conjunction with kbuild Makefile
Hello Steve, I do not have any experience with kbuilt, but I'll try to generate some hins anyway: On Mon, Nov 13, 2006 at 11:48:29AM +0100, Steve Kreyer wrote: DEFAULT_INCLUDES = [EMAIL PROTECTED]@ two nits about this line: No need to use @..@, use $(abs_top_srcdir) instead. Why do you re-define DEFAULT_INCLUDES? Wouldn't it be more appropriate to use AM_CPPFLAGS? (But maybe I'm missing something.) example a make distcheck will fail because the module sources will not be copied into the build environment of the distcheck... Thank you for the description of the situation, but I think your description of the actual problem could be more exact. `make distcheck' is just an automated way to check for features which should every package support. The feature you are speaking about is so called ``vpath build'', when srcdir != builddir. So you can do the same manually: make dist-bzip2 mkdir _check (cd _check ; tar xjf ../*.bz2) #chmod -R -w _check mkdir _build; cd _build ../_check/configure make Does this work? Does it work if you add the chmod command in the middle, to make the source tree read-only? If not, what is the error message? Fix it or post it to this list to get some help. Or perhaps you are not willing to support vpath builds. (Does kbuild usually support them?) If that is the case, you do not want to use `make distcheck', at least not the complete version brought to you by automake. Have a nice day, Stepan
Re: false positive result with 'make distcheck'
Hello, regarding the problem discussed earlier in this thread: On Tue, Sep 05, 2006 at 06:17:20PM +0200, Ralf Wildenhues wrote: Now, even when you stick $(srcdir)/ in front of the prerequisites, still VPATH searching applies. Since source tree of the distcheck source (that below /tmp/rpmbuildupdate-0.7/rpmbuildupdate-0.7) does not contain the *.in files, but VPATH contains .., the `make' executed inside the directory /tmp/rpmbuildupdate-0.7/_build finds the file ../../rpmbuildupdate.in.in and happily uses them; that is: the second ../ is your $(srcdir)/, I made a suggestion, and Ralf oposed to it. On Fri, Nov 10, 2006 at 01:35:54PM +0100, Ralf Wildenhues wrote: * Stepan Kasal wrote on Fri, Nov 10, 2006 at 12:40:18PM CET: [...] So it seems that distcheck would catch more bugs if `_build' were not a subdirectory of the expanded tarball tree. It would possibly catch a different set of bugs. There isn't a strict inclusion ordering on the set of all imaginable bugs; maybe if bugs are weighted by the likelihood by which they happen, [...] I think your reasoning is too teoretical. I would put it like this: When srcdir is .. (or ../.. or some such), than it is a relative path which is valid in every directory. OTOH, if srcdir were ../_dist/$(distdir) then it would be invalid in most places, so it is could be used relatively to other directory then the one which it was meant for. That's why I think `make distcheck' should use something like _dist/$(distdir) _build _inst Have a nice day, Stepan
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Wed, Nov 08, 2006 at 05:46:23PM -0700, David Everly wrote: I put together a test case before sending my email, the only line in the one Makefile.am is the one I gave containing test.txt. well, I created configure.ac and Makefile.am: $ cat configure.ac AC_INIT([this], [1.0], [EMAIL PROTECTED]) AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT $ cat Makefile.am sysconf_DATA = $(top_srcdir)/test.txt $ Then I run: autoreconf -i ./configure make distcheck and the distcheck failed with the expected message: make[1]: *** No rule to make target `../test.txt', needed by `all-am'. Stop. I used recent CVS build of Autoconf, and a CVS version of Automake which is slightly older than 1.10. Stepan
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Thu, Nov 09, 2006 at 06:30:42AM -0700, David Everly wrote: If I understand this correctly, my error was in the use of $(top_srcdir). So I'm wondering under what circumstances it would be correct to use $(top_srcdir) and $(srcdir). a very quick answer: do not use $(top_srcdir) nor $(srcdir). (I apologize that I have not noticed this earlier.) In variables interpreted by Automake (like sysconf_DATA), the $(srcdir) prefix is not needed. It is possible that new versions of Automake were patched to delete it, but it does not belong there. To enhance the above advice: do not use $(srcdir) (and such) until you encounter a problem which will force you to use them. And I think that when you are forced to use $(srcdir) in Makefile.am, it'll be in a _rule_, not in a variable. This is just a rule of thumb, it is possible that others will correct/amend it. HTH, Stepan Kasal
Re: How do you add an executable command into automake
Hello, On Wed, Nov 08, 2006 at 10:00:45AM -0500, Jeff Safier wrote: We have a message parser that generates a header file which is included in the actual source file. then you have to write a standard make rule for the header. The rule will get copied from Makefile.am to Makefile.in and Makefile, as discussed in the other thread. To ensure that the header is generated before the build starts, add it to BUILT_SOURCES. An example: foo.h: foo.input message_parser foo.input $@ BUILT_SOURCES = foo.h See also http://sources.redhat.com/automake/automake.html#Sources In the other thread, On Wed, Nov 08, 2006 at 10:13:12AM -0500, Pat Suwalski suggested: main.c: generatedheader.h to ensure that the header gets built. But this is not healthy: First, if main.c is not touched, it will stay older than the header, and thus generatedheader.h, main.o, and the application will be rebuilt on a subsequent run of `make', eg. during `sudo make install'. Second, I suppose that main.c is distributed and generatedheader.h is not. But distributed files are not allowed to depend on non-distributed ones. In short, do not do this. Have a nice day, Stepan Kasal
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Wed, Nov 08, 2006 at 11:29:39AM -0700, David Everly wrote: I should have used this (because test.txt is not constructed): dist_sysconf_DATA = $(top_srcdir)/test.txt However, I've regularly run 'make distcheck' and it gives no error with the original sysconf_DATA. How can this be? `make distcheck' creates a tarball, unpacks it to a new directory and runs build and install there. This implies that test.txt was installed during the process. So it seems it was available. When you run `make dist' with the old setup, is test.txt packed in the resulting tarball? Perhaps the file was mentioned in EXTRA_DIST, or another list of distributed files. In that case it would not be strictly necessary to use `dist_sysconf_DATA' instead of `sysconf_DATA'. But in most cases, it is more readable to use `dist_sysconf_DATA'. HTH, Stepan
Re: acloca20 test intermittent failure
Hello Greg and Ralf,
I think I have found the bug now.
There were two suspects: aclocal and autoconf.
First, I tried to find out whether aclocal does its work correctly by
that unfortunate grep (should have been `grep acinclude aclocal.m4').
But then Greg posted the diff, and I had an idea: perhaps autoconf
does not refresh `configure', even though --force was given.
And indeed, this was the problem!
autoconf passes --force to autom4te. autom4te then obediently
invalidates the cached output and runs m4 to create an updated one
and stores it to the cache.
But then it notices that the output file has the same time stamp as
the just computed output, and refrains from re-creating it.
The fix is obvious: `autom4te' should always create the output file,
if --force was given. Patch attached.
I committed it to the Autoconf CVS.
Greg, if you are willing to test the fix, then please build and
install CVS Autoconf or apply the patch to autoconf-2.60 and build
and install it. Then apply Ralf's patch to acloca20.test (--force).
Then the test should pass.
Have a nice day,
Stepan
---
Two side notes:
1) Ralf's patch decreased the failure rate, because there was more
work to do. The bug hit only if the m4 run was finished in the same
second in which the old configure was created.
2)
On Tue, Oct 24, 2006 at 02:29:01PM +0200, Ralf Wildenhues wrote:
Since we fixed autoconf/lib/autom4te.cfg in Autoconf 2.60, now when we
call $ACLOCAL, the traces that were created by the $AUTOCONF before are
sufficient; [...]
I think that this is not true. aclocal uses language
`Autoconf-without-aclocal-m4', while autoconf uses language
`Autoconf'. The languages use different lists of input files (the
former language does not include aclocal.m4), thus their caching
always stays disjoint.
2006-10-24 Stepan Kasal [EMAIL PROTECTED]
* bin/autom4te.in: With --force, always refresh the output
file. Problem reported by Greg Schafer [EMAIL PROTECTED].
Index: bin/autom4te.in
===
RCS file: /cvsroot/autoconf/autoconf/bin/autom4te.in,v
retrieving revision 1.102
diff -u -r1.102 autom4te.in
--- bin/autom4te.in 16 Oct 2006 20:58:44 - 1.102
+++ bin/autom4te.in 24 Oct 2006 15:54:41 -
@@ -987,7 +987,7 @@
# We now know whether we can trust the Request object. Say it.
verb the trace request object is:\n . $req-marshall;
-# We need to run M4 if (i) the users wants it (--force), (ii) $REQ is
+# We need to run M4 if (i) the user wants it (--force), (ii) $REQ is
# invalid.
handle_m4 ($req, keys %{$req-macro})
if $force || ! $req-valid;
@@ -1026,10 +1026,10 @@
}
else
{
-# Actual M4 expansion, only if $output is too old. STDOUT is
-# pretty old.
+# Actual M4 expansion, if the user wants it, or if $output is old
+# (STDOUT is pretty old).
handle_output ($req, $output)
- if mtime ($output) mtime ($ocache . $req-id);
+ if $force || mtime ($output) mtime ($ocache . $req-id);
}
# If we ran up to here, the cache is valid.
remove the /dev/null in the heart of autom4te
Hello,
some time ago I noticed that autom4te calls m4 with stdin redirected
to /dev/null. The redirection was a hack to work around a problem
with CVS m4.
The bug was discussed here
http://lists.gnu.org/archive/html/m4-discuss/2006-04/threads.html
and resolved by Eric here
http://lists.gnu.org/archive/html/m4-patches/2006-09/msg00035.html
This allowed me to remove the hack from autom4te, see the attached
patch, which I committed.
Note:
This patch was one of the two pre-requisities for teaching autom4te
to handle `-' as a command line parameter.
The other one is to tell Automake/XFile.pm about `-' about it;
I'm not volunteering for that because of Perl. ;-)
The third step would be to tell the caching in autom4te that such
runs cannot be cached.
(And then we could implement `autoconf -'.)
Have a nice day,
Stepan Kasal
2006-10-24 Stepan Kasal [EMAIL PROTECTED]
* bin/autom4te.in (handle_m4): Do not redirect stdin to
/dev/null since the heuristics for interactive behaviour was
fixed in CVS m4.
Index: bin/autom4te.in
===
RCS file: /cvsroot/autoconf/autoconf/bin/autom4te.in,v
retrieving revision 1.103
diff -u -r1.103 autom4te.in
--- bin/autom4te.in 24 Oct 2006 15:57:57 - 1.103
+++ bin/autom4te.in 24 Oct 2006 18:10:54 -
@@ -454,8 +454,6 @@
# Run m4.
#
- # Neutralize its stdin, so that GNU M4 1.5 doesn't neutralize SIGINT.
- #
# We don't output directly to the cache files, to avoid problems
# when we are interrupted (that leaves corrupted files).
xsystem ($m4
@@ -465,7 +463,6 @@
. @[EMAIL PROTECTED] . $req-id . t
. join (' --trace=', '', sort @macro)
. . files_to_options (@ARGV)
- . ' /dev/null'
. $ocache . $req-id . t);
# Everything went ok: preserve the outputs.
Re: Dependency tracking of pre processed Assembler files
Hello Ralf, you wrote: Further note a small buglet in m4/as.m4: - without no-dependencies, we should not compute depmode. you mean that _with_ no-dependencies, we shouldn't compute depmode, right? Stepan
Re: Dependence on object files listed in link script
Hello,
On Wed, Oct 04, 2006 at 11:59:40AM +0800, Tzu-Chien Chiu wrote:
Makefile.am
bin_PROGRAMS = bar
bar_LDADD = @top_builddir@/xyz.la
bar_DEPENDENCIES = $(bar_LDADD) @many_objs@
a few nits first: all AC_SUBSTed variables are available as make
variables, so you can use $(top_builddir) and $(many_objs).
Actually, this is the prefferred way.
Consequently, you can use
many_objs='$(top_builddir)/foo.lo ...'
in your configure.ac.
Another nit: if the above snippet comes from top level Makefile, then
there is no reason to use top_builddir; top builddir is the current
directory. This simplifies the situation:
configure.ac:
many_objs='foo.lo ...'
AC_SUBST(many_objs)
Makefile.am:
bin_PROGRAMS = bar
bar_LDADD = xyz.la
bar_DEPENDENCIES = $(bar_LDADD) $(many_objs)
linkscript.ld:
SECTIONS {
.a: { foo.o }
..
}
When the number of object files grows, it's difficult to maintain
these files. Better approach anyone, please?
I can see only one remaining problem: both linkscript.ld and
configure.ac contain the same long list of objects.
Then you can select one file, which will have the list, and the other
ones will be generated.
First solution:
linkscript.ld would be the primary source, and configure.ac would do
this:
many_objs=`sed -n '/^SECTIONS/,/^}/{
s|.*{ *\(.*\)\.o *}.*|$(top_builddir)/\1.lo|p
}' $srcdir/linkscript.ld |tr '\n' ' '`
Another solution:
linkscript.ld might be generated by a rule in Makefile.
Actyally, the variable many_objs could be defined directly in
Makefile.am, too. Something like this:
many_objs = foo.lo bar.lo ..
linkscript.ld: Makefile
( \
echo SECTIONS {; \
for obj in $(many_objs:.lo=.o); do \
echo .a { $$obj }; \
echo }; \
) $@
Or you can write an awk or ruby script to generate linkscript.ld from
a list of object files passed as parameters.
Actually, I'm afraid that you real situation might be a bit more
complicated than the simplified example which you posted, but I hope
that you find my suggestions inspirative anyway.
If a problem remains, feel free to ask again.
Have a nice day,
Stepan Kasal
Re: autoreconf not passing -I option to aclocal
Hello, [let's move to the automake list; please keep Guillaume in the cc] On Mon, Oct 02, 2006 at 11:39:45AM +0200, Guillaume Rousse wrote: Moreover, it requires me to specify a path to a file external to my package, which I don't want to do. well, this is the root of the problem: Your package should be rebuildable by others. If the file ocaml.m4 is ``external'' to your project, then others have to install it before rebuilding your package. Then we can suppose that ocaml.m4 is installed in the system aclocal directory, eg. /usr/share/aclocal, on in another directory, which is listed in the file `dirlist'. (See the aclocal info documentation for details about the `dirlist' file.) Though it might not be clear from the documentation, `aclocal -I' should be used only with subdirectories inside your project. In other cases, you should have a `system' installation of the *.m4 file, using the `dirlist' file. (It is possible /usr/share/aclocal/dirlist is read-only in your case, perhaps because you do not administer the system. Then your only option is to make a local installation of Automake under your $HOME directory.) Have a nice day, Stepan Kasal
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
Re: Cross-compiling support (was: Multilib support)
Hello, On Fri, Sep 22, 2006 at 10:54:20PM +0800, Tzu-Chien Chiu wrote: 2006/9/22, Stepan Kasal [EMAIL PROTECTED]: But this does not mean tha BUILD_CC has to be set! If BUILD_CC is empty, this just makes CC empty. AC_PROG_CC then does its work. (The variable CC overrides the test only if it is nonempty.) 1. I understand, but under which circumstances native configure/build will go wrong if BUILD_CC is not empty? I'm not sure I understand the question. Generally you should not set BUILD_CC. But Autoconf enables you to set CC manually, in case you want to override the autodetection. Similarily, if you need to override the autodetection in the sub-configure, you can set BUILD_CC. As I said, you usually do not need to override it. 2. Texinfo's way works for me, but just for curious if there are other (tricky) approaches for mulit-host builds? For example projects, please? I think others mentioned some examples in this thread. (binutils, gcc, ...) Some of these projects might be confusing because they may not use the latest versions of autotools. Stepan
Cross-compiling support (was: Multilib support)
Hello,
On Thu, Sep 21, 2006 at 04:34:35PM +0200, Ralf Corsepius wrote:
On Thu, 2006-09-21 at 21:36 +0800, Tzu-Chien Chiu wrote:
I've read configure.ac and Makefile.am of texinfo. Here is how it works.
[...]
I'm afraid you have not understood the trick.
Perhaps you could try to cross-compile texinfo, watching how the
build works.
Normally with autoconf/automake, you need 2 different build-directories,
each individually being configured for one host, because
autoconf/automake only support one host at a time per configure script.
To be able to support this, you'll need to implement a toptevel
configure script, which configures sub-directories this way. [...]
And the trick in Texinfo is based on this, of course.
But the native build is performed in a subdirectory of the main build
directory.
So when cross-compiling, a secondary configure is run from the main
one, configuring for a native build. And an Automake conditional
(TOOLS_ONLY) is used to limit the native build only to the tools
which are needed for the ``bootstrap''.
[...] When building native tools, the variables CC, AR, and
RANLIB copied from the their BUILD_* environment variable
counterparts.
Yes.
The users have to manually set BUILD_CC, BUILD_AR, BUILD_RANLIB before
running 'configure', right?
No.
I thought there would be AC_PROG_*-like macros for these?
The configure.ac contains AC_PROG_CC.
When configure is run for a native build, this macro searches
for a native C compiler. So when the main configure invokes itself
recursively for the build of native tools, this macro finds the
native compiler.
Actually, the recursive call looks like this:
CC=${BUILD_CC} AR=${BUILD_AR} RANLIB=${BUILD_RANLIB} \
${confdir}/configure --build=${build} --host=${build}
But this does not mean tha BUILD_CC has to be set!
If BUILD_CC is empty, this just makes CC empty. AC_PROG_CC then does
its work. (The variable CC overrides the test only if it is nonempty.)
Yes, I agree this is tricky, yet I think this aproach is appropriate
for a small project.
Have a nice day,
Stepan Kasal
Re: Multilib support
Hello, Ralf Corsepius has answered the question about AM_ENABLE_MULTILIB, and then, on Thu, Sep 21, 2006 at 09:52:25AM +0200, he wrote: I need to build *both* the native and the cross-compiled library at the same time (one-time configure script and make), rather than *either one* of them. This is a completely different problem and not related to multilibs at all. [...] What you are looking for is simultaneously building for the build system (native) and for the host (cross). Only very few packages support this. autoconf/automake doesn't support it by themselves. my previous answer targeted this second problem (as I do not have any experience with multilib). I'm guess the basic tools packages, like binutils and gcc, have to support a ``bootstrap'' which involves this. But these packages are too complex. That's why I suggested to study texinfo/configure.ac (from version 4.8 or newer), which does build a couple of native tools, which are then needed for the main cross-platform build. Texinfo is a smaller package, and thus should serve as a more comprehensive example. Feel free to ask me about the details of it. HTH, Stepan Kasal
Re: calling autoreconf and minimizing rebuilds
Hello Ralf, On Fri, Sep 08, 2006 at 09:50:48PM +0200, Ralf Wildenhues wrote: +test -f $HOME/.autom4te.cfg exit 77 [...], but better be safer than sorry: this test does not need to be executed on many systems in order to be effective. you are right, of course; thanks for explanation. For the tail of the script, I would use something like: $ACLOCAL $AUTOCONF : stamp $sleep $AUTOMAKE test -z `find configure -newer stamp` Running automake never causes an updated `configure' script. Sure, sorry for the mistake. Closer. We need to sleep before the first aclocal, I do not understand why, but I'm afraid it has something to do with your explanation how aclocal and autm4te work. I would be grateful for an explanation. [...] and sleep before the stamp (otherwise it's not guaranteed to be younger than configure), Why does stamp has to be younger than configure? Actually, I would use `test -r configure stamp' if it were portable. and $status is forbidden. And aclocal already fails with 63 if autoconf is too old. And I would like to be stronger (compare aclocal7.test) in that aclocal should not cause autoconf to rebuild configure either. Finally, using and || inside if-then or else clauses is unhealthy with `set -e' on some BSD shells. Thanks for fixing all these. * configure.ac: Preserve original values of `$AUTORECONF' and `$AUTOHEADER', to avoid the `missing' script. * tests/defs.in: Adjust. You deleted am_AUTORECONF from the code, but not from the chlog entry. I suggest to reinstert it to the code, to prevent an unpleasant surprise later. Thanks for your work! Stepan
Re: calling autoreconf and minimizing rebuilds
Hello Ralf, On Mon, Sep 11, 2006 at 01:22:31PM +0200, Ralf Wildenhues wrote: * Stepan Kasal wrote on Mon, Sep 11, 2006 at 12:26:34PM CEST: [sleep before the first aclocal call] thank you that you kindly repeated the explanation for me. I apologize that I was not able to see it in your previous mail. Why does stamp has to be younger than configure? ... the output of `ls -1t configure newer' Oh, so the extra sleep is the result that you are not using find configure -newer stamp [am_AUTORECONF] is merely an optimization, is does not harm execution. I did not understand that the eventual omission of this code is actually harmless. Thanks for your explanation. Have a nice day, Stepan
Re: trying to install docs that are distributed with my package...
Hello, On Mon, Aug 28, 2006 at 06:04:13PM -0700, Tyler MacDonald wrote: Ed Hartnett [EMAIL PROTECTED] wrote: It sounds like the best plan would be to add a flag to configure that indicates you want to build docs, like --with-build-docs using AC_ARG_WITH. [...] a quick comment from a purist: --enable-build-docs, defined using AC_ARG_ENABLE would be more appropriate here. (These two are functionally equivalent, it's just a convention, but following it might prevent confusion.) As far as the rest of the question is concernet, it might help to see an example. Perhaps the problem is that version.texi gets represhed and triggers the rebuild. Could you please post a link to a tarball which exhibits the problem? (If you observed the problem when building from a CVS checkout, please verify that it reproduces with a tarball made by `make dist'.) Have a ncie day, Stepan Kasal
Re: distdir unset in subdir Makefiles?
Hello Alexandre, On Mon, Aug 28, 2006 at 10:04:09AM +0200, Alexandre Duret-Lutz wrote: DF == David Fang [EMAIL PROTECTED] writes: DF I've noticed that the distdir variable in generated Makefile.in's DF only appears in the top-level Makefile.in, however, it is not set in DF subdirectories' Makefile.in's. Is this intentional? Yes. When packages are nested the subpackage doesn't know the distdir value, it has to be passed by the parent. I'm afraid your answer does not answer the David's question. Let me quote the second paragraph: DF In one instance, I wished to manually inspect the result of one of DF the subdirectories' make distdir, but had to pass in these two variables DF by hand, slightly inconvenient. Is there a rationale for omitting these DF two variables in subdir's Makefile.in's? The suggestion is that one might occassionally need to do `make distdir' in a subdirectory of a project. (No subpackages are involved.) My answer was that the advantage of shortening each makefile by two lines is bigger than the discomfort reported, because the need for non-top `make distdir' is very rare. (But I was not sure whether this is the right answer, so I decided to wait for a better answer from someone else.) Stepan Kasal
Re: how to install man pages to directory man3f?
Hello, installed in man3, man3f, and man3f90. indeed, these non-standard man subdirectories are not aupported by the MANS primary. But you can use the _DATA primary: man3fdir = $(mandir)/man3f man3f_DATA = foo.3f man3f90dir = $(mandir)/man3f90 man3f90_DATA = foo.3f90 If you used the same for man3, automake would complain about `man3_DATA'. But the workaround is easy: man3nulldir = $(mandir)/man3 man3null_DATA = foo.3 Have a nice day, Stepan
Re: Error testing automake 1.9.6
Hello, On Wed, Aug 09, 2006 at 10:07:17PM +0200, Pierre wrote: * Pierre wrote on Mon, Aug 07, 2006 at 08:29:53AM CEST: # make check [...] PASS: aclocal.test PASS: aclocal3.test FAIL: aclocal4.test Here are the log file. it seems that the standard Unix command `test' (which is even a builtin in most shells) is replaced by something else: test ! -f aclocal4-1.0/lib/foo.c SHA test passed! MD5 test passed! MD2 test passed! MD4 test passed! RIPEMD test passed! HMAC test passed! ARC4 test passed! DES test passed! AES test passed! Twofish test passed! Blowfish test passed! where's your certs dir?make: *** [check-not-foo] Error 177 If you rename that program/alias, things will work again. Have a nice day, Stepan
Re: Multilib support
Hello, On Tue, Aug 08, 2006 at 08:18:32PM +0800, Tzu-Chien Chiu wrote: I need to build *both* the native and the cross-compiled library at the same time (one-time configure script and make), rather than *either one* of them. FWIIW, the Texinfo configure does this: if a cross compile build is required, the configure script first configures in a subdirectory for a native build, then it continues configuration for the main build. Consult texinfo-4.8/configure.ac for details. Feel free to ask if anything of the trick is not clear. Have a nice day, Stepan Kasal
Re: autom4te.cache?
Hello, On Sat, Aug 05, 2006 at 03:13:22PM +0100, Paulo J. Matos wrote: I'm getting a directory autom4te.cache in my tree with big files in this is a cache produces by autom4te, the workhorse behind autoconf and aclocal. The usual solution is to ignore it, and add it to .cvsignore Some people do not like the cache, and suggest that you switch it off by adding --no-cache to ~/.autom4te.cfg Quoting from `info autom4te': |As another additional feature over `m4', `autom4te' caches its | results. GNU M4 is able to produce a regular output and traces at the | same time. Traces are heavily used in the GNU Build System: | `autoheader' uses them to build `config.h.in', `autoreconf' to | determine what GNU Build System components are used, `automake' to | parse `configure.ac' etc. To save the long runs of `m4', traces are | cached while performing regular expansion, and conversely. This cache | is (actually, the caches are) stored in the directory `autom4te.cache'. | _It can safely be removed_ at any moment (especially if for some | reason `autom4te' considers it is trashed). | | `--cache=DIRECTORY' | `-C DIRECTORY' | Specify the name of the directory where the result should be | cached. Passing an empty value disables caching. Be sure to pass | a relative file name, as for the time being, global caches are not | supported. | | `--no-cache' | Don't cache the results. | | `--force' | `-f' | If a cache is used, consider it obsolete (but update it anyway). BTW, autom4te is part of the Autoconf, so if you have more questions, please direct them to [EMAIL PROTECTED] Have a nice day, Stepan
Re: Creating subdirs of distdir
Hello, On Fri, Aug 04, 2006 at 02:54:23PM +0200, Alexandre Duret-Lutz wrote: I'm installing this as follows, removing another reference to DISTDIRS in dist.am, fixing distdir.test so it passes, and fixing the (c) year of pr2.test, thank you very much for the fixes. (I wonder why I thought that distdir.test worked for me.) Stepan
Re: need to install (but not build or distribute) something to the bin directory...
Hello, On Wed, Aug 02, 2006 at 07:30:47PM -0600, Ed Hartnett wrote: [...] gcc to produce an extra output file, called libnetcdf.def. ... So how do I tell automake that there is a file I would like installed, but not specially built nor included in the distribution? I'm sure there is something very easy I am missing here... my wild guess is that you need bin_DATA = libnetcdf.def Or you can use nodist_bin_DATA, if it makes it more readable for you. (*_DATA are not distributed by default.) You might face complaints that there is no rule for the file; in that case, write one: libnetcdf.def: libnetcdf.dll @: HTH, Stepan
Re: automake 'dist' target distributes built source file
Hello, let me take this opportunity to wrestle with a myth: On Sat, Jul 22, 2006 at 07:19:31PM +0200, Bruno Haible wrote: automake-1.9.6 insists on distributing a file, although I have ... - listed it in BUILT_SOURCES and in CLEANFILES. We all know what CLEANFILES means, and it sounds reasonable that if a file is listed there, it should not be distributed. (Unfortunately, Automake cannot get this informations directly, but the consistency is checked by ``make distcheck''.) But please note that BUILT_SOURCES is a very special variable: listing a target there means that it will be built at the very begining of targets `all', `check', and `install', but that is all. It is just a hack which helps in situations where the target cannot be listed as a prerequisite to the terget which really needs it. Hope this makes this corner less dark, Stepan Kasal
Re: robustifying remove_distdir?
Hello,
On Fri, Jun 30, 2006 at 04:24:37PM -0400, David Fang wrote:
In reply to myself:
Is there a way of making the rm -rf more robust? Maybe with some sort
of while distdir exists, try removing loop?
...
- rm -fr $(distdir); }; }
+ { until rm -fr $(distdir); do :; done; }; }; }
well, it seems that this code can easily loop forever under certain
circumstances.
I'm not sure whether Automake should try to work around this problems
of the system. When you see the problem, try to find a methot which
can reproduce it, though not deterministically, and report that as a
bug of the system.
Have a nice day,
Stepan
Re: variable names and `include'
Hello, On Sat, Jun 24, 2006 at 02:24:09PM +0200, Tom Bachmann wrote: a way to do this but $(eval include bar.mk), Automake is not preprocessing the whole file, so there are easier ways to fool it: NULL = $(NULL)include hoo or include = include $(include) hoo Have a nice day, Stepan
Re: [AM-1.4] make distclean tries to build objects
Hello, What can one say about this? I don't get it. I'm afraid your mail does not contain enough information for any reasonable answer. Can the project be downloaded somewhere? Could you post gui/Makefile.am? Which version of Automake was used? Stepan
Re: Building a static library consisting of libraries
Hello, On Mon, Jun 12, 2006 at 08:59:07PM +0200, Norbert Sendetzky wrote: Let me first ask a question: Are .a libraries (libopendbx.a) static libraries or is that only dependent on the -static flag? *.a is always a static library, AFAIK. But that was not the point of Ralf's answer. Again, I'm repeating part of Ralf's answer, in case there awas a misunderstanding: if you start using libtool, it's best to use it for all libraries, including the static one. All libtool libraries have the same extension: *.la. So please drop the line: lib_LIBRARIES = libopendbx.a because the libtool library should contain both static and dynamic library inside. See the libtool manual for details. Have a nice day, Stepan
Re: [WISH] Local target in cross compialtion
Hello, On Thu, Jun 08, 2006 at 05:25:47PM +0200, Jérôme Pouiller wrote: One last question : In Makefile of linux kernel, HOSTCC is used to name compiler for the build platform, no? yes, when they say ``host program'', they mean ``binary for the system where the kernel build runs.'' The build/host/target terminology was developped for the situation when you cross-compile a cross-compiler, and then applied to all other Autoconf applications. Have a nice day, Stepan
Re: GNU Autoconf test version 2.59d available
Hello Paul and Ralves,
the change discussed here was triggered by problems with Solaris'
make.
I agree that the Automake manual could mention this bad scenario,
perhaps something like:
``Avoid files with names identical to shell builtins or basic
commands; during a VPATH build, Solaris' @command{make} would then
make unwanted replacements in the commands text, yielding very
puzzling results. For example, no check script should be named
@command{test}.''
OTOH, the recommendation in doc/install.texi could be perhaps more
grained. The problem is not that gmake is the only one working, the
problem is that Solaris' make is extremely evil. (Do I understand
correctly that BSD make is not rewriting the commands?)
The wording could be along this:
``The VPATH build should generally work with all make
implementations. Getting this right is tremendously tricky, though:
in particular, the misfeatures of Solaris' @command{make} cause
biggest troubles. On the other hand, the most reliable (and most
tested) is GNU make---try it if the VPATH build is not behaving
well.''
I apologize that I do not submit this in the form of a patch; I'm
sure these paragraphs will have to undergo some editorial work before
install, anyway.
Though I regret the confusion, I'm glad that Ralf pointed out the
problem.
Have a nice day,
Stepan Kasal
