> "Jacob" == Jacob Bachmeyer writes:
Jacob> Well, bringing the topic back to Automake, what prevents using
Jacob> something like:
Jacob> Makefile: ${srcdir}/Makefile.in
Jacob> ${top_builddir}/config.status
Jacob> ${srcdir}/Makefile.in: ${srcdir}/Makefile.am
Jacob> $(AUTOMAKE) ...
Jacob> O
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 s
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> ear
> "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 somet
> "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
> "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 co
>> 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 someon
>> 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
> "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 -- s
> "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:
> "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
> "Stefano" == Stefano Lattarini writes:
Stefano> On a second though, by double-checking the existing code, I
Stefano> couldn't see how the 'cygnus' option could possibly influence
Stefano> the location of the generated info files -- and it turned out
Stefano> it didn't! Despite what was doc
> "Stefano" == Stefano Lattarini writes:
Stefano> It should still be possible, with the right hack (which is
Stefano> tested in the testsuite, and required by other packages
Stefano> anyway). The baseline is: if you don't want your '.info' files
Stefano> to be distributed, then it should be
> "Stefano" == Stefano Lattarini writes:
Stefano> Sorry if I sound dense, but what exactly is the feature you are
Stefano> talking about here?
I was under the impression that it would no longer be possible to build
info files in the build tree. But, I see that, according to the
Automake man
> "Stefano" == Stefano Lattarini writes:
Stefano> True, and that was even stated in the manual; the whole point
Stefano> of ditching support for cygnus trees is that by now those two
Stefano> big users are basically not making any real use of the 'cygnus'
Stefano> option anymore. To quote my
> "Stefano" == Stefano Lattarini writes:
Stefano> Note there's nothing I'm planning to do, nor I should do, in
Stefano> this regard: the two setups described above are both already
Stefano> supported by the current automake implementation (but the last
Stefano> one is not encouraged, even tho
> "Ralf" == Ralf Wildenhues writes:
Ralf> If Automake were only started now, I think requiring GNU make
Ralf> would be a prudent design decision.
Yeah. Portability looked a lot more important back then. Nowadays I
think assuming GNU make is completely reasonable. You can probably even
dig
> "Bob" == Bob Friesenhahn writes:
Bob> You have got it exactly. Automake is not the only solution. There
Bob> are other solutions out there which require GNU make and are likely to
Bob> be more automatic as you prefer. One of those solutions (I forget the
Bob> name) is invented by the ori
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 th
> ">" == 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
> "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 particu
> "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 Makef
> "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
> "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
> "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
> "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
> "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
> "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
> "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
> "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> 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
> "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
> "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
> "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
> "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
> "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
> "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
> "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
> "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
> "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
> "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
> "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
> "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
>>>>> "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
> "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
> "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
> "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
> "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
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.
> "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
> "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
> "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
> "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
> "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>
> "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
> ">" == 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
> "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
> "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
> "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
> "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
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
> "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
> "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;
> "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
> "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
> "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
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
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
> "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'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
> "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.
[ 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> sp
> "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 env
> "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
i
>> AC_CONFIG_SUBDIRS(libghttp-1.0.9-mod)
Eric> Where does this go in the configure.in file? Above the AC_OUTPUT
Eric> command? From what I have read there has to be an order to the script,
Eric> so I want to make sure I put it in the right place
Anyplace before AC_OUTPUT is fine.
>> SUBDIRS = l
> "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
> "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
> "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 sp
> "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 direct
> "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).
> "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 '..
> "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 t
> "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
Harlan> I have the current software project almost building using 2.54
Harlan> and pre-1.7, ylwrap is not present and is not being missed.
I saw some email on the patch list about this too. ylwrap is only
needed if you have more than one yacc source file (or more than one
lex source file) in a g
> "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>> m
> "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 targe
> "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/
> "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>
> "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
> "Sean" == Sean MacLennan <[EMAIL PROTECTED]> writes:
Sean> Ok, I have done that. Now one last question. What is the "correct" way
Sean> to remove a directory when I do not want an error if the directory is
Sean> non-empty.
Sean> rmdir $(DESTDIR)$(rootdir)
If you want to ignore the err
> ">" == 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 appe
> "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
> "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
> "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: .
> "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 reall
> "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
> "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 th
> "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" == 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
1 - 100 of 1295 matches
Mail list logo
