Re: Generating missing depfiles by an automake based makefile
I finally went back to the top of the thread. Dmitry> Here is a rule from an automake generated makefile. Dmitry> Below is a sample bash session with gnu make which demonstrates how a Dmitry> dummy shuffle.Po makefile fails to have shuffle.o rebuilt when Dmitry> shuffle.h changes. Dmitry> $ rm src/.deps/shuffle.Po Just don't do this. Maybe it's possible in theory to deal with this scenario, but it seems to me that it's not worth putting much effort into it. Tom
Re: Generating missing depfiles by an automake based makefile
Dmitry> i am not looking forward to -include (even though -include is Dmitry> supported by bmake, gnu make and sun make). Dmitry> -include robs the user the error message should make fails to rebuild a depfile. Dmitry> i'd rather introduce rules to rebuild depfiles, as presented in the Dmitry> earlier email. It's been a long time since I worked on automake, but the dependency tracking in automake is designed not to need to rebuild or pre-build dep files. Doing that means invoking the compiler twice, which is slow. Instead, automake computes dependencies as a side effect of compilation. What is the scenario where you both end up with an empty depfile and a compilation that isn't out of date for some other reason? That seems like it shouldn't be possible. Tom
Re: Future plans for Autotools
> "Gavin" == Gavin Smith writes: Gavin> I remember somebody was Gavin> complaining about this page: Gavin> https://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html Gavin> and asking what "maude" meant - it turned out it was the name of the Gavin> dog or something of the person who first wrote the program, who didn't Gavin> want it to change. Yeah, that was my dog's name. Feel free to change it if you think that's important. I don't recall objecting, but I wouldn't put it past me. Tom
Re: Installing something nonstandard in $(libdir)
> "Zack" == Zack Weinberg writes: Zack> Makefile.am:158: error: 'libfoo$(SOEXT).1' is not a standard library name Zack> Makefile.am:158: did you mean 'libfoo$(SOEXT).a'? Zack> and lib_DATA is the obvious alternative but that doesn't work either: Zack> Makefile.am:145: error: 'libdir' is not a legitimate directory for 'DATA' Zack> So, the question is, is there a lib_SOMETHING variable that I can use Zack> to install to $(libdir) arbitrary stuff that automake doesn't Zack> understand? If not, is there some other option? I believe you can work around the checks by providing your own install directory variable, like: myexeclibdir = $(libdir) myexeclib_DATA = ... The "exec" is in the name to ensure that "make install-exec" installs these files, see (info "(automake) The Two Parts of Install") for this detail. Tom
Re: AC_ARG_ENABLE and checking for unrecognized switches
> "Bob" == Bob Friesenhahn writes: Bob> A project can be made subordinate to another project without the Bob> author of the subordinate project being aware of it. This is a very Bob> useful capability. This capability is used by projects such as GCC. Yeah, but the outer configure script could easily pass --disable-option-checking. Maybe it already does. So, if the default is to suppress checking (as was reported), then that seems backward. More generally it would be nice if the outer configure would do some kind of global checking, and if --help reflected the actual state of what is available. This stuff comes up all the time for gdb, which does subdir configures like this: users either typo an option or are confused because --help doesn't mention the option we ask them to pass. Tom
Re: AC_ARG_ENABLE and checking for unrecognized switches
>> I use AC_ARG_ENABLE to create a number of different --enable switches. >> I noticed when I accidentally mistyped the in --enable- >> , ./configure didn't bail on the unrecognized switch. Eric> This is by design; the GNU Coding Standards wants projects to be Eric> aggregatable, such that someone else could write a larger project that Eric> uses yours as a subdirectory, and takes additional --enable switches Eric> that some (but not all) of its subprojects understand. Being able to Eric> blindly pass down all of its switches to subprojects, without having to Eric> worry about which projects care about which switches, makes this easier. I think there are a few wrinkles: https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Option-Checking.html My reading is that there *is* checking by default, but it is turned off if you have a subdir configure, but then can be turned back on again by the user. Doing something better here would be nice (though maybe difficult) since in my experience I often forget the exact spelling... like, is it "--disable-multilib" or "--disable-multilibs"? Or is it "--with-python" or "--enable-python"? Tom
Re: Make autoconf and automake generate compile_commands.json for integration with other build systems and IDEs
>> The list of source files and resulting object files isn't known until >> `make` is launched. It seems to me that Automake knows more about the build than a generic system would, and could implement this. Well, at least it could in most cases, for example those where all the sources are visible in the Makefile.am. FWIW this is the second time in the last week or so that I've heard this request. It seems like a reasonable thing to attempt. Tom
Re: manual: Why use 'maude' as the example program name?
> "Bob" == Bob Friesenhahn writes: Bob> I think that we should have respect for the author's Bob> dog. Disrespecting the author's dog is not far from disrespecting the Bob> author. Haha, well my memory of my dog is why I'd rather keep the text. It's fine to disrespect me, but not Maude -- she was great & hilarious :-) Tom
Re: manual: Why use 'maude' as the example program name?
> "Jonas" == Jonas Thiem writes: Jonas> Disclaimer: I haven't read this part of the docs myself. But for what Jonas> it's worth, I think Maude looks a bit like a misspelling of Make and Jonas> doesn't stick out that well, compared to "exampleprog" or something. One such section starts: In the list below, we use the name “maude” to refer to the program or library. In your ‘Makefile.am’ you would replace this with the canonical name of your program. This list also refers to “maude” as a program, but in general the same rules apply for both static and dynamic libraries; the documentation below notes situations where programs and libraries differ. I guess my view is that in all the years of Automake, if we're first hearing about it now, then it probably isn't really that confusing. Also AFAICT it isn't mentioned on stack overflow. Tom
Re: manual: Why use 'maude' as the example program name?
> "Kang-Che" == Kang-Che Sung writes: Kang-Che> And I really wonder one thing: Why these obscure name had been Kang-Che> chosen, instead of having a name like "myprog", "foo" or Kang-Che> "fooprog" that is more obvious as a placeholder? It's easily distinguished from any ordinary text and I have a dislike of "foo" as an example. Also Maude was the name of my dog. Kang-Che> This had troubled me when I need to look up the meanings of Kang-Che> Automake variables frequently in order to write a debug an Kang-Che> Automake file. And I hope the keywords can be indexed in a Kang-Che> better way. IMO the index should refer to definitions of primaries but not the names used in examples. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
> "Stefano" == Stefano Lattarini writes: Stefano> On a second though, by double-checking the existing code, I Stefano> couldn't see how the 'cygnus' option could possibly influence Stefano> the location of the generated info files -- and it turned out Stefano> it didn't! Despite what was documented in the manual, the Stefano> 'cygnus' option did *not* cause the generated '.info' files to Stefano> be placed in the builddir (see attached test case). It certainly does for me: barimba. pwd /home/tromey/gnu/baseline-gdb/build/binutils barimba. grep '^srcdir = ' Makefile srcdir = ../../src/binutils barimba. find . -name 'binutils.info' ./doc/binutils.info barimba. find ../../src/binutils -name 'binutils.info' barimba. How did you test it? If you built from a distribution tar, then it is expected that the info file would be in srcdir. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
> "Stefano" == Stefano Lattarini writes: Stefano> It should still be possible, with the right hack (which is Stefano> tested in the testsuite, and required by other packages Stefano> anyway). The baseline is: if you don't want your '.info' files Stefano> to be distributed, then it should be easily possible to have Stefano> them built in the builddir; but if you want them distributed, Stefano> they will be built in the srcdir. Now I am confused. Is it possible to continue to work the way it does today, or not? If so, then great. If not, then we need some other plan. Tom> But, I see that, according to the Automake manual, I am wrong about that. Stefano> Weird, I didn't expect that hack to be documented in the Stefano> manual... And in fact I cannot find it. Could you please Stefano> point me to it? Thanks. http://www.gnu.org/software/automake/manual/automake.html#Cygnus "Info files are always created in the build directory, and not in the source directory. Packages that don't use the cygnus option can emulate this effect by using the no-installinfo option and listing the generated info files in the CLEANFILES variable. " Re-reading the suggestion here, I can't understand how it would work. Anyway the real use in the src tree is different, IIUC. Info files are built in the build tree by developers, but put in the source tree for distribution. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
> "Stefano" == Stefano Lattarini writes: Stefano> Sorry if I sound dense, but what exactly is the feature you are Stefano> talking about here? I was under the impression that it would no longer be possible to build info files in the build tree. But, I see that, according to the Automake manual, I am wrong about that. So, sorry for the noise. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
> "Stefano" == Stefano Lattarini writes: Stefano> True, and that was even stated in the manual; the whole point Stefano> of ditching support for cygnus trees is that by now those two Stefano> big users are basically not making any real use of the 'cygnus' Stefano> option anymore. To quote my previous report: Stefano> ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus Stefano> ./bfd/doc/Makefile.in:# cygnus option. Stefano> ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus Stefano> ./bfd/doc/Makefile.am:# cygnus option. But this is a reason not to remove it; or at least to restore the previous handling of info files. I don't care about the cygnus option per se. It was always a grab bag of hacks. The issue is removing a feature that an important user relies on. So far the suggested replacements haven't seemed that good to me. Tom
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
> "Stefano" == Stefano Lattarini writes: Stefano> Note there's nothing I'm planning to do, nor I should do, in Stefano> this regard: the two setups described above are both already Stefano> supported by the current automake implementation (but the last Stefano> one is not encouraged, even though it makes perfect sense in Stefano> some *rare* situations). I was just pointing out that you have Stefano> to choose one of these setups -- so, if you want to distribute Stefano> info files, you must accept to have them build in the srcdir. Or we can just stick with an older version of automake. It seems to me that this is the sensible approach. Or move to some other build system; either autogen-based or just requiring GNU make features. The latter is fine for GCC but I'm not sure whether all the src projects are on board. I'm pretty disappointed that automake would make this change. I realize these choices may (arguably) make the most sense for most projects, but the gcc and src trees are not like most projects; and really the whole 'cygnus' feature is there just to support these two big users. Tom
Re: GNU make or portable make?
> "Ralf" == Ralf Wildenhues writes: Ralf> If Automake were only started now, I think requiring GNU make Ralf> would be a prudent design decision. Yeah. Portability looked a lot more important back then. Nowadays I think assuming GNU make is completely reasonable. You can probably even dig up cases where the configury for a project is bigger than GNU make itself... you could shrink some programs by shipping the build tool :-) Ralf> Still, as things stand, I'm not sure whether changing design goals of Ralf> Automake now are such a good idea. BSD developers really like using Ralf> their own make. The code we have works, build system overhead is really Ralf> bad only on w32. We have opportunities for improvement by assuming Ralf> Posix and XSI shell in more places, guarded by suitable tests. As long Ralf> as the build system parallelizes well, I don't think there is too much Ralf> cause for concern. The "make" part of the build parallelizes well, but the configure part does not. I think that is the big problem today. It is particularly noticeable in big trees like gcc or gdb. GNU make could help solve this. See quagmire for a random stab at this idea. It isn't the most pleasant programming environment, but then neither is the m4+shell combination ;-). I'm sure there are other workable approaches as well. Tom
Re: GNU Make Extensions
> "Bob" == Bob Friesenhahn writes: Bob> You have got it exactly. Automake is not the only solution. There Bob> are other solutions out there which require GNU make and are likely to Bob> be more automatic as you prefer. One of those solutions (I forget the Bob> name) is invented by the original Automake author. "Quagmire": http://code.google.com/p/quagmire/ Tom
Project Quagmire
I recently started work on a new automake-like project, called Quagmire. I thought folks interested in Automake would also be interested in this; I hope no one is offended that I am posting this here. For years I've been interested in a few twists on the auto* idea: * Integrate configury into the build. This has some nice benefits, most notably that checking can be on-demand and parallelized. * A minimized, "low-expectation" libtool-like thing integrated into the Makefiles. * An automake-workalike that uses GNU Make features rather than a preprocessor. This is what Quagmire aims to accomplish. Currently it has functionality equivalent to (and in many cases, taken directly from :-) parts of Automake -- it supports the most common things (C, C++, etc). It also has some rudimentary support for a few configure-like operations (though it still does, and always will, require at least a minimal autoconf-produced configure). The syntax is about as close to Automake's as possible -- primaries, directory prefixes, etc. (FWIW I never considered the syntax among Automake's problems -- I still think it is very reasonable.) Of course, Quagmire is not for everybody. GNU make is an absolute requirement -- in fact, Quagmire currently requires 3.81, the latest release. But, if you don't mind this dependency, you might consider Quagmire. Here's the hosting location: http://code.google.com/p/quagmire/ And the mailing list: http://groups.google.com/group/quagmire-discuss If you are interested in discussing Quagmire, its direction, its pointlessness, whatever -- I would suggest moving to the Quagmire list so as not to disturb this list too much. thanks, Tom
Re: Yacc Support?
> ">" == kj1nabble <[EMAIL PROTECTED]> writes: >> Any thoughts? I think it has something to do with how I set up my bin in >> Makefile.am. You don't say how it failed... >> bin_PROGRAMS = app >> lc_SOURCES = l.l app.c g.y appgen.c You either want to have 'bin_PROGRAMS = lc', or you want to name your program 'app' and have 'app_SOURCES'. Tom
Re: meaning of @variablename@
> "Arun" == Arun Jain <[EMAIL PROTECTED]> writes: Arun> I am new to this utility (automake). I am working on Linux Arun> platform with KDE libraries. I came across some variable names Arun> in the makefile such as For answers to this and other questions, read the Autoconf manual. In particular read the node "Substitutions in Makefiles". Tom
Re: Non-recursive makefiles
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> An aspect, I don't see how an import feature would help is Ralf> "scoping": A subdir-Makefile.am controls one subdir, a flat Ralf> toplevel Makefile controls all subdirs. I.e. when developing on Ralf> a package, with a non-flat Makefile structure, e.g. a "make Ralf> clean" inside of a subdir cleans this single subdir. With a flat Ralf> Makefile the whole source tree will be "cleaned". FWIW the original 'import' plan included support for scoping of the automake-generated rules, e.g. 'make subdir/clean'. Ralf> Yet another aspect is size/speed of files generated from Ralf> flat-Makefile.am. Processing all-flat Makefile.am of a source tree Ralf> containing 100s of source-files can be annoyingly slow and easily reach Ralf> the order of several minutes, even on contemporary HW. Ralf> I don't see how an "import feature" would help. The hope was that a single Makefile would improve performance by eliminating multiple 'make' invocations, and by allowing better parallelism across the entire project -- right now parallelism is limited to a single directory. We didn't really consider make scalability back when thinking about this. Oops. But, perhaps whatever problems there are in make are solvable there. In any case the import plan looked pretty complicated to implement. And, it would have required user support in some cases. As you noted, you can't go around rewriting make rules arbitrarily; we were thinking of adding a new '%subdir' automake-time substitution, or something like that, to let people write relocatable rules. Tom
Re: Built sources always regenerated
> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
Braden> Forget about BUILT_SOURCES and *_DEPENDENCIES. The sources I'm building
Braden> get #include'd by browser.cpp. As such, checking of browser.cpp's
Braden> dependencies should cause them to get (re)generated, right?
Braden> But it doesn't. If I remove BUILT_SOURCES, the files don't get
Braden> generated before browser.cpp gets compiled. Why not?
Automake dependency tracking information is computed as a side effect
of compilation. So, the first time things are compiled, it has no way
of knowing about dependencies on generated files.
BUILT_SOURCES is a hack to get around this. It basically inserts a
'make $(BUILT_SOURCES)' before targets like 'all'. (It would be nice
to have per-{executable,library} BUILT_SOURCES...)
I didn't look into this too deeply but I would guess that it is more
make-related than automake-related. You can add rules to the
Makefile.am to help with debugging, eg:
hack:
$(MAKE) $(BUILT_SOURCES)
Then in theory 'make hack' should reproduce the problem you're seeing.
If that doesn't happen then something weird and perhaps
automake-related is going on. If it does happen, you can try plain
old Makefile debugging with 'make -d'.
Tom
Re: what happens to EXTRA_DIST during distcheck?
> "Ed" == Ed Hartnett <[EMAIL PROTECTED]> writes: Ed> In my top level makefile I have an EXTRA_DIST: Ed> # These files get added to the distribution. Ed> EXTRA_DIST = README COPYRIGHT RELEASE_NOTES Ed> But looking at the _build directory created during make distcheck, I Ed> do not see any of these files: They don't get copied to the build directory. They are put in the final .tar.gz that is the distributable result. Tom
Re: compile not copied? Why?
> "Harald" == Harald Dunkel <[EMAIL PROTECTED]> writes: Harald> What is the criteria for copying the compile script into Harald> the source directory tree? I have some *.cc code, it is Harald> mentioned in my Makefile.am file, configure detects that Harald> the compile script must be used, too, but Automake doesn't Harald> provide it. Did you try 'automake -a'? Tom
Re: why does make install depend upon all?
> "Harald" == Harald Dunkel <[EMAIL PROTECTED]> writes: Harald> Please see subject. Of course I would agree that this Harald> dependency is usually a good thing, but sometimes it might Harald> be helpfull to do a 'make install' for another prefix e.g. Harald> in your stow directory without verifying all the dependencies Harald> again. This is traditional; there is no hard requirement for it in the spec, it is just the "way things were done", at least in the GNU world as I understood it back then. 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
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: non-recursive automake advice?
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: Bob> Note that the messages appear to indicate that Automake does recurse Bob> once regardless. Some features require a $(MAKE) invocation in the same directory. Offhand I forget what. As I recall, removing this would be tricky. Tom
Re: non-recursive automake advice?
> "tom" == tom fogal <[EMAIL PROTECTED]> writes: tom> Basically I'd like each module to build their own libtool convenience tom> library, and then have /src/Makefile.am link all of those modules' tom> convenience libraries into one that is the union of all of them. Do you really want each separate convenience library, or is that just inertia? I ask because if you don't want separate ones, the task becomes even simpler. tom> Without recursive make this is a little strange, but I've devised a tom> scheme to make each module 'feel' like it has its own, local tom> Makefile.am, by playing with includes. tom> libAll_la_LIBADD = \ tom> $(srcdir)/models/libModels.la \ tom> $(srcdir)/share/libShare.la \ tom> $(srcdir)/input/libInput.la \ tom> $(srcdir)/libCur.la You don't want $(srcdir) here. The .la files are in the build tree, not the source tree. Just write: libAll_la_LIBADD = \ models/libModels.la \ share/libShare.la \ input/libInput.la \ libCur.la tom> Unfortunately in the 'Inc.am' files I need to remember to qualify every tom> filename with not just '$(srcdir)', but tom> '$(srcdir)/modules_directory_name/'. This is only a minor annoyance tom> and definitely worth the trouble, but perhaps I am missing something? Once upon a time I had a plan to introduce a new 'import' statement, that would work like 'include' but magically rewrite things like this as needed. That would make it really simple to do the kind of thing you're trying to do. It was fairly complex, though, and in the end I lost interest... tom> noinst_LTLIBRARIES += $(srcdir)/models/libModels.la (Likewise no srcdir here) Tom
Re: AM_CPPFLAGS not applied for CHECK programs?
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: Bob> As a follow-up to this posting, I see that when Automake generates a Bob> specific rule for a target built in a subdirectory, it forgets to Bob> include $(AM_CPPFLAGS). This is a serious error. This is documented in the 'Program and Library Variables' node: In compilations with per-target flags, the ordinary `AM_' form of the flags variable is _not_ automatically included in the compilation (however, the user form of the variable _is_ included). So for instance, if you want the hypothetical `maude' compilations to also use the value of `AM_CFLAGS', you would need to write: maude_CFLAGS = ... your flags ... $(AM_CFLAGS) As I recall we made this choice so that people could set a global default and then override it for specific programs. Tom
Re: Support for precompiled C++ headers
> "Roberto" == Roberto Bagnara <[EMAIL PROTECTED]> writes: Roberto> Can anyone point me to a C++ project that is working with Roberto> precompiled headers and that is doing it with the currently Roberto> available versions of automake and autoconf? >From the gcjx project on sourceforge: BUILT_SOURCES = [...] typedefs.hh.gch headers = [...] ## FIXME: need a better way to convince libtool to let us do this. typedefs.hh.gch: $(headers) -rm -f typedefs.hh.gch $(CXXCOMPILE) -fPIC -DPIC -x c++-header -o typedefs.hh.gch $(srcdir)/typedefs.hh As you can see I had to hack around libtool. I didn't try a more direct approach, perhaps it would have worked. Also, I always build this project with --disable-static. Tom
Re: FEATURE REQUEST: Uninstall script should be created by AutoMake.
> "Hans" == Hans Deragon <[EMAIL PROTECTED]> writes: Hans>Automake should create a script that simply contains all the "rm" Hans>commands and have it installed with the other binaries. You could write a program to do this, if you wanted to experiment with it. You would run `make -n uninstall' and set the variables NORMAL_UNINSTALL, PRE_UNINSTALL, and POST_UNINSTALL to magic strings so that you can determine command boundaries. This would work for a lot of packages, but not all of them, since most custom uninstall targets (if they exist, an already doubtful proposition) probably don't use these correctly. See the GNU Coding Standards for more info. Tom
Re: pathnames containing spaces
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: Russ> make uses a space as a separator, and getting it to accept spaces in file Russ> names is extremely difficult or impossible depending on the version of Russ> make that you're using. Yeah, and the problem is made worse because quoting for make isn't the same as quoting for the shell. You have to double quote things, sometimes in creative ways -- and automake likes to re-use user input, so in some situations doing this is probably just impossible. The problems aren't just with spaces, dollar signs and colons also cause fits. Tom
Re: release schedule for 1.9? (Was: Re: automake -vs- huge projects (1st patch))
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> Also, since we have switched to API-numbering, bumping that adl> version number has a cost. For instance Debian distributes adl> automake1.4, automake1.6, automake1.7, and automake1.8. If we adl> add another API, it'd better be worth it. Yeah. It turns out that Red Hat still ships 1.5 because some packages still depend on it. Sigh. Obviously this doesn't scale -- at some point it has to be so painless to upgrade that someone like Debian or Red Hat can simply ditch 1.x and convert everything to 1.x+1 all at once. adl> Maybe we could release an "official snapshot" of HEAD? This may adl> also help to better test these uncertain subdir-suffix-rules. adl> Would that be enough? It might. Unfortunately I don't think we can unilaterally make a decision like this. We'll have to involve the other gcc maintainers. I think the ideal for gcc is to have the entire tree requiring a single released version of automake. But, we'll never know if we can do it until we try :-) Tom
Re: utility programs used during build
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: >> > If you want a clean way, you'd have to split buildtools and >> > host-packages into separate (sub) packages and write a costomized >> > toplevel configure-script to parse and set the configure options for >> > build- and host- compile packages. Ralf> This is the current nominal working principle, as it is applied by Ralf> packages which actually support cross-compilation (gcc, newlib, Ralf> binutils, gdb etc.). Hmm, I think we're mixing scenarios. In gcc, for instance, ordinarily target libraries are put in their own directories with their own configuration. And there is also a surrounding layer of hackery to deal with multilibs. But that isn't what Warren is talking about. He's talking about a situation where you want to build your package for a different host, but first build some helper programs on the build machine to create other parts of your program. E.g., in gcc there are the gen* family of programs, like genattrtab. These are just incorporated in the gcc source directory along with files that will be compiled for the host machine, not the build machine. My opinion on this is that total separation is easier to implement, but not really cleaner. "Clean" depends on the needs of the package at hand, sometimes you'd really rather just lump all the sources together. Alexandre's simple solution of overriding _CC and the like is nice. I think at least one part of this must be handled automatically, and that is the selection of EXEEXT, which can differ between build and host. And really my preference would be to have it all done automatically, since that is easier for the user and less error-prone... still, it looks like the same internal mechanisms are necessary to support build compilers and per-target compilers. Anyway, it looks like there's a big job ahead for Warren :-). Tom
Re: make distcheck problem
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes: Lars> if BUILD_SRC_BEOS_SUBDIR Lars> d_beos = beos Lars> endif Lars> SUBDIRS = $(d_beos) Lars> If I run make distcheck in the top level directory, it bombs out at Lars> one point because the beos subdir doesn't exist. Is this a bug in Lars> automake? Is there any way to work around it? I am not running on Use `DIST_SUBDIRS'. Tom
Re: utility programs used during build
> "Warren" == Warren Turkal <[EMAIL PROTECTED]> writes: Warren> Is there any analysis on what it would take to create utility Warren> programs that are only used during build in a crosscompiled Warren> environment in automake? Warren> I and working on the libX11 for Freedesktop.org and it builds Warren> a file and uses it during installation, but does not install Warren> it. I am under the impression that automake does not support Warren> this right now. What would be needed to add support for this Warren> feature. I think your plan as posted on the patch list is a good start. I always liked the gcc-style names like `CC_FOR_BUILD', `CFLAGS_FOR_BUILD'; they always seemed the easiest to understand. (Other folks have suggested BUILD_CC, BUILD_CFLAGS, etc. Which, really, aren't that much harder.) Having a `build_' prefix for primaries makes sense to me. For autoconf it would be nice if you could tell it "now I want to do checks on the host compiler" and have it change the definition of CC (and other flags), have a new build-specific config.h, etc. The required changes might be extensive. I agree with Alexandre that we don't have to support target, just host and build. Well, really it might be nice to clean up target library support, but I wouldn't recommend it unless you have a real need; it is pretty messy. Tom
Re: automake -vs- huge projects
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes: Paul> If you're willing to require GNU make then I'm quite confidant Paul> you could write automake as nothing more than a suite of GNU Paul> make macros and functions. Yeah. One idea for the post-auto* world is "let's beef up GNU make and use it as the basis for the next-generation system". This approach has the benefits that most build scripts are already written for make and that GNU make already does a lot of what is needed. The competing idea (which seems to have more mindshare -- not necessarily making it more viable) is to write something brand new, typically in your-favorite-scripting-language, thus avoiding the less pleasant aspects of make (syntax, primarily, but also the flat namespace). From time to time I work on a tool following this approach, but there are several of these out there. We did consider just writing our own Makefile.in for libgcj using GNU make features. It seemed easier to try to fix the size problem though. Tom
Re: Principles of a developing from a dist or install?
> "John" == jling <[EMAIL PROTECTED]> writes: John> Is there any sense in me having the user install the package (i.e. do John> a 'make install') and then have them develop off of the code in the John> install directory? ... assuming I have the source code and headers John> copied over during the install process. I can't say whether or not it makes sense. It isn't the standard thing, though, that's for sure. The typical approach is that "make install" simply installs the output of the build process, the idea being that the user can save some space by then deleting the source and build trees, if he so desires. Users who wish to hack on the package usually use the unpacked tree, both because it is already built (and therefore a simple change might involve less recompilation) and because it means these users and the maintainers will have a similar build structure and directory layout (so patches will apply more easily). John> Nevertheless what is the best way or ideal way to proceed? The general idea is to have one single structure used by everybody. This means less testing, less trouble applying patches, etc. People can generally navigate any sensible source layout, no matter how deep; I wouldn't normally consider that a big hurdle. Tom
Re: automake -vs- huge projects
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: >> $(CC) -c -o $@ `$(CYGPATH_W) $<` Bob> An simple (but ugly) approach would be to define $(CYGPATH_W) to Bob> 'echo' when not compiling under Cygwin. We already have much worse hacks. But ideally we'd be reducing the amount of weird code we generate, trying to streamline compilations as much as possible (hence the fast-dep stuff). Bob> It seems to me that perhaps 'CYGPATH_W' is misnamed or the use is Bob> outdated. It's entirely possible. This use probably dates to the original Cygwin port of automake and most likely has been carried forward without examination or modification since then. Tom
Re: .cpp to .c
> "Bob" == Bob Lockie <[EMAIL PROTECTED]> writes: Bob> I have: Bob> arson_SOURCES = arson.cpp Bob> in Makefile.am Bob> and this is changed in Makefile.in Bob> arson_SOURCES = arson.c Bob> Any idea why my .cpp is changed to .c? No, that shouldn't happen. Do you have a small test case? Tom
Re: automake -vs- huge projects (1st patch)
> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes: [ suggestions ] Tom> Anyway, this patch brings us closer to using automake-1.8 for libgcj. Tom> Thanks! I think all the patches are in now. Could you try CVS automake and see how big the resulting Makefile.in is? Tom
Re: automake -vs- huge projects
>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> I've found this: adl> 1999-11-22 Tom Tromey <[EMAIL PROTECTED]> adl> * automake.in (handle_single_transform_list): Generate explicit adl> rule for subdir objects. Fixes new addition to subobj.test. I looked into this a bit today. One nice thing about having a patch list is that it records the rationale for changes somewhere... back in those days that sort of information was just lost. Sigh. I suppose the best we can hope for is to try out your change on a different platforms and in different scenarios and hope for the best... Tom
Re: SUBDIR_OBJECTS option
> "John" == jling <[EMAIL PROTECTED]> writes: John> I read in one thread the mention of a SUBDIR_OBJECTS option in John> automake. Supposedly this would prevent intermediate object files from John> ending up in the directory of the Makefile (I'm trying to use a non- John> recursive Makefile.am). John> Where and how is this option to be specified? Put `subdir-objects' into the AUTOMAKE_OPTIONS variable in Makefile.am. See the manual for this and other information... Tom
Re: Usage
> "John" == John Darrington <[EMAIL PROTECTED]> writes: John> One particular problem is the way in which they modify each other's John> input files. After a while, your Makefile.am looks like this: John> SUBDIRS= intl m4 intl m4 intl m4 intl m4 intl m4 intl m4 John> intl m4 intl m4 Report this as a bug against whatever tool (presumably gettext) is modifying Makefile.am. Tom
Re: automake -vs- huge projects
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> Furthermore, generally it does not work to compile both the .o adl> and .lo objects of a source file (in the last example Automake adl> is expected to warn that these files are being built both with adl> and without Libtool), so it sounds safe to remove the rules adl> which are not used. This would be a great change, but unfortunately it only gets us down to 3M, which is still about 6x too large. Tom
Re: automake -vs- huge projects
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> Couldn't we use the (existing) .java.o: inference rule in this adl> case? Actually, is there a difference between `%.o: %.java' and adl> `.java.o:' beside portability? -- I'm not asking about the adl> general % construction, just about this precise case where both adl> sides are expected to be in the same directory. My recollection is that we tried this and ran into real problems with it. I don't remember what they are any more. There's an old thread on this: http://sources.redhat.com/ml/automake/1999-04/threads.html#00033 At this point I still believed that these suffix rules would work. I couldn't find the point where we changed things. adl> So the simplest part of the fix would be to disable the output adl> of explicit rule for subdirectory sources without per-target adl> flags when subdir-objects is used. Yeah. That would help us a lot, but... adl> The other side of the coin is that dependency tracking will not adl> work anymore, because the dependency stuff for subdir/X.o should adl> go into subdir/.deps/X.Po but the default suffix rule will put adl> it in ./.deps/subdir/X.Po. I don't see an easy way to fix this, adl> unless we add some clumsy shell computation in the suffix rules adl> (while this can probably be folded into depcomp when it is used, adl> it does not seem to fit well in fastdep rules). Hmm, maybe this is the issue from way back. We definitely want to keep dependency tracking. This is pretty important. fastdep would be great, since we know we'll always be using gcc. If somehow dropping fastdep would get the Makefile.in to a reasonable size, though, I'd be in favor of that. Alternatively running sed or whatever once or twice before the compilation isn't going to hurt as much as having a 9M Makefile.in. So we could just do the rewrite in the suffix rule and pay the cost. adl> Note that this issue is unrelated to the %.o:%.java vs. .java.o: adl> choice. Not completely, since GNU make might give us handy macros that would let us do this transformation in-line. Tom
automake -vs- huge projects
Tom Fitzsimmons (CCd) has been working on upgrading libgcj to use newer auto* tools. This has gone swimmingly, except one problem with automake. A little background. libgcj is pretty big. It has 2,243 ".java" files at the moment. Previously it has been using its own slightly hacked automake 1.4. It used to use its own "%" rules to handle compiling .java (since 1.4 couldn't do this). It is part of GCC, which recently decided as a project that requiring GNU make is ok. We have to use subdir-objects, both because nobody wants 2000 .o files in "." and because we have unavoidable basename clashes between .java files. Also, we use a single top-level Makefile.am, as it is way more convenient. The problem is, automake generates an explicit rule for each compilation. Our resulting Makefile.in is nearly 9 megabytes. This is really much too large -- compare to 200K with automake 1.4. One idea we had for a fix is to introduce a new "gnu-make" option that would allow automake to generate code relying on GNU make. Then we could replace all those rules with a single "%.o: %.java". I thought this probably wouldn't be a popular idea, but figured I'd send it past you just in case. We definitely don't want to have a local fork of automake any more -- it is too much of a pain, and GCC as a whole is trying to update and standardize on one set of tools for the whole tree. Any other ideas for how to fix this problem? In absence of a real fix, another option for us is to just hand-write our Makefile. I'd really rather not do that, either. Though I suppose if we start from Automake's output it won't be too awful -- we can still preserve dependency tracking and the like. The long term maintenance on this is likely to be hard though. Tom
Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?
> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes: Dalibor> They use make -DCHECK=1 to enable adding of special debuggin flags, Dalibor> for example, and make -DPROF=1 to add another set of flags to enable a Dalibor> build fro profiling. You can always add your own targets: debugging: $(MAKE) CFLAGS='-g ...' Then "make mostlyclean debugging" should work ok. This isn't completely robust in all situations -- if something in CFLAGS changes a decision that configure makes, then you must reconfigure. However, the above would work fine most of the time. Maybe I'm misunderstanding what you want? If you've got several common ways to build something, I suggest either building outside the source tree (so you can easily have multiple builds with different options -- this is what I do) or using ccache. Tom
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> the *_OBJECT definitions assume the absence of shell-active Alexandre> characters in filenames, which is probably a safe Alexandre> assumption for Makefiles. It isn't unreasonable for a Java .class file's name to contain "$". libgcj only uses these for headers, but some other project might compile from .class to .o -- if they use an inner class, pow. Tom
Re: Non-recursive make & maintenance issue
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: Bob> In other words, dealing with junk like Bob> apps_build_postgres_src_build_postgres_SOURCES Bob> is very tiring and failure prone. Is there a reason why it can't Bob> simply be Bob> apps/build-postgres/src/build-postgres_SOURCES ? Yeah, that does seem easier. One problem is that you might refer to these variables elsewhere in your Makefile, and it isn't clear that automake can reliably rewrite all uses. The initial reason for canonicalizing macro names was simply that automake was pretty dumb, and passed through its input directly to its output. Rewriting wasn't really possible. Tom
Re: SUBDIRs and slashes
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: "Marty" == Marty Leisner <[EMAIL PROTECTED]> writes: adl> [...] Marty> common/Makefile.am:1: directory should not contain `/' Marty> Just wondering for some thoughts on this matter...is Marty> there any reason to insist on single level source Marty> directories in recursive make... adl> I can't think of any. Back in the day there were two problems. First, automake's "dist" rule was not robust if there was a gap in the hierarchy. Second, autoconf wouldn't properly create intermediate directories in this same situation. I don't know whether either of these is still true today. The first one in particular has probably changed, I think I'm remembering our first "dist" implementation :-) Tom
Re: Non-recursive make & maintenance issue
> "Jirka" == Jirka Hanika <[EMAIL PROTECTED]> writes: Jirka> My view is that these (and other) problems disappear if you use a Jirka> per-directory Makefile.am; but I also see the benefits (esp. compilation Jirka> speed) of a non-recursive Makefile. So the solution could be to support Jirka> generating a single Makefile from multiple Makefile.am's in Jirka> subdirectories. (Just kidding. But interested in seeing the reasons Jirka> why this is nearly impossible.) It isn't impossible. I once wrote up some ideas along these lines: http://sources.redhat.com/ml/automake/2001-07/msg00248.html Obviously I never got around to implementing this :-) Tom
Re: Newbie Request for Help (make dist problem)
> "Scott" == J Scott Amort <[EMAIL PROTECTED]> writes: Scott> - include Scott> - src Scott>- subdir1 Scott>- subdir2 Scott> - extra Scott> - build Scott>- src Scott> The configure.ac, Makefile.am, etc. files are located in the Scott> src subdirectory of the build directory at the bottom (nothing Scott> platform specific is therefore in the top level directory). Automake assumes that your top-level directory will have a Makefile.am... Scott> However, the problem lies Scott> when trying to make dist. It copies all of the include, src and extra Scott> directories into the build directory and only makes a tar.gz of the Scott> files that were originally in the build...src directory (i.e. configure, Scott> configure.ac, etc.). None of the source files make it into the Scott> archive. Why is this happening? This is fallout from that assumption. Scott> Additionally, it seems I would also Scott> need to put the header files into the distribution, so I added: Scott> EXTRA_DIST = \ Scott>$(ISRC)/header1.h \ Scott>$(SSRC)/header2.h Yeah, you can do this. It's a bit more idiomatic to list header files in a _SOURCES somewhere. They are ignored for purposes of compilation, but are distributed. Tom
Re: AM_INIT_AUTOMAKE comes from an older version of automake
> ">" == Piyush Kumar Garg <[EMAIL PROTECTED]> writes: >> configure.in:12: old Automake version. You should recreate aclocal.m4 >> configure.in:12: with aclocal and run automake again. >> I am using RHL8.0. I also tried upgrading automake to 1.7.9 and >> autoconf to 2.57. It doesn't work. It will be helpful, if someone can >> provide pointers on this. Try running "aclocal". Tom
Re: Makefile dependency
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> => automake-1.7's AM_MAINTAINER_MODE deactivates regeneration of Ralf> Makefile's. Ralf> I am inclined to interpret this as a bug and/or regression from earlier Ralf> versions of automake. I agree. The rule for maintainer mode was that it would deactivate rules for which you needed special maintainer tools. Rebuilding Makefile doesn't fit this category -- all you need is config.status, which you've got. Tom
Re: how to add dependencies to an auto-generated rule?
> "Jeff" == Jeff Rizzo <[EMAIL PROTECTED]> writes: Jeff> Ideally, I'd like to add a dependency on the file VERSION for the rule Jeff> for $(srcdir)/autoconf.h.in ... is there any way to do this? Doesn't it work to just write the dependency in Makefile.am? $(srcdir)/autoconf.h.in: VERSION Maybe my memory is slipping though. Perhaps automake gets confused about this and doesn't write out its own rule. Tom
Re: Adding a manpage to a autoconf/automake project (fwd)
> "Frank" == Frank Aune <[EMAIL PROTECTED]> writes: Frank> In my ROOT/Makefile.am I got so far: Frank> AUTOMAKE_OPTIONS = foreign 1.4 Frank> SUBDIRS = src Frank> I think I should then add in my ROOT/Makefile.am Frank> man_MANS = manpagename.8 Frank> where manpagename.8 resides in ROOT/man/ Perhaps I even Frank> have to add: Frank> SUBDIRS = src man Frank> to ROOT/Makefile.am? It depends on how you want to do things. You could write: man_MANS = man/manpagename.8 in your top-level Makefile.am. Or you could add a Makefile.am to the man/ directory, then update SUBDIRS and AC_CONFIG_OUTPUT in the top level. It's up to you. Tom
Re: defining xxx_PROGRAMS conditionally?
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> And where is CVS automake these days? Is it still on Harlan> sourceware.cygnus.com? That machine was renamed to "sources.redhat.com" long ago. But yes, that is where it is hosted. Tom
Re: .Po / .Plo Question
> "Asim" == Asim Suter <[EMAIL PROTECTED]> writes: Asim> 1) Which tool/script/program generates .Po/.Plo files ? And at what Asim> stage ? They are initially created, as empty files, by configure when building the various Makefiles. Then, they are updated as a side effect of compilation. Asim> 2) While rebuilding I see sometimes .Po files get "bad" in that Asim> they get malformed somehow for which gmake croaks and bails out. Asim> For instance: Asim>a) .deps/libcryptotool_a-sig_verify.Po:1: *** target pattern contains Asim> no `%'. Stop. Asim>b) Missing separator in file.. I haven't seen this before. What platform are you on? What version of make are you using? What compiler? Could you send the contents of that file? Tom
Re: [PATCH] ylwrap
Tom> Alexandre, is ylwrap still maintained in the automake repository? adl> Yes. Do you think we should mention Automake in the headings of adl> all similar auxiliary files? Sure, but it doesn't matter much to me. A note in HACKING would suffice as well. Tom
Re: [PATCH] ylwrap
> "Didier" == dc <[EMAIL PROTECTED]> writes: Didier> I've made a patch several months ago concerning ylwrap, and Didier> posted it on http://savannah.gnu.org/patch/?group=automake , Didier> but it seems that it wasn't included yet. Since there wasn't Didier> any response so far, I joined the list to ask about its Didier> validity. I think this is obviously correct. Alexandre, is ylwrap still maintained in the automake repository? Tom
Re: [SUGGESTION] Having 'make check' use AM_CPPFLAGS
> "Stephen" == Stephen Torri <[EMAIL PROTECTED]> writes: Stephen> TESTS = test_Foo Stephen> test_Foo_SOURCES = test_Foo.cpp As you discovered, you have to list test_Foo in a _PROGRAMS variable. I suggest check_PROGRAMS, as this is what `check' is made for. An entry in TESTS doesn't suffice; these aren't assumed to necessarily be compiled/linked programs. I suppose it almost works due to implicit rules in your `make'. Tom
Re: precompiled header suggestion
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> This sounds tricky. Adding such a file as a dependency of each .o file adl> means that _all_ of them will be updated whenever the .ghc changes. Good point. There are other possible approaches, though. For instance, for a given program, we could generate: am--program: $(program_BUILT_SOURCES) $(MAKE) program ... which is sort of like the BUILT_SOURCES implementation, but more targeted. That's sort of backward, since "make program" will no longer work as expected. But you get the idea... I suppose this is sort of secondary, and the main thing is just to have some automation for building the .gch file at all. adl> Putting the .ghc in BUILT_SOURCES automatically will not work if adl> the .ghc includes another BUILT_SOURCES indirectly (direct adl> inclusion is ok because we can issue the dependency ourself). adl> Maybe we can live with such a limitation? Yeah, there could be some problems here. But the user can always add an explicit dependency (just adding the .h to the gch file's _SOURCES would suffice). adl> Also I presume some libraries will also want to install such adl> files? Can they be installed? (Is this what install-pch is adl> about in your libstdc++ quote?) If so, such installation also adl> needs to be conditional. Honestly, I don't know too much about this. I'd suggest we leave open the possibility that they can be installed, though. adl> Maybe it would be simpler to introduce a new primary Yeah. Another idea would be to recognize `*.gch' automatically in a _SOURCES variable corresponding to a program or library. Tom
Re: How one could integrate Automake in an IDE ?
> "Alain" == Alain Magloire <[EMAIL PROTECTED]> writes: Alain> I'm curious on how the autoXXX tools like automake etc .. can Alain> be integrated nicely part of an IDE. So far what I've seen Alain> is not suitable enough ... Alain> If you know of a good integration, please send the URL. The only integration I'm aware of at all is with KDevelop. I've still never tried that :-( Alain> I'm looking at the Multipage Editor design, when one tab Alain> control(page) shows the raw source and the others shows a Alain> different "view" of the source that can be edited by newbies Alain> easily, of course with round-trip(i.e. the raw source Alain> Makefile.am reflects the other views vice-versa). Yeah, that sounds pretty reasonable, if difficult. It probably makes sense to concentrate on a simple-but-usable subset of automake, at least at first. Otherwise, the problem you'll encounter is that a Makefile.am is pretty complicated to interpret. For instance, there are runtime conditionals and configure substitutions. Another thing to think about is whether to support having a Makefile.am in each directory. It might be simpler just to have a single master Makefile.am at the top level. There are a lot of other things a useful auto*/eclipse integration could do. We could talk here or on the CDT list, as you (and others) prefer... Tom
Re: precompiled header suggestion
> "Rob" == Robert Collins <[EMAIL PROTECTED]> writes:
>> Recently gcc added precompiled header support. This is mostly useful
>> for C++, but C might benefit in some cases too.
Rob> Are you planning on doing this, or just sketching the design and hoping
Rob> for volunteer contributions?
I'm hoping someone else will do it :-)
Rob> What might be a useful starting point is some manual test cases or
Rob> sample rules, to aim for.
No problem. libstdc++ is already using it. I've appended some
snippets from their Makefile.am.
We could probably already get most of this by abusing _PROGRAMS.
That's ugly though.
I've also appended the section of the gcc manual explaining
precompiled headers.
Tom
pch_input = ${host_builddir}/stdc++.h
pch_output_builddir = ${host_builddir}/stdc++.h.gch
pch_source = ${glibcxx_srcdir}/include/stdc++.h
PCHFLAGS=-Winvalid-pch -Wno-deprecated -x c++-header $(CXXFLAGS)
if GLIBCXX_BUILD_PCH
pch_build = ${pch_input}
pch_install = install-pch
else
pch_build =
pch_install =
endif
# Build a precompiled C++ include, stdc++.h.gch.
${pch_input}: ${allstamped} ${host_builddir}/c++config.h ${pch_source}
touch ${pch_input}; \
if [ ! -d "${pch_output_builddir}" ]; then \
mkdir -p ${pch_output_builddir}; \
fi; \
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) ${pch_source} -O0 -g -o
${pch_output_builddir}/O0g; \
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) ${pch_source} -O2 -g -o
${pch_output_builddir}/O2g;
@node Precompiled Headers
@section Using Precompiled Headers
@cindex precompiled headers
@cindex speed of compilation
Often large projects have many header files that are included in every
source file. The time the compiler takes to process these header files
over and over again can account for nearly all of the time required to
build the project. To make builds faster, GCC allows users to
`precompile' a header file; then, if builds can use the precompiled
header file they will be much faster.
To create a precompiled header file, simply compile it as you would any
other file, if necessary using the @option{-x} option to make the driver
treat it as a C or C++ header file. You will probably want to use a
tool like @command{make} to keep the precompiled header up-to-date when
the headers it contains change.
A precompiled header file will be searched for when @code{#include} is
seen in the compilation. As it searches for the included file
(@pxref{Search Path,,Search Path,cpp.info,The C Preprocessor}) the
compiler looks for a precompiled header in each directory just before it
looks for the include file in that directory. The name searched for is
the name specified in the @code{#include} with @samp{.gch} appended. If
the precompiled header file can't be used, it is ignored.
For instance, if you have @code{#include "all.h"}, and you have
@file{all.h.gch} in the same directory as @file{all.h}, then the
precompiled header file will be used if possible, and the original
header will be used otherwise.
Alternatively, you might decide to put the precompiled header file in a
directory and use @option{-I} to ensure that directory is searched
before (or instead of) the directory containing the original header.
Then, if you want to check that the precompiled header file is always
used, you can put a file of the same name as the original header in this
directory containing an @code{#error} command.
This also works with @option{-include}. So yet another way to use
precompiled headers, good for projects not designed with precompiled
header files in mind, is to simply take most of the header files used by
a project, include them from another header file, precompile that header
file, and @option{-include} the precompiled header. If the header files
have guards against multiple inclusion, they will be skipped because
they've already been included (in the precompiled header).
If you need to precompile the same header file for different
languages, targets, or compiler options, you can instead make a
@emph{directory} named like @file{all.h.gch}, and put each precompiled
header in the directory. (It doesn't matter what you call the files
in the directory, every precompiled header in the directory will be
considered.) The first precompiled header encountered in the
directory that is valid for this compilation will be used; they're
searched in no particular order.
There are many other possibilities, limited only by your imagination,
good sense, and the constraints of your build system.
A precompiled header file can be used only when these conditions apply:
@itemize
@item
Only one precompiled header can be used in a particular compilation.
@item
A precompiled header can't be used once the first C token is seen. You
can have preprocessor directives before a precompiled header; you can
even include a precompiled header from inside another header, so long as
there are no C tokens before the @code{#include}.
@item
The precompiled header file must be produced for t
precompiled header suggestion
Recently gcc added precompiled header support. This is mostly useful for C++, but C might benefit in some cases too. To use it, you make a special `.gch' file by compiling a bunch of .h files. Then you tell gcc to use it when compiling. Automake could usefully automate this. First, when building the .gch file we could do automatic dependency tracking (the process of building this file should support the normal -M flags). Also, if a .gch file is listed in _SOURCES, it would be cool to build this file before trying to build any of the objects associated with the _SOURCES variable. (This could be generalized to all .h files, perhaps, to let us reduce the scope of BUILT_SOURCES.) This could be implemented by adding a new dependency for each .o file. There would also have to be a way to disable .gch support for non-gcc compilers. Tom
question about automake build
I haven't looked at this yet. Take a look at the appended `make' output. Why are we building in `tests' twice? Tom Making all in . make[1]: Entering directory `/home/tromey/gnu/Auto/automake/build' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/tromey/gnu/Auto/automake/build' Making all in m4 make[1]: Entering directory `/home/tromey/gnu/Auto/automake/build/m4' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/tromey/gnu/Auto/automake/build/m4' Making all in lib make[1]: Entering directory `/home/tromey/gnu/Auto/automake/build/lib' Making all in Automake make[2]: Entering directory `/home/tromey/gnu/Auto/automake/build/lib/Automake' Making all in tests make[3]: Entering directory `/home/tromey/gnu/Auto/automake/build/lib/Automake/tests' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/tromey/gnu/Auto/automake/build/lib/Automake/tests' make[3]: Entering directory `/home/tromey/gnu/Auto/automake/build/lib/Automake' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/tromey/gnu/Auto/automake/build/lib/Automake' make[2]: Leaving directory `/home/tromey/gnu/Auto/automake/build/lib/Automake' Making all in am make[2]: Entering directory `/home/tromey/gnu/Auto/automake/build/lib/am' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/tromey/gnu/Auto/automake/build/lib/am' make[2]: Entering directory `/home/tromey/gnu/Auto/automake/build/lib' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/tromey/gnu/Auto/automake/build/lib' make[1]: Leaving directory `/home/tromey/gnu/Auto/automake/build/lib' Making all in tests make[1]: Entering directory `/home/tromey/gnu/Auto/automake/build/tests' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/tromey/gnu/Auto/automake/build/tests'
Re: question about automake build
> "Alexandre" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: >> Take a look at the appended `make' output. Why are we building in >> `tests' twice? Alexandre> There are two different tests/ directories on HEAD... Duh, I can't read. Sorry about that. Tom
automake buglet
I'm using 1.7.6a. My Makefile.am has: TEXINFO_TEX = ../gcc/doc/include/texinfo.tex My configure.in has: AC_CONFIG_AUX_DIR(..) I expected TEXINFO_TEX to override AC_CONFIG_AUX_DIR, but it doesn't: fleche. automake Makefile.am:61: required file `../texinfo.tex' not found Tom
Re: missing fi for compilation to .obj
> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes: Eric> I don't have the automake sources in front of me, but the file to Eric> patch gets installed as /usr/share/automake/am/depend2.am. Eric> 2002-11-14 Eric Blake <[EMAIL PROTECTED]> Eric> * am/depend2.am: Add missing fi in c.obj rule. Looks good. I'm checking it in on the trunk and the 1.7 branch. Tom
Re: proposal to fork the build-tools projects
[ back to automake for this one ] > "Tom" == Tom Lord <[EMAIL PROTECTED]> writes: Tom> Also in defence of the `sh + make' approach: Tom> GNU make can do lots of useful globbing and set manipulation of file Tom> lists. Tom> If you do things right, your Makefiles don't need to contain Tom> specific filenames at all, and you don't need to edit any Tom> Makefiles as you add, delete, or rename files -- you just move Tom> things around more or less freely, and the build-process catches Tom> up more or less automatically. Long-time automake readers already know I'm strongly against this sort of structuring. This yields Makefiles which are fragile and undependable. For instance, if you create a temporary file with a "source-like" name in the source tree, then the build fails. I could add globbing to automake. I've always resisted it for the reasons above. (There was a brief time where I vacillated, if you read the archives fully. But that era is past.) Tom> I'm therefore not sure it's a really high priority to bother: GNU Tom> make, for example, seems like a quite tractable little program in Tom> an implementation that's well suited to make run really fast (and Tom> that can be compiled in a very minimal environment). All implementations of make, including GNU make, are missing features that are helpful when scaling up to larger builds. They are also missing features which help dependability and reproducibility of builds. In some cases, like using timestamps instead of signatures, this change is impossible to implement in make -- switching to signatures would break every Makefile that uses a stamp file. For this and other reasons I think that make must go. Tom
Re: Using gcj to create .class files
> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes: >> JAVAC = gcj -C Braden> I thought of that, but thought there might be something less Braden> subtle. Perhaps this should be done by the AM_PROG_GCJ macro? This is actually sort of a standard approach. AC_PROG_CC looks at the CC environment variable. As I recall AM_PROG_GCJ is only useful for compiling java to object code. Tom
Re: include files and statically linked libraries
> "Eric" == Eric Anderson <[EMAIL PROTECTED]> writes: Eric> Makefile:225: *** missing separator. Stop. Eric> and line 225 of the Makefile is: Eric> @SET_MAKE@ This means that whatever configure is building this Makefile doesn't invoke AC_PROG_MAKE_SET. AM_INIT_AUTOMAKE invokes this, so it is probably some weird problem. Maybe not running aclocal? Tom
Re: include files and statically linked libraries
>> AC_CONFIG_SUBDIRS(libghttp-1.0.9-mod) Eric> Where does this go in the configure.in file? Above the AC_OUTPUT Eric> command? From what I have read there has to be an order to the script, Eric> so I want to make sure I put it in the right place Anyplace before AC_OUTPUT is fine. >> SUBDIRS = libghttp-1.0.9-mod Eric> I assume this goes at the top of the Makefile.am file? Anyplace in Makefile.am is fine. At the top is typical though. Tom
Re: Disabling linking
> "Stephen" == Stephen Torri <[EMAIL PROTECTED]> writes: Stephen> In part of a project we generate code from an IDL Stephen> compiler. All we want to do is ensure that the files compile Stephen> but we do not want to link everything together to create an Stephen> executable. Is it possible to stop automake from invoking the Stephen> linker for just one directory? Not cleanly. You could specify the _LINK variable to be `true' or something like that. That would prevent linking. You might have to add a `.PHONY: programname' for it to make sense though. Tom
Re: Build problems for m4 target with make distcheck
> "Stephen" == Stephen Torri <[EMAIL PROTECTED]> writes: Stephen> When I can configure and compile a project that I am working Stephen> on the automake and autoconf files. When I run "make -j4" it Stephen> works fine. But when I try to do "make distcheck" I get back: Stephen> make[1]: *** No rule to make target `m4//_xine.m4', needed by Stephen> `../aclocal.m4'. Stop. `distcheck' will unpack your new tarball and try to configure and build it. Look in the unpacked directory. Is the `m4' subdirectory there? If not, did you perhaps forget `SUBDIRS = m4'? That's the first thing that comes to mind. After that, I don't have an idea. More information would be required. For instance if you could construct a simple test case, that would help... Tom
Re: module level flags
> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> 2. lobby for automake to support spitting out specialized Bruce> rules when it sees ``autogen_defReduce_c_CFLAGS = -O0''. This is PR automake/321. Bruce> Hopefully, it (or libtool) is smart enough to strip extra Bruce> optimizer specs for compilers that choke and respell them for Bruce> other compilers. I find it unlikely that this will ever happen. Tom
Re: grub-0.92 and CVS automake...
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> The problem is that grub likes the "old style" of AS rules, Harlan> and current automake/autoconf Really Want grub to use Harlan> AM_PROG_AS. Making this change means asm.S no longer Harlan> assembles because of missing -I directives. After adding Harlan> them, the resulting asm.o (apparently) has extra/duplicate Harlan> symbols, so the final link fails. And the AS rules have gone through a few mutations, so I'm not sure which style the old style is. You can set AM_ASFLAGS to include whatever you want: $(INCLUDES), $(DEFS), etc. That is one way to approximate one of the old behaviors. Or you can write your own .s.o / .s.lo rules for complete control. I don't know about the link problem. Tom
Re: Problem with 'make distcheck'
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: Tom> top_dir = .. Tom> foo_SOURCES = $(top_dir)/foo.c adl> Hmmm, are you sure? This construct is the one used in PR/325. adl> It breaks the dependency tracking code (the dependency file will have adl> "\$\(top_dir\)" in its name). Yeah, you're right :-(. I suppose we could add a %top_srcdir% substitution that is done while reading. That would be a new thing, though. I'd prefer to be cautious about it. Tom
Re: Problem with 'make distcheck'
> "Sebastian" == Sebastian Huber <[EMAIL PROTECTED]> writes: Sebastian> ok, changing `$(top_srcdir)' to `..' fixed the problem, but Sebastian> is this a temporay workaround or is the behaviour of the Sebastian> dist rule not correct in this case? To use $(top_srcdir) Sebastian> instead of '..' seems more natural to me. I doubt we'll change this. The fix would require rewriting the _SOURCES variable inside Automake. In general we avoid that sort of thing. You could write: top_dir = .. foo_SOURCES = $(top_dir)/foo.c That will preserve some clarity. Tom
Re: Problem with 'make distcheck'
> "Sebastian" == Sebastian Huber <[EMAIL PROTECTED]> writes: >> I know in the past it didn't work to put `$(top_srcdir)' in a path in >> a _SOURCES variable. Alexandre, has this changed? >> I don't think this would cause your problem necessarily, but it is an >> oddity. This is definitely the problem. Changing the `$(top_srcdir)' to `..' in your example fixes the problem. I didn't investigate too deeply. But my guess is that the $(top_srcdir) causes the dist rule (the one run in the distcheck build tree) to be confused about where to copy the source file. Tom
Re: Problem with 'make distcheck'
> "Sebastian" == Sebastian Huber <[EMAIL PROTECTED]> writes: Sebastian> libTACOExtensions_la_SOURCES = $(top_srcdir)/server/src/TACOServer.cpp \ I know in the past it didn't work to put `$(top_srcdir)' in a path in a _SOURCES variable. Alexandre, has this changed? I don't think this would cause your problem necessarily, but it is an oddity. Sebastian> A 'make distcheck' fails due to 'Error: files left after Sebastian> distclean'. These files are What system are you on? What version of automake are you using? What version of make are you using? Tom
Re: Should ylwap get installed by autoreconf -i?
Harlan> I have the current software project almost building using 2.54 Harlan> and pre-1.7, ylwrap is not present and is not being missed. I saw some email on the patch list about this too. ylwrap is only needed if you have more than one yacc source file (or more than one lex source file) in a given directory. Is that the case for you? Tom
Re: Should ylwap get installed by autoreconf -i?
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Docs>> The `ylwrap' program is distributed with Automake. It should appear in Docs>> the directory specified by `AC_CONFIG_AUX_DIR' (*note Finding Docs>> `configure' Input: (autoconf)Input.), or the current directory if that Docs>> macro is not used in `configure.in'. Harlan> What does "should" mean in that sentence? It means that automake expects to find the file there. However, automake also should know to copy the file there. Harlan> I'm asking because we have discovered that (since Harlan> automake/1.5, at least) ylwrap is not being installed by Harlan> either "automake --add-missing" or "autoreconf --install". Does this still happen with 1.6 and the current 1.7 prerelease? I remember some fixes in this area between 1.5 and now. In any case, failure to install this file is a bug. Tom
Re: strange error message
> "Nicholas" == Nicholas Kidd <[EMAIL PROTECTED]> writes: Nicholas> I was wondering if someone knew what these error message meant: Nicholas> Makefile:483: warning: overriding commands for target Nicholas> `engine/cpp/engine.o' Nicholas> Makefile:362: warning: ignoring old commands for target Nicholas> `engine/cpp/engine.o' This means that this file has two different rules to generate it in the Makefile. We can't tell exactly why without more information. What version of automake are you using? What is your Makefile.am? Tom
Re: How build C++ header with m4 and install them - no program
> "Marc" == Marc Waeckerlin <[EMAIL PROTECTED]> writes: Marc> I have a little C++ signal-slot library, that consists of only Marc> two C++ header files. The automake script should do the Marc> following: Marc> [ ... ] Marc> How do I write the makefile.am? nobase_include_HEADERS = sig/functor.hxx sig/sigslot.hxx SUFFIXES = .m4 sig/functor.hxx: sig/functor.hxx.m4 m4 $(srcdir)/sig/functor.hxx.m4 > sig/functor.m4 [ also for sigslot.hxx ] This isn't perfect since you must arrange for mkdir sig somehow. Automake doesn't do this automatically in this situation. Marc>- How to tell that the *.hxx are targets that must be cleared? CLEANFILES = $(nobase_include_HEADERS) Marc>- How to tell that the *.hxx are derieved from the *.m4? As above. Suffix rules don't work if the files are in subdirs. Suffix rule support in automake could use some enhancements. Marc> Is there a check or macros for invoking m4 in autoconf, automake? Not that I know of. Tom
Re: Automake 1.6.3 issue
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> You are alowed to overwrite the variable if you want, but only in adl> the condition where it was initially defined. I.e., you can do adl> pkgincludedir = something adl> but you can't do adl> if INSTALL_SNPRINTFV adl> pkgincludedir = something adl> endif I've long thought that we should, eventually, support the latter use. It seems to have a clearly defined meaning. And it is even useful in some situations. For instance, suppose in a very large project you want to `include' some boilerplate. Then you might conditionally override some value or another in a particular Makefile.am. Before Akim's rewrite of variable handling, we really couldn't do this. We just didn't have the internal abstractions. Now it might be possible, but I haven't looked. Tom
Re: ARFLAGS added
> "Erik" == Erik Hofman <[EMAIL PROTECTED]> writes: Erik> Therefore I've added an ARFLAGS definition to automake.in (see the Erik> patch) because at this time when setting program_AR = $(CXX) -ar -o Erik> the resulting link line will be: What version of automake are you using? Erik> program_AR = $(CXX) -ar I think this ought to override the default setting (which includes "cru"). So this should work already. Erik> - &define_variable ($xlib . '_AR', '$(AR) cru'); Erik> + &define_variable ($xlib . '_AR', '$(AR) $(ARFLAGS)'); This change supports my theory. If you redefine the per-library _AR setting, the "cru" won't be included -- this code is only run if the per-library AR setting is not defined. If it still fails for you, could you write a test case in the style of the test suite that shows the problem? Thanks. Tom
Re: How not to override existing file
> "Sean" == Sean MacLennan <[EMAIL PROTECTED]> writes: Sean> Ok, I have done that. Now one last question. What is the "correct" way Sean> to remove a directory when I do not want an error if the directory is Sean> non-empty. Sean> rmdir $(DESTDIR)$(rootdir) If you want to ignore the error, prefix the command with `-'. That tells make to ignore it. If you want to delete the directory even if it has contents, use "rm -rf". (This is dangerous.) Tom
Re: AMDEP does not appear in AM_CONDITIONAL
> ">" == Olefirenko Alexander <[EMAIL PROTECTED]> writes: >> Subj: what am i doing wrong ? >> executing automake i getting alot of messages: >> /usr/share/automake/am/lang-compile.am: AMDEP does not appear in >> AM_CONDITIONAL >> and >> /usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL My first guess is that you didn't run aclocal. If it isn't that then I'd need more information. For instance, what versions of auto* are you using? Tom
Re: Including header files in shared libraries
> "Xabier" == Xabier Rodriguez Calvar <[EMAIL PROTECTED]> writes: Xabier> include_HEADERS = hello-utils.h Xabier> Doing this hello-utils.h is included as a headers file that Xabier> belongs to hello project, but I want it to be included as Xabier> libhello-util. The easiest thing is to name it that way in the first place. Next easiest is to write your own install-local rule which installs the header by hand. Tom
Re: How not to override existing file
> "Sean" == Sean MacLennan <[EMAIL PROTECTED]> writes: Sean> sysconf_DATA = gofish.conf Sean> This works great at installing the conf file. Now I want to Sean> change it so it will not overwrite an exiting file. Preferably, Sean> if the file does not exist, it will be installed. If it does, Sean> the file will be installed as gofish.conf.new but leave the old Sean> file alone. There's no automatic way to do this. But you can write an install-local rule and do it by hand. Tom
Re: Single question FAQ
> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> Attached are three files: I finally looked at this. It sure is a lot of machinery for a faq! Also I had to download and install autogen, since it doesn't come with my distribution. When I try to run autogen I get this: grep: ../automake_toc.html: No such file or directory grep: ../automake_toc.html: No such file or directory I think that's because in our htdocs cvs module we use a single large `automake.html'. I ran autogen like this: AM_HTMLDOC_DIR=.. export AM_HTMLDOC_DIR autogen automakefaq.def (automake.html is in `..') I changed the references to `automake_toc.html' to `automake.html', but now the generated html doesn't look right. For instance: See
Re: [patch] Another over zealous sanity check
> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> +## DO NOT FORGET that there may be duplicates in the source and build :-( When? Bruce> - cp -pR $$d/$$file $(distdir)$$dir || exit 1; \ Bruce> + cp -pR $$d/$$file $(distdir)$$dir || :; \ A patch like this really requires a rationale. Tom
Re: GNU build system support (autoconf, automake, libtool) for NetWare
> "Paul" == Paul Thomas <[EMAIL PROTECTED]> writes: Paul> Does anyone know of any past, current, or future efforts to have Paul> the GNU build system (autoconf, automake, libtool) support the Paul> NetWare platform? I'm not aware of any efforts in this regard. Tom
Re: automake & Objective C
> "Matej" == Matej Kosik <[EMAIL PROTECTED]> writes: Matej> I have put together some awful autoconf macros Matej> cheking `Objective C' compiler's functionality. Matej> automake: objcprog/Makefile.am: Objective C source Matej> seen but `OBJC' not defined in `configure.ac' Since there are no pre-canned macros for ObjC, you must define the `OBJC' macro in configure.ac yourself. Like so: OBJC=... something ... AC_SUBST(OBJC) Tom
Re: Parallel builds and SUBDIRS
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: [ This is a reply to some pretty old email. As is my habit. ] Harlan> I'm working on a project where Somebody decided it would be a Harlan> feature to hack the automake templates to permit subdirs to be Harlan> built in parallel. Ok. Harlan> I'm wondering if there is benefit to allowing SUBDIRS to be Harlan> build in parallel by option (or default), and wondering if Harlan> it's possible, reasonable, and not too difficult to use Harlan> dependency lines in the "parent" Makefile.am to control Harlan> serialization, ie: I've actually considered this from time to time. It isn't an unreasonable idea. It would definitely have to be explicitly requested, though. We've long promised that SUBDIRS will be built in order. Lots of packages depend on this. Harlan> SUBDIRS = include lib bar baz foo Harlan> lib: include Harlan> bar baz foo: lib I suppose what we could do is have a new rule for each subdir: all-recursive-include clean-recursive-include ...: cd include && $(MAKE) ... Then from a specification of subdir interdependencies we could generate the exhaustive list. In Makefile.am: lib-subdir: include-subdir In Makefile.in: all-recursive-lib: all-recursive-include clean-recursive-lib: clean-recursive-include ... Perhaps there's some cleaner way. I don't know, I'm just writing this off the top of my head. Hmm, the clean dependencies would be tricky. Right now we run clean rules in the opposite order as build rules. The gcc top-level Makefile already does something like this. It isn't as robust as what we'd require for automake. One question I have is whether this is actually worth the extra hair. How much parallelism do we really lose with the current implementation? How much does it slow down the build? These questions implicitly assume that the primary benefit of this approach is improved performance. Are there other benefits? Anyway, if the benefit is substantial this would make a good feature-request PR. If there's no benefit, it may be better to drop it. Tom
Re: AC_CONFIG_FILES(whatever) and the $(AUTOMAKE) rule generated by automake?
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> So should the list provided by AC_CONFIG_FILES(whatever) be Harlan> any different from the list "fed" to $(AUTOMAKE) in the Harlan> generated Makefile.in? According to the code (see parse_arguments), you should pass the same text in both cases. I don't think we've ever defined what it would mean to write `Makefile:foo:Makefile.in'. Automake accepts this, but I don't recall what meaning it is given. I imagine all but one of the input files are ignored. Tom
Re: Pathalogical behavior with "more" AM_CONDITIONAL()s?
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> Again, I'm not sure why automake cares about SUBDIRS. Automake computes DIST_SUBDIRS from SUBDIRS, unless you define DIST_SUBDIRS yourself. In this case it might try to compute a value. With a large number of conditionals affecting the value of SUBDIRS, this can be expensive :-( Try setting DIST_SUBDIRS yourself and see if that solves the problem. Tom
