Re: Avoiding installation
Hello, On Sat, Sep 03, 2005 at 09:16:00AM -0400, John Kodis wrote: I'd like a program to be built when I type make, but not have it installed when I type make install. Is there a provision for this? [...] When this source file is compiled with $(CC) -o $@ -DMAIN $ will build a stand-alone test program. since this is a test program, you might want to use check_PROGRAMS. This way it would be build only on make check, not on make all. HTH, Stepan Kasal
'make' reruns configure ?!
Can anyone tell me why an Automake-generated Makefile would rerun the 'configure' script when 'make' is invoked, and whether there's a (possibly heavy-handed) way to disable this behavior? Thanks! Kendrick
Re: 'make' reruns configure ?!
Hello, On Mon, Sep 05, 2005 at 08:46:07AM -0500, Kendrick Smith wrote: Can anyone tell me why an Automake-generated Makefile would rerun the 'configure' script when 'make' is invoked, because it has regenerated 'configure' just before it and there is possibility that the new 'configure' might get different results than the previous one. And why was 'configure' regenerated? Because some of its source files, probably configure.ac or some of the *.m4 files, were modified. Perhaps they weren't modified, perhaps they just have screwed their time stamps. How did you unpack the source tree? and whether there's a (possibly heavy-handed) way to disable this behavior? Sure, just delete some part of the makefile, see the rule containing the string --recheck. I think deleting variable am__configure_deps might do it. Well, if you really modified some of the files, perhaps applied a patch against configure.ac (configure.in) or run aclocal, then it is correct to re-run configure. Just let the make do its work. If your copy of the source tree has wrong time stamps, then I'd recommend getting a correct copy. HTH, Stepan Kasal
Re: 'make' reruns configure ?!
Kendrick Smith wrote: Can anyone tell me why an Automake-generated Makefile would rerun the 'configure' script when 'make' is invoked, This would mean that the timestamps on the files indicate that you have modified a source file such as modifying a Makefile.am. Because the Makefile.am is newer than the Makefile the tools think it needs to be rebuilt. Downstream users unpacking a distribution tar.gz file should never need to run the autotools because the tar unpacking will set the timestamps properly. The timestamps will indicate that the project is up to date. The make program will not be triggered to run automake. One way for users to trip into this condition is to copy the unpacked directory without copying the timestamps. cp -r project-1.0 myproj-0.0 Because the cp did not preserve timestamps the result depends upon how fast your copy happened and things like that. Better to put the -a option there and preserve all attributes. cp -a project-1.0 myproj-0.0 Another way for users to trip into this condition is to check all files, even the generated ones, into a version control system and then do an update from it. If the VCS does not preserve timestamps then this can also indicate by the timestamps that the tools need to be run to bring things up to date. And of course there are other tools such as dpkg-source that do not preserve timestamps and can cause inadvertent timestamps skews. and whether there's a (possibly heavy-handed) way to disable this behavior? There is a whole section in the automake FAQ about the missing script and about the maintainer-mode option. Please read the documentation on it. (You may need to change the version if you have a different version of automake installed.) info automake-1.9 FAQ If you wanted a heavy-handed way of making sure that make thinks your timestamps are up to date then you can always make all files the same timestamp. This will make everything appear up to date. You can then make clean and make normally. find . -type f -print0 | xargs -r0 touch --reference . make clean make Bob
Re: 'make' reruns configure ?!
Hi Kendrick, * Kendrick Smith wrote on Mon, Sep 05, 2005 at 03:46:07PM CEST: Can anyone tell me why an Automake-generated Makefile would rerun the 'configure' script when 'make' is invoked, and whether there's a (possibly heavy-handed) way to disable this behavior? Usually, Automake-generated Makefiles contain rules to update config.status, Makefile itself, and even configure. A partial dependency tree is drawn in the documentation info Autoconf Making configure Scripts but additional dependencies may have been specified in configure.ac by the variables CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES. (In the end, I've sometimes had to resort to reading the output of make with various debug options added, to find out which file was out of date and caused a specific rebuild.) One way to disable these rules is to add AM_MAINTAINER_MODE to configure.ac and recreate everything. Then, the configure option --enable-maintainer-mode is necessary to re-enable these rules. Read info Automake maintainer-mode for more information about this topic. Cheers, Ralf
Portable prefix pattern rules
I am trying to find a portable way to replace this rule as given in AutoQt [1], which the autotools warn against using: SUFFIXES = .moc.cpp %.moc.cpp:%.h $(MOC) -o $@ $ The following doesn't seem to work: SUFFIXES = .moc.cpp .moc.cpp:.h $(MOC) -o $@ $ The only other alternative I see is to enumerate a rule containing the actual file names for every single .h to .moc.cpp conversion, of which there are hundreds. Cheers, Brian Mingus [1] http://autoqt.sourceforge.net/
Re: Portable prefix pattern rules
I hate to say it, but it is more than ugly. As a maintainer, when forced with the choice of leaving it as it is, which were it portable would be an elegant solution, or replacing it with hundreds of rules that I will have to maintain, I will leave it as it is. If the autotools were to recognize these pattern rules, scan the source and automatically generate portable rules for me, I would be a very happy customer indeed :) Brian On 05 Sep 2005 15:02:28 -0600, Tom Tromey [EMAIL PROTECTED] wrote: Brian == Brian [EMAIL PROTECTED] writes: Brian The following doesn't seem to work: Brian SUFFIXES = .moc.cpp I have never tried it but it is somewhat hard to imagine some versions of make accepting a suffix with two '.'s in it. Brian The only other alternative I see is to enumerate a rule Brian containing the actual file names for every single .h to Brian .moc.cpp conversion, of which there are hundreds. Yeah, this is ugly but it works. IMO, and this is most likely a controversial opinion, it would be reasonable for automake to have an option allowing it to generate (and recognize in Makefile.am http://Makefile.am) code specific to GNU make. Tom
Re: Portable prefix pattern rules
Brian == Brian [EMAIL PROTECTED] writes: Brian The following doesn't seem to work: Brian SUFFIXES = .moc.cpp I have never tried it but it is somewhat hard to imagine some versions of make accepting a suffix with two '.'s in it. Brian The only other alternative I see is to enumerate a rule Brian containing the actual file names for every single .h to Brian .moc.cpp conversion, of which there are hundreds. Yeah, this is ugly but it works. IMO, and this is most likely a controversial opinion, it would be reasonable for automake to have an option allowing it to generate (and recognize in Makefile.am) code specific to GNU make. Tom
Re: Portable prefix pattern rules
Brian == Brian [EMAIL PROTECTED] writes: Brian If the autotools were to recognize these pattern rules, scan Brian the source and automatically generate portable rules for me, I Brian would be a very happy customer indeed :) Sorry, I thought that was what we were talking about. In terms of just using it, yeah, this doesn't work atm. Having automake recognize GNU make-style '%' rules isn't totally out of the question, IMO. It might be tricky to make this totally reliable, I'm not sure. (E.g., if you considered something like extending the built-in dependency tracking code to support user rules...) Alternatively, code to directly support moc would also be fine. Tom
