Config files not removed by make clean
The documentation of Automake 1.7.2 says: Configuration requirements == [snip] `AC_CONFIG_FILES' `AC_OUTPUT' [snip] Other listed files are treated differently. Currently the only difference is that an Automake `Makefile'is removed by `make distclean', while other files are removed by `make clean'. However, make clean does not remove the files listed in AC_CONFIG_FILES. Indeed, in file /usr/share/automake-1.7/am/clean.am, I see: distclean-generic: -rm -f Makefile $(CONFIG_CLEAN_FILES) meaning that the files listed in AC_CONFIG_FILES are removed with make distclean, contrary to what is stated in the documentation. What am I missing here? -- Rafael
Patch to aclocal
Hi,
At our site we have a repository for experimental apps which are not as
fully tested as we would like, or not entirely compatible with the version
we have installed by default.
Unfortunately since we have a fairly old base system this means that
autoconf, automake, libtool et al have to live in this area.
I've built a script to set up the user's environment to include the latest
versions of the packages they want, it modifies CPATH, PATH,
LD_LIBRARY_PATH, MANPATH, INFOPATH and PKG_CONFIG_PATH to make sure
everything works. Unfortunately I couldn't find an env var to modify the
search path for aclocal, so I patched it myself to add the support I
wanted.
Here's the patch - I added 4 lines, 2 of which are comments, one of which
is entirely self-serving ;-). Can it be in 1.7.4?
diff -r -b -u -U 3 1.7.3/bin/aclocal 1.7.3-phil1/bin/aclocal
--- 1.7.3/bin/aclocal Thu Feb 20 19:55:32 2003
+++ 1.7.3-phil1/bin/aclocal Wed Mar 5 13:01:19 2003
@@ -26,6 +26,7 @@
# 02111-1307, USA.
# Written by Tom Tromey [EMAIL PROTECTED].
+# Slightly hacked on by Philip Willoughby [EMAIL PROTECTED].
BEGIN
{
@@ -218,6 +219,9 @@
close (DEFAULT_DIRLIST);
}
+# Allow the ACLOCALPATH environment variable to influence the search
paths
+push (@dirlist, split (/:/, $ENV{ACLOCALPATH}))
+ if defined ($ENV{ACLOCALPATH});
return @dirlist;
}
Ta for some great software,
Regards,
Philip Willoughby
Systems Programmer, Department of Computing, Imperial College, London, UK
--
echo [EMAIL PROTECTED] | tr bizndfohces pwgd9ociaku
Why reinvent the wheel? . . . . . . . . . Because we can make it rounder...
./Configure - make = configure again?!?
Hi guys, I have a very weird problem with my project. Perhaps you can help me! Everytime I run configure, then type make, there is a chance that doing this will run aclocal, autoconf and configure again!!! I realized this a while ago: I wrote some macros that I put in my aclocal.m4 file, and then, when doing a make, it would sometimes run configure and aclocal again and complain that my macros weren't there anymore (aclocal.m4 had been overwritten). I then realized I should put my macros in acinclude.m4, but still... I have no idea what triggers this. I remember reading in the documentation that Sometimes, make will run autoconf and aclocal again or something similar, but I don't want this to happen!!! Any ideas? Jean-Guillaume
Re: ./Configure - make = configure again?!?
Today, Jean-Guillaume Paradis (LMC) wrote: I have no idea what triggers this. I remember reading in the documentation that Sometimes, make will run autoconf and aclocal again or something similar, but I don't want this to happen!!! In my experience, autoconf et al will only be re-run if you have changed a Makefile.am or configure.[in|ac] file. Are you, perhaps, using an editor to view one of these files and then saving and exiting? This will of course update the timestamp on the file and cause make to think it's dependants are out of date. The answer in this case is, of course, to stop changing the file modify time. If you're on linux you probably have a command-line program called `stat' which can tell you everything you need to know about the file modify times. If you can find an instance where things are being re-run but haven't been changed that's an interesting bug, but probably not a bug in automake (I'd blame make itself). Regards, Philip Willoughby Systems Programmer, Department of Computing, Imperial College, London, UK -- echo [EMAIL PROTECTED] | tr bizndfohces pwgd9ociaku Why reinvent the wheel? . . . . . . . . . Because we can make it rounder...
Re: ./Configure - make = configure again?!?
Today, Jean-Guillaume Paradis (LMC) wrote: You see, we use CVS for our project ( http://sourceforge.net/projects/disec if you are interested ;) ). What we do is to include the configure.ac and Makefile.am files in our CVS tree, since this isn't a distribution, but the necessary things for developpers who want to change the Makefile.am files to include new programs etc etc. I think this is the cause of the problem, and this would't happen if we would only include the Makefile.in for example. So if I checkout (download) the entire project, a ./configure - make will run aclocal, automake again. I tried running autoconf, automake, configure, (putting everything up to date) and then commiting the changes to the CVS repository, but another checkout did the same problem. Aah it's all becoming clear. If you use `cvs checkout', the timestamps will be updated. You want to use `cvs update' for your day-to-day updating of your source tree... This should solve it - just get everyone else on your project to use update too or it won't help. Regards, Philip Willoughby Systems Programmer, Department of Computing, Imperial College, London, UK -- echo [EMAIL PROTECTED] | tr bizndfohces pwgd9ociaku Why reinvent the wheel? . . . . . . . . . Because we can make it rounder...
Re: ./Configure - make = configure again?!?
Aah it's all becoming clear. If you use `cvs checkout', the timestamps will be updated. You want to use `cvs update' for your day-to-day updating of your source tree... This should solve it - just get everyone else on your project to use update too or it won't help. Regards, Philip Willoughby Got that, problem solved. Thank you for your insightful and quick help sir, it is very appreciated! :) Jean-Guillaume
Re: Patch to aclocal
Philip Willoughby wrote: Today, Richard Dawe wrote: Unfortunately this is not portable to DOS. Oops - my bad. I should have tried it in MSYS I guess. I was modifying the installed code on linux rather than doing it properly... Would probably work in MSYS. You should try it in DJCPP environment. Earnie.
Re: Patch to aclocal
Hello.
Philip Willoughby wrote:
[snip]
or just
push (@dirlist, split (/@PATH_SEPARTOR@/, $ENV{ACLOCALPATH}));
OK.
Either way we'll need to add the `ACX_CHECK_PATHNAME_STYLE_DOS' macro to
configure.in and acinclude.m4
[snip]
Why? autoconf 2.50 and later set PATH_SEPARATOR already. automake CVS (1.7 and
HEAD) require autoconf 2.54.
I'm willing to test out your patch with automake DJGPP. Can you provide a
test case?
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
Re: Patch to aclocal
Philip == Philip Willoughby [EMAIL PROTECTED] writes: [...] Philip Unfortunately I couldn't find an env var to modify the Philip search path for aclocal There is an envvar called `ACLOCAL'. It is honored by `autoreconf' and the rebuild rules in `Makefile'. See also http://sources.redhat.com/ml/automake/2003-02/msg00112.html [...] -- Alexandre Duret-Lutz
Re: Config files not removed by make clean
Rafael == Rafael Laboissiere [EMAIL PROTECTED] writes: Rafael The documentation of Automake 1.7.2 says: Rafael Configuration requirements Rafael == Rafael [snip] Rafael `AC_CONFIG_FILES' Rafael `AC_OUTPUT' Rafael [snip] Rafael Other listed files are treated differently. Currently the only Rafael difference is that an Automake `Makefile'is removed by `make Rafael distclean', while other files are removed by `make clean'. Rafael However, make clean does not remove the files listed in Rafael AC_CONFIG_FILES. Thank you. The documentation is wrong. -- Alexandre Duret-Lutz
No dependencies in distribution
Is there a way to NOT have dependencies in the distributed Makefile.in file but still use dependency feature in the developer's build? I'm using automake 1.4p5.
Re: Patch to aclocal
Today, Alexandre Duret-Lutz wrote: Philip == Philip Willoughby [EMAIL PROTECTED] writes: [...] Philip Unfortunately I couldn't find an env var to modify the Philip search path for aclocal There is an envvar called `ACLOCAL'. It is honored by `autoreconf' and the rebuild rules in `Makefile'. See also http://sources.redhat.com/ml/automake/2003-02/msg00112.html I can't/won't use that for 2 reasons: * I expect (and my users expect) that running: make COMMANDNAME=string will set the path to the command that is the lower case of COMMANDNAME to string. This is for the very good reason that that's how every other command is reselected. See `man 5 environ' on a modern GNU/linux system. * I don't in general use autoreconf - I have my own script to run everything I need to run to regenerate my build system. I take your point about moving the functionality into autoconf being the right thing to do, but this doesn't solve my problem right now. (I haven't heard any mention of it on [EMAIL PROTECTED] BTW). In any case, the problem isn't going to go away, autoconf will also need some way of finding package-installed macros. OK, perhaps ACLOCALPATH isn't the right name for it in that eventuality, but it's got to exist and it's got to be called something... Regards, Philip Willoughby Systems Programmer, Department of Computing, Imperial College, London, UK -- echo [EMAIL PROTECTED] | tr bizndfohces pwgd9ociaku Why reinvent the wheel? . . . . . . . . . Because we can make it rounder...
Re: Patch to aclocal
I submitted a patch to handle this a while ago. Don't know what happened to it. H
Re: Patch to aclocal
Harlan Stenn schrieb: I submitted a patch to handle this a while ago. Don't know what happened to it. H well, I think something like this needed in many places around, it doesn't quite matter how it is called or how it works. If the current patch proposal works, along with path-separator on a $ACLOCALPATH, then it looks like a very good solution IYAM. -- cheers, guido
Re: Config files not removed by make clean
* Alexandre Duret-Lutz [EMAIL PROTECTED] [2003-03-05 21:15]: Rafael == Rafael Laboissiere [EMAIL PROTECTED] writes: Rafael The documentation of Automake 1.7.2 says: Rafael Configuration requirements Rafael == Rafael [snip] Rafael `AC_CONFIG_FILES' Rafael `AC_OUTPUT' Rafael [snip] Rafael Other listed files are treated differently. Currently the only Rafael difference is that an Automake `Makefile'is removed by `make Rafael distclean', while other files are removed by `make clean'. Rafael However, make clean does not remove the files listed in Rafael AC_CONFIG_FILES. Thank you. The documentation is wrong. Oh, too bad! I would prefer the reverse... -- Rafael
Re: $srcdir
But if I echo either $top_srcdir or $top_builddir, in the file tests/foo.test, they are both null, so I can't seem to find a way of referring to any files. AC_OUTPUT your test scripts using foo.in - foo rules, and include lines like: [EMAIL PROTECTED]@ in them. Either that, or AC_OUTPUT a vbls.conf.in - vbls.conf file which does this and source this file in from your scripts. H
Conditional copying
I'm trying to configure a program such that it will build properly, whether or not the building is done from the top of the source tree, or in a separate build directory. If a separate build directory is used, it is necessary to copy one directory from $top_srcdir/examples to $top_builddir/examples. How I can do the conditional copy? I tried this in Makefile.am if [ $top_builddir != $top_srcdir ] ; then cp -R $top_srcdir/examples $top_builddir/examples fi as well as something similar to that in the manual http://www.gnu.org/manual/automake-1.6.1/html_chapter/automake_9.html#SEC28 but both without any success. Automake and autoconf run okay, but the generated Makefile has an error in it. Instead of copying, using symbolic links would make more sense to save on disk space. How relieable are sybolic links? I was concerned that if the source directory is on one computer and the build directory on another, it may not be possible to create the links, although I think that will be okay. Any thoughts on how to solve the problem, or on linking vs copying? -- Dr. David Kirkby, Senior Research Fellow, Department of Medical Physics, University College London, 11-20 Capper St, London, WC1E 6JA. Tel: 020 7679 6408 Fax: 020 7679 6269 Internal telephone: ext 46408 e-mail [EMAIL PROTECTED]
Re: Conditional copying
David,
I'm trying to configure a program such that it will build properly,
whether or not the building is done from the top of the source tree,
or in a separate build directory. If a separate build directory is
used, it is necessary to copy one directory from $top_srcdir/examples
to $top_builddir/examples.
Usually I tell automake to pass ${srcdir}/file and don't bother copying.
for example,
tool_LDFLAGS = -Wl,--version-script=${srcdir}/file
How I can do the conditional copy? I tried this in Makefile.am
if [ $top_builddir != $top_srcdir ] ; then
cp -R $top_srcdir/examples $top_builddir/examples
fi
Makefile.am is not a shell script, but rather a Makefile.
Simon
--
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
pgp0.pgp
Description: PGP signature
Re: $srcdir
Hi, Harlan Stenn [EMAIL PROTECTED] writes: But if I echo either $top_srcdir or $top_builddir, in the file tests/foo.test, they are both null, so I can't seem to find a way of referring to any files. AC_OUTPUT your test scripts using foo.in - foo rules, and include lines like: [EMAIL PROTECTED]@ in them. Either that, or AC_OUTPUT a vbls.conf.in - vbls.conf file which does this and source this file in from your scripts. That's too heavy-handed for tests. The idiom for tests is to use TESTS_ENVIRONMENT = srcdir=$(srcdir) top_srcdir=$(top_srcdir) This is assuming the test scripts are listed in check_TESTS. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: $srcdir
Raja R Harinath wrote: That's too heavy-handed for tests. The idiom for tests is to use TESTS_ENVIRONMENT = srcdir=$(srcdir) top_srcdir=$(top_srcdir) This is assuming the test scripts are listed in check_TESTS. Thanks, that does indeed work okay. -- Dr. David Kirkby, Senior Research Fellow, Department of Medical Physics, University College London, 11-20 Capper St, London, WC1E 6JA. Tel: 020 7679 6408 Fax: 020 7679 6269 Internal telephone: ext 46408 e-mail [EMAIL PROTECTED]
Re: $srcdir
Clinton Roy wrote: Dr. David Kirkby [EMAIL PROTECTED] writes: $srcdir, which I assumed refereed to the directory 'src' below the top directory of a package, but seems to be undefined when I try to use it. Putting 'echo $srcdir' in a test script, just echoes a blank line, with no directory information. Just to confirm, you've added the script to the automake variable TESTS and are running the tests by invoking `make check' ? Yes, I was doing that. echo $srcdir in my scratch script setup like above does work, for what it's worth. #!/bin/sh echo source dir: $srcdir make check ... source dir: . PASS: foo.sh == All 1 tests passed == I would not work for me, but adding the TESTS_ENVIRONMENT = srcdir=$(srcdir) top_srcdir=$(top_srcdir) to Makefile.am did allow it to work. -- Dr. David Kirkby, Senior Research Fellow, Department of Medical Physics, University College London, 11-20 Capper St, London, WC1E 6JA. Tel: 020 7679 6408 Fax: 020 7679 6269 Internal telephone: ext 46408 e-mail [EMAIL PROTECTED]
$srcdir
I'm sorry I don't really know if this is an automake issue or an autoconf one, so please excuse the posting to both groups. I'm confused just how to best refer to files and in particular the use of $srcdir, which I assumed refereed to the directory 'src' below the top directory of a package, but seems to be undefined when I try to use it. Putting 'echo $srcdir' in a test script, just echoes a blank line, with no directory information. If I am right in assuming srcdir is supposed to refer to 'src' immediately below the top level directory, does that mean I can refer to the 'tests' directory immediately below the top level directory as $srcdir/.../tests ? Incedently, should the test scripts have '#!/bin/sh' on the first line? I'm have a package with a directory structure like this: ./examples ./src ./src/non_gui ./src/gui ./tests ./tools ./tools/src I'd like to run some tests (in the 'tests' directory) that uses a) A binary called src/non_gui/atlc b) The tests themselves in tests c) An example bitmap file, that I first create with one program and put into an exacmples directory, then test the bitmap file has the chechsum I expect. Test 1 below just does not work, since $srcdir is undefined in the test script. #test1.test #!/bin/sh $srcdir/non_gui/create_bmp $srcdir/../examples/test_stripline_coupler.bmp CKSUM=`../tools/src/mycksum ../examples/test_stripline_coupler.bmp` if [ $CKSUM = 48613 ]; then echo PASSED: $0 tests.log exit 0 else echo FAILED: $0 tests.log exit 1 fi Conversely 'test2.test' below does work, although I'm sure using paths in this way is not a great idea, easpecially if someone was building in a different directory to the sources. #test2.test #!/bin/sh # Compute a value 'Zo' using 'atlc' to analyse the bitmap # just created in test1. Zo=`../src/non_gui/atlc ../examples/test_stripline_coupler.bmp` if [ $Zo = 63.70 ] ; then echo PASSED: $0 tests.log exit 0 else echo FAILED: $0 tests.log exit 1 fi -- Dr. David Kirkby, Senior Research Fellow, Department of Medical Physics, University College London, 11-20 Capper St, London, WC1E 6JA. Tel: 020 7679 6408 Fax: 020 7679 6269 Internal telephone: ext 46408 e-mail [EMAIL PROTECTED]
Re: $srcdir
Today, Dr. David Kirkby wrote: I'm sorry I don't really know if this is an automake issue or an autoconf one, so please excuse the posting to both groups. I'm confused just how to best refer to files and in particular the use of $srcdir, which I assumed refereed to the directory 'src' below the top directory of a package, but seems to be undefined when I try to use it. Putting 'echo $srcdir' in a test script, just echoes a blank line, with no directory information. I think this is right - no doubt someone will correct me if not ;-). $srcdir refers to the directory containing the input Makefile the Makefile you're looking at it from was generated from. Let me try explaining that again If you have the following structure: . . . ./Makefile.in ./src/Makefile.in . . . and then you make a build dir and run configure in it you'll have: . . . ./Makefile ./src/Makefile ../Makefile.in ../src/Makefile.in . . . In which case at the top level $srcdir will be set to ../ and in the src dir it will be set to ../../src/ Of course, most people don't use separate build directories, and thus $srcdir is left empty - you don't need to see files in a separate directory in this case. Anyway, you probably want to use $top_srcdir, which is the root of the original package - thus if you need to refer to the src directory in the source area you should use $top_srcdir/src/. Think carefully though - if you want to refer to a built component you should use $top_builddir instead of $top_srcdir, or everyone who uses separate build directories as standard (in other words, me ;-)) will be very annoyed... Regards, Philip Willoughby Systems Programmer, Department of Computing, Imperial College, London, UK -- echo [EMAIL PROTECTED] | tr bizndfohces pwgd9ociaku Why reinvent the wheel? . . . . . . . . . Because we can make it rounder...
Re: $srcdir
Philip Willoughby wrote: $srcdir refers to the directory containing the input Makefile the Makefile you're looking at it from was generated from. Let me try explaining that again If you have the following structure: . ./Makefile.in ./src/Makefile.in . . . and then you make a build dir and run configure in it you'll have: . . . ./Makefile ./src/Makefile ../Makefile.in ../src/Makefile.in . . . In which case at the top level $srcdir will be set to ../ and in the src dir it will be set to ../../src/ Of course, most people don't use separate build directories, and thus $srcdir is left empty - you don't need to see files in a separate directory in this case. Anyway, you probably want to use $top_srcdir, which is the root of the original package - thus if you need to refer to the src directory in the source area you should use $top_srcdir/src/. Think carefully though - if you want to refer to a built component you should use $top_builddir instead of $top_srcdir, or everyone who uses separate build directories as standard (in other words, me ;-)) will be very annoyed... But if I echo either $top_srcdir or $top_builddir, in the file tests/foo.test, they are both null, so I can't seem to find a way of referring to any files. I've also tried building in /tmp, where there top directory is in /export/home/davek/atlc, but even then, when running 'make check', with a test that is supposed to echo $top_srcdir or $top_builddir, are both null, so naturally they don't function as intended if I try to use them. Is there anything that needs to be added to configure.in or Makefile.am in order that these are exported to the tests properly ?? I'm using autoconf 2.53 and automake 1.6.1 -- Dr. David Kirkby, Senior Research Fellow, Department of Medical Physics, University College London, 11-20 Capper St, London, WC1E 6JA. Tel: 020 7679 6408 Fax: 020 7679 6269 Internal telephone: ext 46408 e-mail [EMAIL PROTECTED]
