Re: Generating missing depfiles by an automake based makefile

[Tom Tromey]

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

[Tom Tromey]

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

[Tom Tromey]

> "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)

[Tom Tromey]

> "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

[Tom Tromey]

> "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

[Tom Tromey]

>> 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

[Tom Tromey]

>> 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?

[Tom Tromey]

> "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?

[Tom Tromey]

> "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?

[Tom Tromey]

> "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

[Tom Tromey]

 Stefano == Stefano Lattarini stefano.lattar...@gmail.com 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

[Tom Tromey]

 Stefano == Stefano Lattarini stefano.lattar...@gmail.com 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

bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

 Stefano == Stefano Lattarini stefano.lattar...@gmail.com 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

bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

 Stefano == Stefano Lattarini stefano.lattar...@gmail.com 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

[Tom Tromey]

 Stefano == Stefano Lattarini stefano.lattar...@gmail.com 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

[Tom Tromey]

 Stefano == Stefano Lattarini stefano.lattar...@gmail.com 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

[Tom Tromey]

 Stefano == Stefano Lattarini stefano.lattar...@gmail.com 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: GNU make or portable make?

[Tom Tromey]

 Ralf == Ralf Wildenhues ralf.wildenh...@gmx.de 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

[Tom Tromey]

 Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us 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

[Tom Tromey]

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?

[Tom Tromey]

  == 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@

[Tom Tromey]

 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

[Tom Tromey]

 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

[Tom Tromey]

 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?

[Tom Tromey]

 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?

[Tom Tromey]

 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?

[Tom Tromey]

 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

[Tom Tromey]

 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

[Tom Tromey]

 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: non-recursive automake advice?

[Tom Tromey]

 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 Tromey]

 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?

[Tom Tromey]

 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

[Tom Tromey]

 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.

[Tom Tromey]

 Hans == Hans Deragon [EMAIL PROTECTED] writes:

HansAutomake should create a script that simply contains all the rm
Hanscommands 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

[Tom Tromey]

 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))

[Tom Tromey]

 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

[Tom Tromey]

 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

[Tom Tromey]

 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

[Tom Tromey]

 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 (1st patch)

[Tom Tromey]

 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: SUBDIR_OBJECTS option

[Tom Tromey]

 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: automake -vs- huge projects

[Tom Tromey]

 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: Usage

[Tom Tromey]

 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

automake -vs- huge projects

[Tom Tromey]

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: automake -vs- huge projects

[Tom Tromey]

 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

Re: automake -vs- huge projects

[Tom Tromey]

 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: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?

[Tom Tromey]

 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: Newbie Request for Help (make dist problem)

[Tom Tromey]

 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: Non-recursive make maintenance issue

[Tom Tromey]

 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: SUBDIRs and slashes

[Tom Tromey]

 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

[Tom Tromey]

 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: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C

[Tom Tromey]

 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: AM_INIT_AUTOMAKE comes from an older version of automake

[Tom Tromey]

  == 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

[Tom Tromey]

 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: defining xxx_PROGRAMS conditionally?

[Tom Tromey]

 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: how to add dependencies to an auto-generated rule?

[Tom Tromey]

 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)

[Tom Tromey]

 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: .Po / .Plo Question

[Tom Tromey]

 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:
Asima) .deps/libcryptotool_a-sig_verify.Po:1: *** target pattern contains
Asim no `%'.  Stop.
Asimb) 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 Tromey]

 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: [PATCH] ylwrap

[Tom Tromey]

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: [SUGGESTION] Having 'make check' use AM_CPPFLAGS

[Tom Tromey]

 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: How one could integrate Automake in an IDE ?

[Tom Tromey]

 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

[Tom Tromey]

 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: precompiled header suggestion

[Tom Tromey]

 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 the same language as

precompiled header suggestion

[Tom Tromey]

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

Re: question about automake build

[Tom Tromey]

 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

[Tom Tromey]

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

[Tom Tromey]

 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: include files and statically linked libraries

[Tom Tromey]

 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: Using gcj to create .class files

[Tom Tromey]

 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: proposal to fork the build-tools projects

[Tom Tromey]

[ 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: Disabling linking

[Tom Tromey]

 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

[Tom Tromey]

 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

[Tom Tromey]

 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: Problem with 'make distcheck'

[Tom Tromey]

 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: grub-0.92 and CVS automake...

[Tom Tromey]

 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'

[Tom Tromey]

 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'

[Tom Tromey]

 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: Problem with 'make distcheck'

[Tom Tromey]

 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: Should ylwap get installed by autoreconf -i?

[Tom Tromey]

 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: How build C++ header with m4 and install them - no program

[Tom Tromey]

 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: strange error message

[Tom Tromey]

 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: Automake 1.6.3 issue

[Tom Tromey]

 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

[Tom Tromey]

 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

[Tom Tromey]

 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: Including header files in shared libraries

[Tom Tromey]

 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: AMDEP does not appear in AM_CONDITIONAL

[Tom Tromey]

  == 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: GNU build system support (autoconf, automake, libtool) for NetWare

[Tom Tromey]

 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: [patch] Another over zealous sanity check

[Tom Tromey]

 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: Single question FAQ

[Tom Tromey]

 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 a href=/manual/automake/html_node/are explained later (see a 
href=#Program%20and%20Library%20Variables

Can you fix this?

Tom

Re: automake Objective C

[Tom Tromey]

 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: Support for new languages

[Tom Tromey]

 Rafael == Rafael Jesus Alcantara Perez [EMAIL PROTECTED] writes:

Rafael Is there any way of adding support for new languages to
Rafael AUTOMAKE, without modifying the source of the main AUTOMAKE
Rafael script (usually /usr/bin/automake)?

It depends.

If the language is a simple C-like language then suffix rules may
suffice.

And of course you can always write support code in a .am file that you
`include' wherever you need it.  This works if the support you need is
largely boilerplate rules without special processing.

