> "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.
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
> "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
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/autom
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 buildi
> "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
> "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.
Th
> "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 give
> "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;
> "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
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
> "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.
As
> "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
> "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: VERSIO
> "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/ Pe
> "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 wa
> ">" == 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
> "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
> "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>
> "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 sing
> "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 ?
Ye
> "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
> "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:
debuggi
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.
> "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, ju
> "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
> "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
Rep
> "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 Makefil
>>>>> "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
> "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
> "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
> "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 co
> "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 dur
> "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
> "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 bui
> "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
Lar
> "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
> "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
> "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 f
> "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 u
> "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:
BUI
> "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
> "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 sep
> "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
> "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
> "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 te
> "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 ver
> "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
> "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
> "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 i
> ">" == H Nanosecond writes:
>> I encountered pavuk-0.9pl24 a url download utility,
>> it has a space in the version name in the Init:
>> AM_INIT_AUTOMAKE($PACKAGE, "$VERSION $host_alias")
>> and this made make distcheck choke from not quoting in shell commands.
>> So my question is what
> "Mark" == Mark Galassi <[EMAIL PROTECTED]> writes:
Mark> lib_LTLIBRARIES = libgenie.la @SWIG_LIBRARIES@
Mark> EXTRA_LTLIBRARIES = libge.la libgeperl.la libgeguile.la
This is right.
Mark> /bin/sh ../libtool --mode=install /usr/bin/install -c libge.la
/tmp/junk/lib/libge.la
Automake uses
>> if SWIG
>> lib_LTLIBRARIES = libgenie.la libge.la libgeperl.la libgeguile.la
>> else
>> lib_LTLIBRARIES = libgenie.la
>> endif
Mark> I was trying that, and I get these two messages, the first seems
Mark> incorrect and the second is very obscure:
Mark> [rosalia@odie genie]$ automake -a
Mark> a
> "Andrew" == Andrew S Townley <[EMAIL PROTECTED]> writes:
Andrew> Hi. I have been trying to add support for our ESQL/C
Andrew> preprocessor to an Automake makefile, but I'm having trouble
Andrew> with a couple of different things.
Andrew> The extra sed command is there so that the dependen
> "Mike" == Mike Reilly <[EMAIL PROTECTED]> writes:
Mike> As root, I ran "tar -zxvf automake-1.4.tar.gz". I
Mike> then went into the directory that was created, ran
Mike> ./configure, make and then make install.
Mike> When I checked the version, however, I found that I
Mike> still had autom
> "Mark" == Mark E <[EMAIL PROTECTED]> writes:
Mark> Could an equivalent change be considered to automake.in so
Mark> DJGPP's bison will work? While not the best solution, it's the
Mark> best one I can think of until there is suitable macro in
Mark> Autoconf to deal with this. I'm not famili
> "Linus" == Linus Nordberg <[EMAIL PROTECTED]> writes:
Linus> What's the reason behind putting all `-I' stuff in DEFS?
If you mean in Makefile.in, it is laziness.
Linux> I would like to pass a few -D to m4, but don't want the `-I':s.
Use INCLUDES to hard-code your own options.
You can (an
Linus> hmpf! :)
[ ... ]
Linus> (AM_CLFAGS, hmmm... American C language fags? :-)
It is early here. My fingers aren't awake yet.
Linus> I don't want to pass any `-I' to m4 since some m4's don't like that,
Linus> so using INCLUDES is no good. How should AM_CFLAGS be used?
Ah. Don't use DEFS or
> "Merijn" == mdejonge <[EMAIL PROTECTED]> writes:
Merijn> I'm new to this mailing list so I don't know whether to
Merijn> following has been discussed before (At least I couldn't
Merijn> find anything on the mailing list).
It has been, but it may have been quite a while ago.
Merijn> Durin
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Any point in using the f flag at all in such cases?
Lars> => $(TAR) cho $(distdir) | $(GZIP) -c > $(distdir).tar.gz
I thought some versions of tar defaulted to something like /dev/rmt8
(or some other equally obscure device). It's h
> "Merijn" == Merijn de Jonge <[EMAIL PROTECTED]> writes:
Merijn> In the Makefile.am I have listed these dependencies on
Merijn> multiple lines, Automake generates a Makefile.in which
Merijn> contains all 356 file names on a single line. This line is too
Merijn> long for configure to instanti
> "Todd" == Todd Dukes <[EMAIL PROTECTED]> writes:
Todd> I was disapointed that pkgdata_DATA files are not included
Todd> in a distribution without also being listed in EXTRA_DIST.
Todd> Is this a bug? The section in the manual says EXTRA_DIST is
Todd> for files that aren't installed by the
Merijn> This line is too long for configure to instantiate and the
Merijn> result is a truncated line of dependencies.
Akim> What happens? Do you know where this limitation comes from?
Typically sed chokes when building Makefile from Makefile.in.
I forgot about this when making some changes in
Jim> Here's an untested patch.
I'll look at this soon.
Jim> BTW, Tom, what about that last patch I sent in (testing for close
Jim> failure)?
Yeah :-(
I haven't had much automake hacking time for a while (again). I guess
I'd like to get more people checkin rights to make up for my failings.
Ji
> "Hal" == Duston, Hal <[EMAIL PROTECTED]> writes:
Hal> I am setting my package up with automake/autoconf, and want to
Hal> provide gnu getopt if it is not available. I noticed
Hal> AC_REPLACE_GNU_GETOPT in the info file, but it doesn't seem to be
Hal> completely implemented. It is in autom
Hal> That would be something I would install on my development system?
Hal> Would I need to put it somewhere special so it doesn't go away if
Hal> I upgrade automake? I would really rather do it the "proper" way
Hal> if true. Or is get a copy the "proper" way? Still trying to get
Hal> my br
> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes:
>> localhost:~/src/4dim$ automake
>> Makefile.am:2: bad macro name '4dim_SOURCES'
Olly> I hit this problem a few months ago. It's an unnecessary
Olly> restriction which is fixed in the CVS version of automake.
Olly> If you'd prefer not to
> "Carl" == Carl van Schaik <[EMAIL PROTECTED]> writes:
Carl> I am at present trying to get automake to build a library that
Carl> contains various source files (.c, .s) that I want to compile
Carl> with different compilers. Automake no matter what I have done,
Carl> sees the suffix (.c, .s)
> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> I've just looked into the failure of test pr19.
I don't understand.
pr19.test works fine for me.
Tom
> "Carl" == Carl van Schaik <[EMAIL PROTECTED]> writes:
Carl> Also, there any way to get automake to compile a .c file to .o
Carl> and not make a library or program out of it?
Carl> I'm doing some cross-compiling stuff that only seems to work if
Carl> I compile files to .o and use the linker
> "Michael" == Michael Bletzinger <[EMAIL PROTECTED]> writes:
Michael> Is anyone working on creating rpm targets similar to "make
Michael> dist". I was thinking that automake could for example
Michael> generate the spec file from a template.
I occasionally hear about people wanting this, but
> "John" == John Fremlin <[EMAIL PROTECTED]> writes:
John> This patch adds the ability to use partial $(wildcard *.h)
John> (GNU?) make-style syntax in automake variable declarations. It
John> is useful for projects where the files for each target are are
John> organised in a single director
> ">" == OKUJI Yoshinori <[EMAIL PROTECTED]> writes:
>> 2. The target `Makefile' depends on $(BUILT_SOURCES).
>> The solution may be to get rid of the dependency in the item 2,
>> so my question is why Makefile must depend on BUILT_SOURCES. Is
>> there some good reason?
Only a historical
>> Ok, I will do. BTW, now does Jim have the maintainship? I thought
>> you were the maintainer.
I am, but I haven't had much time to check things in lately.
Neither has Alexandre, I think. I'm hoping Jim will.
T
Pavel> In fact, the failures are caused by other tests that
Pavel> (erroneously!) copy install-sh, missing and mkinstalldirs to
Pavel> the test directory.
Thanks. I'm seeing this now.
I'll look into it soon.
Tom
Harlan> Anybody have an idea of how much trouble it will be to accept
Harlan> the nodist_ prefix on HEADERS?
If you're using the cvs automake, then I'm suprised it doesn't work.
Could you write a test case (in the style of the test suite)?
Tom
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> This is a problem as Foo_real.cpp includes Foo_derived.h.
Alex> How can I get a result similar to the old BUILT_SOURCES, where
Alex> the commands to produce the derived source files for a target
Alex> are run _before_ the non derived
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>> How about just creating standard Makefile dependencies?
>>
>> Foo_impl.o: Foo_s.hh Foo_c.hh Foo_s.cpp Foo_c.cpp
>> Foo_impl.$(OBJEXT): Foo_s.hh Foo_c.hh Foo_s.cpp Foo_c.cpp
Alex> That would work. I wanted to avoid adding dependencies ma
> "Ionutz" == Ionutz Borcoman <[EMAIL PROTECTED]> writes:
Ionutz> Is automake going to support bcc55 ? Or is there a way to create the
Ionutz> Makefile for Win$$ + bcc55 from Makefile.am ?
I don't know what bcc55 is. I'm not against supporting it. We
already support Microsoft's compiler, I
> "Sascha" == Sascha Ziemann <[EMAIL PROTECTED]> writes:
Sascha> flex conf_lexer.l && mv lex.yy.c conf_lexer.c
Sascha> gcc -c conf_lexer.c
Sascha> bison -y conf_parser.y && mv y.tab.c conf_parser.c
Sascha> gcc -c conf_parser.c
Sascha> And this means, that the tokens are not available i
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>> I agree it would be nice to say "build these files before doing
>> anything else". That's sort of a pain with make. One idea would
>> be to introduce an "all-hook" which would be run before "all".
>> This solves the common problem, but
> "Sascha" == Sascha Ziemann <[EMAIL PROTECTED]> writes:
Sascha> bin_PROGRAMS = rlpd rlpc
Sascha> rlpd_SOURCES = rlpd.c rlp.c errwrap.c conf_parser.y conf_lexer.l
Sascha> rlpc_SOURCES = rlpc.c rlp.c errwrap.c
Sascha> How can I prevent the second program (rlpc) from beeing linked
Sascha> with
Sascha> I don't specify -lfl and I don't use LIBS, so I can not use
Sascha> LIBADD instead.
I don't understand this.
Anyway, the current automake doesn't force you to link with @LEXLIB@.
Neither did automake 1.4, if I remember correctly.
So I don't understand why you are seeing -lfl on your link
Chris> When I run "make check" when installing automake-1.4,
Chris> it passes all 194 tests, except for the cond5.test.
Chris> How do I fix this?
This test tests for a bug that used to cause automake to hang. The
test works by running automake and then waiting a while to see if it
terminates.
> "Okuji" == OKUJI Yoshinori <[EMAIL PROTECTED]> writes:
Okuji> Automake requires some helper scripts such as `depcomp', but there
Okuji> is an inconsistency. The documentation tells me that they are put in
Okuji> the top directory or the source directory. However, while `depcomp' is
Okuji> r
> "Thomas" == Thomas Tanner <[EMAIL PROTECTED]> writes:
Thomas> I wonder why automake passes CFLAGS and AM_CFLAGS
Thomas> to libtool in link mode? This makes it impossible
Thomas> to differentiate between compiler and linker (LDFLAGS)
Thomas> flags.
The GNU Coding Standards mandate this.
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> Do you have any hints before I dive in? Is the current CVS head
Alex> a good starting point?
CVS head is a good starting point.
There is a HACKING file that explains some rules (which may or may not
apply; I forget exactly what is in
>> I'm skeptical that this approach will work :-(
Alexandre> I still think we should revert to the old behavior of
Alexandre> Makefile depending on BUILT_SOURCES, at the very least, as
Alexandre> a deprecated feature, for backward compatibility.
This only works for GNU make. So it was never a r
Alexandre> So maybe we should use a stamp file that all $(OBJECTS)
Alexandre> depend upon, and that runs $(MAKE) $(BUILT_SOURCES) before
Alexandre> it touches itself. It still wouldn't work in case someone
Alexandre> removes one of the BUILT_SOURCES but leaves the stamp file
Alexandre> around, bu
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> The problem is that when it's time to link against the C++
Lars> library in the parent project, a C linker is chosen, which fails
Lars> on a lot of platforms (IRIX is one of them).
Lars> Does anyone know why $(LINK) is chosen instead o
Sam> The basic problem is that source is conditionally compiled into
Sam> SDL, and supposedly the attached code is supposed to do the
Sam> "right thing", but I can't get it to include rules for the
Sam> objects. I can get the desired effect using automake
Sam> conditionals, but the complexity of
>> How do I override the rule for entering one of them?
Alexandre> I don't think you can override it :-(
You can rewrite the entire rule, but of course that will break in a
future version.
Tom
> "Christophe" == Christophe Gros <[EMAIL PROTECTED]> writes:
Christophe> I'm sorry to disturb you with some administrative matter,
Christophe> but I've tried to unsubscribe from the automake mailing
Christophe> list without success. It seems that there is a
Christophe> discrepancy between s
> "Michael" == Michael Bletzinger <[EMAIL PROTECTED]> writes:
Michael> The first issue is: Where should the common configuration
Michael> information needed to build the various subpackages be
Michael> stored?
It depends on your goals.
Michael> I would like to set up a base package for the
> "Fred" == F Labrosse <[EMAIL PROTECTED]> writes:
Fred> Is it possible to test for a library using $CXX instead of $CC?
Fred> My problem is that on a Solaris box, some libraries won't link
Fred> with cc while they do with CC (e.g. qt).
Can't you set the language to C++ and then test?
Seems
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> I've always been annoyed that automake --add-missing --copy
Lars> doesn't pass the "--copy"-option along to libtoolize, so I end
Lars> up with symlinked config.guess, config.sub, ltconfig and
Lars> ltmain.sh.
Fixed.
Lars> This might b
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
Morten> BTW, I've already written a pretty extensive Qt-check macro. Feel free
Morten> to check it out, its part of our SoQt distribution at
Morten> http://www.sim.no/coin.html>, or just do:
Why not submit it to the autoconf macro arch
> "Fred" == F Labrosse <[EMAIL PROTECTED]> writes:
Fred> On solaris, X11 needs some extra libs to be used. Apparently,
Fred> AC_PATH_XTRA can find them and sets some variables: X_CFLAGS,
Fred> X_LIBS, and X_EXTRA_LIBS.
Fred> My question is what is the best way to use them?
"best" depends o
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> I'm using CVS automake and have source files in sub directories of my
Alex> project like so:
Alex> That would be fine, but AFAICT there is no way for make to apply the
Alex> normal .c.o suffix rule in this case to produce the object f
> "Fred" == F Labrosse <[EMAIL PROTECTED]> writes:
Fred> DEFINESDOC=`echo @DEFS@ | sed -e "y/-D/ /"` && \
Fred> export VERSION DEFINESDOC DOC_H_FILES && \
Fred> makeDoc && \
Fred> touch doc
Fred> Only DEFINESDOC is available in makeDoc!!! i.e. the variables
Fred> not defined in the
1 - 100 of 1295 matches
Mail list logo
