Infinite recursion with `check_SCRIPTS = check'
Hello list, Due to a sudden lack of imagination, I wrote a testsuite named `check' and used it as a `check_SCRIPTS' which led to an infinite recursion of make (because the .PHONY check depends on check-am which does a `$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS)' so the make has no chance of catching the dependency cycle). Maybe automake should warn (or bail out) in such a case. I can write a patch for that, if you think that could be something relevant. I had a quick look at the source to try to see where that check could be inserted, and I ended up in am_install_var whose documentation surprised me because it did not correspond to the call site at handle_scripts. Maybe something along these lines would be better: diff --git a/automake.in b/automake.in index 3c47cc1..263674c 100755 --- a/automake.in +++ b/automake.in @@ -6826,8 +6826,10 @@ sub am_primary_prefixes ($$@) # Handle `where_HOW' variable magic. Does all lookups, generates # install code, and possibly generates code to define the primary -# variable. The first argument is the name of the .am file to munge, -# the second argument is the primary variable (e.g. HEADERS), and all +# variable. The first argument can be one of: '-noextra', '-candist', +# or '-defaultdist'. FIXME: Document these options. +# The following argument is the name of the .am file to munge, +# the following argument is the primary variable (e.g. HEADERS), and all # subsequent arguments are possible installation locations. # # Returns list of [$location, $value] pairs, where If I have some time next week, I'll try to port the parallel testsuite thing that Akim wrote because automake takes about an hour to distcheck on my Core2Duo 2Ghz, and I guess it would be much better with make -j2 distcheck. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part
Circular dependencies and test programs
Hi, I have two libraries liba and libb. I would like liba to call a function in libb but libb is linked with liba. So I have a circular dependency. Normally this is not a problem because the linker doesn't try to resolve dependencies when linking libraries. But here's the problem: liba uses libtool / automake and builds a number of test programs not just by configure but by liba's test suite and the linker *does* try to resolve depenencies in that case. Meaning, if I try to build an executable with liba it says it needs libb but libb needs liba. So what do I do? Is there a way to tell configure don't build executables? Mike
Forcing an AC_CHECK to fail
Hey, I have a package that uses AC and checks for a lib but the package also has it's own implementation of that lib. I have the said lib installed on the system but I want autoconf to fail that check and used the one provided in the package. So is there a way to tell a specific check to fail? Mike
Re: Circular dependencies and test programs
On Sat, 20 Oct 2007, Michael B Allen wrote: I have two libraries liba and libb. I would like liba to call a function in libb but libb is linked with liba. So I have a circular dependency. Normally this is not a problem because the linker doesn't try to resolve dependencies when linking libraries. My best advice is to change the design of your libraries to avoid the circular dependencies. On some platforms the linker must resolve all dependencies when linking libraries. Circular dependencies are sure-fire headache in otherwise portable software. In some cases a link can succeed by listing dependency libraries several times. Even once you fix the circular dependency issue, you will still need to worry about library build order since Automake will need to build and install libraries in the correct order. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Circular dependencies and test programs
Nuts. On 10/20/07, Bob Friesenhahn [EMAIL PROTECTED] wrote: My best advice is to change the design of your libraries to avoid the circular dependencies.
Re: Forcing an AC_CHECK to fail
Michael B Allen [EMAIL PROTECTED] writes: So is there a way to tell a specific check to fail? You can preset the cache variable before running configure. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Forcing an AC_CHECK to fail
On 10/20/07, Andreas Schwab [EMAIL PROTECTED] wrote: So is there a way to tell a specific check to fail? You can preset the cache variable before running configure. Excellent! So how to do I preset a cache variable before running configure? Mike
Re: Forcing an AC_CHECK to fail
Michael B Allen [EMAIL PROTECTED] writes: So how to do I preset a cache variable before running configure? You can put it in the environment, or use config.site. See (autoconf)Site Defaults. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Circular dependencies and test programs
Michael B Allen [EMAIL PROTECTED] writes: But here's the problem: liba uses libtool / automake and builds a number of test programs not just by configure but by liba's test suite and the linker *does* try to resolve depenencies in that case. Meaning, if I try to build an executable with liba it says it needs libb but libb needs liba. So what do I do? Is there a way to tell configure don't build executables? If the test programs are listed on check_PROGRAMS, instead of on some other target, then they will be built only for make check, not for make all or make install. -- Ben Pfaff http://benpfaff.org
Re: Forcing an AC_CHECK to fail
On 10/20/07, Andreas Schwab [EMAIL PROTECTED] wrote: Michael B Allen [EMAIL PROTECTED] writes: So how to do I preset a cache variable before running configure? You can put it in the environment, or use config.site. See (autoconf)Site Defaults. Hey Andreas, Ok. I see the docs you're talking about. Still not crystal clear what exactly I would put in the site config (AC_CACHE_VALUE I suppose). But it doesn't matter. The test in question is custom so I just sabotaged it to fail. Not an elegant solution but it works. Thanks, Mike
Re: Circular dependencies and test programs
On 10/20/07, Ben Pfaff [EMAIL PROTECTED] wrote: Michael B Allen [EMAIL PROTECTED] writes: But here's the problem: liba uses libtool / automake and builds a number of test programs not just by configure but by liba's test suite and the linker *does* try to resolve depenencies in that case. Meaning, if I try to build an executable with liba it says it needs libb but libb needs liba. So what do I do? Is there a way to tell configure don't build executables? If the test programs are listed on check_PROGRAMS, instead of on some other target, then they will be built only for make check, not for make all or make install. Hi Ben, Well that's interesting because indeed they are list on check_PROGRAMS. However, I have decided that Bob's solution is the right thing to do. It so happens that the specific code from libb needed by liba does not need liba. So by breaking up libb into a few smaller libraries I can eliminate the circular dependency and greatly reduce the number of libraries I need to link liba with. Thanks, Mike PS: I like your Linux Thinkpad page on the T30. It was very helpful.