Otherwise, you need to hack automake.  What language are you concerned
about?

Tom

Re: Pathalogical behavior with more AM_CONDITIONAL()s?

[Tom Tromey]

 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

Re: AC_CONFIG_FILES(whatever) and the $(AUTOMAKE) rule generated by automake?

[Tom Tromey]

 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: Parallel builds and SUBDIRS

[Tom Tromey]

 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: myconfig.h in dist

[Tom Tromey]

 Waldemar == Waldemar Rosenbach [EMAIL PROTECTED] writes:

Waldemar If I include it into include_HEADERS or _SOURCES, then it is
Waldemar installed and distributed.  If I don't include it in any of
Waldemar the both, then it is neither installed nor distributed.

First, you shouldn't be installing a config.h.  Generally speaking,
that is; sometimes there are exceptions.  But care is required since
includedir is platform-independent (in theory), but config.h isn't.

Anyway, you can use nodist_include_HEADERS to avoid having config.h in
the distribution.  Likewise for _SOURCES, though as I said earlier you
simply shouldn't list config.h there.

Tom

Re: Problems defining Makefile.am trying to cross-compile for VxWorks on cygwin

[Tom Tromey]

 Niklaus == Niklaus Giger [EMAIL PROTECTED] writes:

Niklaus AUTOMAKE_OPTIONS = dejagnu
Niklaus bin_PROGRAMS = calc.o
Niklaus calc_SOURCES = calc.c

The variable should be named calc_o_SOURCES and not calc_SOURCES.

Niklaus checking for C compiler default output... configure: error: C compiler
Niklaus cannot create executables

This isn't really an automake problem.  If your cross-compiler can't
create executables then you'll need to do some special hackery.  I
suggest asking on the autoconf list.

Tom

Re: listing some files to be build with no optimization?

[Tom Tromey]

 Dan == mcmahill  [EMAIL PROTECTED] writes:

Dan Is there an easy way in automake to indicate that certain source
Dan files should be compiled without optimization?

Nope.  This is really a limitation of the whole GNU style of build.
The user can always set CFLAGS=-O, and there's not a very good way to
override it.

You can of course hack things by making an explicit rule to build the
.o file in question and have it ignore CFLAGS or whatever.

Tom

Re: Processing scripts to handle --program-suffix

[Tom Tromey]

 Ross == Ross Burton [EMAIL PROTECTED] writes:

Ross However, galeon is started via a shell script which sets up an
Ross environment.  Is it possible to get the final name of galeon-bin
Ross (defined in bin_PROGRAMS) and tell automake to process the shell
Ross script and replace @BINARY@ (or some such name) with the name of
Ross the binary, as it will be after transformations?

You have to do it by hand, applying the transform yourself.

Tom

Re: depcomp for texinfo + automake in guile

[Tom Tromey]

 Thi == Thien-Thi Nguyen [EMAIL PROTECTED] writes:

Thi i could not find ready documentation (automake 1.6.1) on how to
Thi emulate the include .deps/foo.Ptexi since, if i add that to
Thi Makefile.am, it seems automake interprets that for itself instead
Thi of passing it through to the end Makefile.

Yes, that's right.

Thi the workaround is to have configure run a program after invoking
Thi config.status to do the job.  is there a better way?

Perhaps not :-(.  This really isn't too different from what automake
itself actually does.

Thi my question is: is there a canonical way to do this w/in the
Thi automake worldview that i've not yet discovered?  if not, what
Thi would be the best way to contribute general handling of .texi
Thi generation to automake?

It would be nice to let other tools that generate dependencies well
integrate into automake seamlessly.  As far as I know nobody has
really thought about the problem though (you seem to be the first
person to be interested).

Thi the other top-level question is: i noticed automake in guile per
Thi rms request in a todo list (somewhere).  has anyone started
Thi that?  if not, is anyone in the audience interested in funding
Thi that work?

Nobody has started doing that.  It seems pretty unlikely to ever
happen.

Tom