work with plain Makefiles under an automake'ed directory tree
hi, in my automake-managed directory tree, there are some external sources which came with plain Makefiles. i want to ask you folks, when i type in a 'make' or 'make clean' at the top directory, how can i let the automake dive into those external source directories and run 'make ' and 'make clean' for them? -- woody then sun rose thinly from the sea and the old man could see the other boats, low on the water and well in toward the shore, spread out across the current.
help, automake generated a buggy Makefile?
hi, i wrote a simple sample program as well as a cpp-unit test, and then use automake in both cygwin and linux to generate `configure' and Makefile.in. it works well in these platforms, but has problem when do configure/make in MinGW's MSYS. It seems the Makeifle generated from `./configure' script is not fully correct for MinGW's MSYS though is okay for cygwin and Linux. i guess what makes differ is that in MinGW the executable should have .exe as extension name. below are full story. i started from a very simple Makefile.am TESTS = AllTests check_PROGRAMS = $(TESTS) AllTests_SOURCES = \ AllTests.cpp CXXFLAGS = `cppunit-config --cflags` -Wall LIBS = `cppunit-config --libs` and a simple configure.ac, AC_INIT( [ motconv ], [ 0.1 ], [ [EMAIL PROTECTED] ] ) AM_INIT_AUTOMAKE( [ -Wall -Werror foreign ] ) AC_PROG_RANLIB AC_PROG_CXX AC_PROG_INSTALL AC_LANG_PUSH([C++]) AC_CHECK_HEADERS([limits]) AC_LANG_POP AC_CONFIG_HEADER( configure.h ) AC_CONFIG_FILES( [ Makefile test/Makefile ]) AC_OUTPUT i did 'autoreconf -i' in Linux and let it produce a `configure' script. then what i did is to run the `configure' script under the MinGW's shell prompt, after that i do `make check', but got following outputs, Making check in test make[1]: Entering directory `d:/motconv/test' c:/MinGW/bin/make AllTests.exe make[2]: Entering directory `d:/motconv/test' if g++ -DHAVE_CONFIG_H -I. -I. -I.. `cppunit-config --cflags` -Wall -MT AllTests.o -MD -MP -MF ".deps/AllTests.Tpo" -c -o AllTests.o AllTests.cpp; \ then mv -f ".deps/AllTests.Tpo" ".deps/AllTests.Po"; else rm -f ".deps/AllTests.Tpo"; exit 1; fi g++ `cppunit-config --cflags` -Wall-o AllTests.exe AllTests.o `cppunit-config --libs` make[2]: Leaving directory `d:/motconv/test' c:/MinGW/bin/make check-TESTS make[2]: Entering directory `d:/motconv/test' g++ `cppunit-config --cflags` -Wall AllTests.cpp -o AllTests d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x181): undefined reference to `CppUnit::TextTestRunner::TextTestRunner(CppUnit::Outputter*)' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x1c5): undefined reference to `CppUnit::TestFactoryRegistry::getRegistry(std::string const&)' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x26e): undefined reference to `CppUnit::TestRunner::addTest(CppUnit::Test*)' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x279): undefined reference to `CppUnit::TextTestRunner::result() const' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x307): undefined reference to `CppUnit::CompilerOutputter::CompilerOutputter(CppUnit::TestResultCollector*, std::ostream&, std::string const&)' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x350): undefined reference to `CppUnit::TextTestRunner::setOutputter(CppUnit::Outputter*)' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x42e): undefined reference to `CppUnit::TextTestRunner::run(std::string, bool, bool, bool)' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x47d): undefined reference to `CppUnit::TextTestRunner::~TextTestRunner()' d:/_tmp/ccA7baaa.o:AllTests.cpp:(.text+0x56d): undefined reference to `CppUnit::TextTestRunner::~TextTestRunner()' collect2: ld returned 1 exit status make[2]: *** [AllTests] Error 1 make[2]: Leaving directory `d:/motconv/test' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `d:/motconv/test' make: *** [check-recursive] Error 1 the problem is in line, g++ `cppunit-config --cflags` -Wall AllTests.cpp -o AllTests it forgot to append `cppunit-config --libs' which is what i assigment to the LIBS variable. and, i believe it actually should not do any compile or link when do `make check-TESTS' because the AllTests.exe has already generated, i guess the Makefile try to find AllTests but dont know that AllTests.exe is actually AllTests. On another hand, you might noticed that the Makefile can generate AllTests.exe correctly when it do seperated compile/link stages: c:/MinGW/bin/make AllTests.exe make[2]: Entering directory `d:/motconv/test' if g++ -DHAVE_CONFIG_H -I. -I. -I.. `cppunit-config --cflags` -Wall -MT AllTests.o -MD -MP -MF ".deps/AllTests.Tpo" -c -o AllTests.o AllTests.cpp; \ then mv -f ".deps/AllTests.Tpo" ".deps/AllTests.Po"; else rm -f ".deps/AllTests.Tpo"; exit 1; fi g++ `cppunit-config --cflags` -Wall-o AllTests.exe AllTests.o `cppunit-config --libs` i hope you experts get know what i mean. thanks in advance! ** my automake version is 1.10 ** -- woody then sun rose thinly from the sea and the old man could see the other boats, low on the water and well in toward the shore, spread out across the current.
Re: help, automake generated a buggy Makefile?
On 10/15/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Steven,
>
> * Steven Woody wrote on Sun, Oct 14, 2007 at 05:51:45AM CEST:
> >
> > AC_INIT( [ motconv ], [ 0.1 ], [ [EMAIL PROTECTED] ] )
> > AM_INIT_AUTOMAKE( [ -Wall -Werror foreign ] )
> > AC_PROG_RANLIB
> > AC_PROG_CXX
> > AC_PROG_INSTALL
> > AC_LANG_PUSH([C++])
> > AC_CHECK_HEADERS([limits])
> > AC_LANG_POP
> > AC_CONFIG_HEADER( configure.h )
> > AC_CONFIG_FILES( [ Makefile test/Makefile ])
> > AC_OUTPUT
>
> Please drop all the trailing white space, it makes a difference. That
> is, you should write at most
> AC_INIT([motconv], [0.1], [EMAIL PROTECTED])
>
> because right now, the name of your package is " motconv " with version
> " 0.1 ", and so on, and that will lead to subtle issues later. They
> don't have to do with the issue you reported, though.
>
> For that, I can only test it myself later. For now, please post the
> output of "grep -C2 TESTS Makefile.in" of the Makefile.in from which
> AllTests.exe is built, thanks.
>
> Cheers,
> Ralf
>
thanks. below are output of grep -C2 TESTS on Makefile.in,
~/motconv/trunk/test$ grep -C2 TESTS Makefile.in
sysconfdir = @sysconfdir@
target_alias = @target_alias@
TESTS = AllTests
AllTests_SOURCES = \
AllTests.cpp
--
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
check-TESTS: $(TESTS)
@failed=0; all=0; xfail=0; xpass=0; skip=0; \
srcdir=$(srcdir); export srcdir; \
list='$(TESTS)'; \
if test -n "$$list"; then \
for tst in $$list; do \
--
elif test -f $$tst; then dir=; \
else dir="$(srcdir)/"; fi; \
if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
all=`expr $$all + 1`; \
case " $(XFAIL_TESTS) " in \
*" $$tst "*) \
xpass=`expr $$xpass + 1`; \
--
elif test $$? -ne 77; then \
all=`expr $$all + 1`; \
case " $(XFAIL_TESTS) " in \
*" $$tst "*) \
xfail=`expr $$xfail + 1`; \
--
check-am: all-am
$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
$(MAKE) $(AM_MAKEFLAGS) check-TESTS
check: check-am
all-am: Makefile
--
uninstall-am: uninstall-info-am
.PHONY: CTAGS GTAGS all all-am check check-TESTS check-am clean \
clean-checkPROGRAMS clean-generic ctags distclean \
distclean-compile distclean-generic distclean-local \
Re: help, automake generated a buggy Makefile?
On 10/15/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Steven Woody wrote on Mon, Oct 15, 2007 at 10:16:20AM CEST: > > > > ~/motconv/trunk/test$ grep -C2 TESTS Makefile.in > > sysconfdir = @sysconfdir@ > > target_alias = @target_alias@ > > TESTS = AllTests > > This looks like this file has been generated with Automake 1.9 rather > than 1.10. Please check the comment at the top of the file, and if > that's the case, please run > aclocal-1.10 && automake-1.10 && autoconf > > and retest. > > Thanks, > Ralf > because this is my office computer, not the home computer for which i have upgraded to 1.10. i will redo the procedure server hours later when go back home and repost here. thank you very much.
Re: help, automake generated a buggy Makefile?
On 10/15/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Steven Woody wrote on Mon, Oct 15, 2007 at 10:16:20AM CEST: > > > > ~/motconv/trunk/test$ grep -C2 TESTS Makefile.in > > sysconfdir = @sysconfdir@ > > target_alias = @target_alias@ > > TESTS = AllTests > > This looks like this file has been generated with Automake 1.9 rather > than 1.10. Please check the comment at the top of the file, and if > that's the case, please run > aclocal-1.10 && automake-1.10 && autoconf > > and retest. > > Thanks, > Ralf > Dear Ralf, after removed extra spaces in configure.ac and re-executed automake 1.10 in an explicitly way as you mentioned above, every thing run well and the gcc error have disapeared! thanks for you help! but i still dont understand, why when i typed `automake', it actually run 1.9.6 rather than the most recent version of 1.10. should i delete all old version of autoexec/aclocal in my system? - woody -- woody then sun rose thinly from the sea and the old man could see the other boats, low on the water and well in toward the shore, spread out across the current.
Re: help, automake generated a buggy Makefile?
On 10/16/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Steven, > > * Steven Woody wrote on Mon, Oct 15, 2007 at 05:45:57PM CEST: > > On 10/15/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > > > > This looks like this file has been generated with Automake 1.9 rather > > > than 1.10. Please check the comment at the top of the file, and if > > > that's the case, please run > > > aclocal-1.10 && automake-1.10 && autoconf > > > > after removed extra spaces in configure.ac and re-executed automake > > 1.10 in an explicitly way as you mentioned above, every thing run > > well and the gcc error have disapeared! thanks for you help! > > Good. > > > but i still dont understand, why when i typed `automake', it actually > > run 1.9.6 rather than the most recent version of 1.10. should i > > delete all old version of autoexec/aclocal in my system? > > Well, each Automake version installs the program under both names > `automake' and `automake-MAJOR.MINOR'. If you have installed 1.9.x > after you installed 1.10, or if you have installed them in different > prefixes, and the 1.9.x one happens to be found earlier in $PATH, then > that one will be used when you type `automake'. Similar for aclocal. > > That said, you need not delete old Automake installations. Rather, > either adjust $PATH, or reinstall 1.10. > > Cheers, > Ralf > thanks a lot! -- woody then sun rose thinly from the sea and the old man could see the other boats, low on the water and well in toward the shore, spread out across the current.
A global _CFLAGS assigment?
Hi, My project tree have many Makefile.am in a recursive directory tree and I want every Makefile.am has a line some thing like xxx_CFLAGS = -Wall. What's the way to do that? You see, there are many different xxx_ in different Makefile.am. Thanks. - narke
How to define a `prefix' other than the default vaule?
Hi, I want all my stuff by default installed in /usr/local/mypkg unless user specified another 'preflex' value when run 'configure' script. How can I? Thank you. - narke
Re: A global _CFLAGS assigment?
On Sat, Jun 7, 2008 at 12:22 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Steven, > > * Steven Woody wrote on Fri, Jun 06, 2008 at 06:17:30PM CEST: >> >> My project tree have many Makefile.am in a recursive directory tree >> and I want every Makefile.am has a line some thing like xxx_CFLAGS = >> -Wall. What's the way to do that? You see, there are many different >> xxx_ in different Makefile.am. > > I don't quite understand, but you're either looking for > AM_CFLAGS = ... But I have to insert this line in every Makefile.am in the tree, right? That's I dont want. But your below solution using AC_SUBST looks making sense. > > (you can also AC_SUBST([AM_CFLAGS], [...]) from within configure.ac) > or for putting a bunch of 'include $(top_srcdir)/.../fragment.am' into > all the Makefile.am files to have some common code. > > Hope that helps. The big problem may be, the AM_CFLAGS will disappear if in a Makefile.am, there is a _CFLAGS.
Re: How to define a `prefix' other than the default vaule?
On Sat, Jun 7, 2008 at 12:30 AM, John Calcote <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Steven Woody wrote: >> Hi, >> >> I want all my stuff by default installed in /usr/local/mypkg unless >> user specified another 'preflex' value when run 'configure' script. >> How can I? Thank you. > > > Try AC_PREFIX_DEFAULT([/usr/local/mypkg]) in your configure.ac file. > Thank you!
Re: A global _CFLAGS assigment?
On Sat, Jun 7, 2008 at 1:23 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Steven Woody wrote on Fri, Jun 06, 2008 at 06:44:46PM CEST: >> On Sat, Jun 7, 2008 at 12:22 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> > >> > (you can also AC_SUBST([AM_CFLAGS], [...]) from within configure.ac) > >> The big problem may be, the AM_CFLAGS will disappear if in a >> Makefile.am, there is a _CFLAGS. > > _CFLAGS = $(AM_CFLAGS) -additional-flags ... > Cool! It works, Thank you! Before received your post, I tried _CFLAGS = @AM_CFLAGS@ -additional-flags ... but failed, but _CFLAGS = @CXXFLAGS@ -additional-flags ... will passed the make though this is not what I want. I just wonder why @CXXFLAGS@ is okay while @AM_CFLAGS@ not
Why I can not overwrite CXXFLAGS values?
In my system, the default CXXFLAGS is '-g -O2'. But, for a particular program, I need -O0 and without -g. I tried something like: bin_PROGRAS = xxx xxx_CXXFLAGS = -O0 in Makefile.am. But, the final CXXFLAGS used when I compile is actually -O0 -g -O2, the default CXXFLAGS appended to my xxx_CXXFLAGS. What should I do? Thanks in advance. - narke
How can I change shared library's version number?
When I use autoconf/automake with its integrated libtool to build a shared library, I got shared libraray named 'libfoo.so.0.0.0'. I don't sure where the 0.0.0 comes from, and I don't like it. How can I change it? I searched info page but found no answer. Thanks in advance. - narke
Re: Why I can not overwrite CXXFLAGS values?
On Sat, Jun 7, 2008 at 3:38 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Steven, > > * Steven Woody wrote on Fri, Jun 06, 2008 at 08:54:59PM CEST: >> In my system, the default CXXFLAGS is '-g -O2'. But, for a particular >> program, I need -O0 and without -g. I tried something like: >> bin_PROGRAS = xxx >> xxx_CXXFLAGS = -O0 >> in Makefile.am. But, the final CXXFLAGS used when I compile is >> actually -O0 -g -O2, the default CXXFLAGS appended to my xxx_CXXFLAGS. > > Note that is exactly done because CXXFLAGS is for the user, not the > developer. If you try to outsmart the user, then that may fire back > because your users may just know better what's good for their system. > Yes, they really may. > Thank you. > That said, you can > CXXFLAGS = > AM_CXXFLAGS = $(CXXFLAGS) > xxx_CXXFLAGS = -O0 Set AM_ and xxx_ both? Manual said, only one of them will be used. > > and you probably want `AUTOMAKE_OPTIONS = -Wno-override' in that > Makefile.am. > > Alternatively, you can modify $CXXFLAGS within configure.ac; find out > whether CXXFLAGS was set by the user _before_ AC_PROG_CXX, and if it > wasn't, you can default it to your liking. How? Thanks.
Re: A global _CFLAGS assigment?
On Sat, Jun 7, 2008 at 3:46 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Steven Woody wrote on Fri, Jun 06, 2008 at 08:34:05PM CEST: >> Before received your post, I tried >> _CFLAGS = @AM_CFLAGS@ -additional-flags ... >> but failed, but >> _CFLAGS = @CXXFLAGS@ -additional-flags ... > > (Is that mixup of C and C++-specific flag names a typo in your mail?) > >> will passed the make though this is not what I want. I just wonder >> why @CXXFLAGS@ is okay while @AM_CFLAGS@ not > > Both are ok, iff the corresponding variable is AC_SUBSTed from > configure.ac. CFLAGS and CXXFLAGS are AC_SUBSTed by default, with > AM_CFLAGS and AM_CXXFLAGS you would have to do it manually. > Understood. Thank you!
How to install shell script?
Hi, I use "sysconf_DATA= etc/net.up etc/net.down" in my Makefile.am and expect that when I run 'make install' then those shell scripts (net.up, net.down) can be installed in PREFIX/etc . It really work, just except that these scripts are not chmod to executable. How do I make it happen? Thanks. - woody
Re: How to install shell script?
On Mon, Jun 30, 2008 at 4:39 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote: > sysconf_SCRIPTS > Hi, If I do that, 'automake' will fail and report: Makefile.am:10: `sysconfdir' is not a legitimate directory for `SCRIPTS' Did you miss somthing?
Re: How to install shell script?
On Mon, Jun 30, 2008 at 7:15 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote: >> On Mon, Jun 30, 2008 at 4:39 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote: >> > sysconf_SCRIPTS >> > >> >> Hi, >> >> If I do that, 'automake' will fail and report: >> >> Makefile.am:10: `sysconfdir' is not a legitimate directory for `SCRIPTS' >> >> Did you miss somthing? > > Yes. > > So you will need to create a new target: > > foodir=$prefix/etc > > foo_SCRIPTS= ... > > I could be making another mistake here, but it's also documented. > I works, thank you!
Where to do post installation?
Hi, After 'make install', I want to do some post-install things such as creating some directories, run a script etc. What is valid method in Makefile.am to do this? Thank you.
Re: Where to do post installation?
On Mon, Jul 7, 2008 at 1:32 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Steven, > > * Steven Woody wrote on Mon, Jul 07, 2008 at 07:20:44AM CEST: >> >> After 'make install', I want to do some post-install things such as >> creating some directories, run a script etc. What is valid method in >> Makefile.am to do this? Thank you. > > Write rules for install-exec-hook and/or install-data-hook. > > Cheers, > Ralf > Thank you, understood. But, when I copy samples from automake manual and do the following: install-data-hook: mkdir -p $(DESTDIR)/var/run and I expect that var/run will be created under my $PREFIX. The result is not, the var/run was created under my current working directory. See the following 'make install' outputs: make[3]: Entering directory `/home/woody/lmt/trunk' mkdir -p var/run Here, /home/woody/lmt/trunk is my working directory, not my $PREFIX. Did I missed something? Thanks.
Re: Where to do post installation?
On Mon, Jul 7, 2008 at 3:17 PM, Steven Woody <[EMAIL PROTECTED]> wrote: > On Mon, Jul 7, 2008 at 1:32 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> Hello Steven, >> >> * Steven Woody wrote on Mon, Jul 07, 2008 at 07:20:44AM CEST: >>> >>> After 'make install', I want to do some post-install things such as >>> creating some directories, run a script etc. What is valid method in >>> Makefile.am to do this? Thank you. >> >> Write rules for install-exec-hook and/or install-data-hook. >> >> Cheers, >> Ralf >> > > Thank you, understood. But, when I copy samples from automake manual > and do the following: > > install-data-hook: >mkdir -p $(DESTDIR)/var/run > > and I expect that var/run will be created under my $PREFIX. The > result is not, the var/run was created under my current working > directory. See the following 'make install' outputs: > > > make[3]: Entering directory `/home/woody/lmt/trunk' > mkdir -p var/run > > > Here, /home/woody/lmt/trunk is my working directory, not my $PREFIX. > > Did I missed something? Thanks. > any idea?
Re: Where to do post installation?
On Tue, Jul 8, 2008 at 2:00 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Ralf Wildenhues wrote on Mon, Jul 07, 2008 at 07:58:01PM CEST: >> You'll want to use something like >> >> install-data-hook: >> mkdir -p $(DESTDIR)$(localstatedir)/run > > Erm, for portability, either $(mkdir_p) (Automake >= 1.10) or > $(mkinstalldirs) (for compatibility with older Automake) instead of > 'mkdir -p'. > > Sorry 'bout that. > Thank you Ralf
Warn: non-POSIX variable name
Hi, How do I remove these warnings when do automake: src/rmeterd/Makefile.am:9: shell ../../svndate-sh: non-POSIX variable name src/rmeterd/Makefile.am:9: (probably a GNU make extension) in the Makefile.am, I did something like this: rmeterd_CXXFLAGS = \ -D'SVN_REV="$(shell ../../svnrev-sh)"' \ -D'SVN_DATE="$(shell ../../svndate-sh)"' That is, I call a external shell script to get values that will be set to a -D definition. What's the correct way to do this without warning? Thanks.
Re: Warn: non-POSIX variable name
On Tue, Aug 19, 2008 at 10:51 AM, Brian Dessent <[EMAIL PROTECTED]> wrote: > Steven Woody wrote: > >> How do I remove these warnings when do automake: >> >> src/rmeterd/Makefile.am:9: shell ../../svndate-sh: non-POSIX variable >> name >> src/rmeterd/Makefile.am:9: (probably a GNU make extension) >> >> in the Makefile.am, I did something like this: >> >> rmeterd_CXXFLAGS = \ >> -D'SVN_REV="$(shell ../../svnrev-sh)"' \ >> -D'SVN_DATE="$(shell ../../svndate-sh)"' >> >> That is, I call a external shell script to get values that will be set >> to a -D definition. >> >> What's the correct way to do this without warning? Thanks. > > Are you asking how to do this in a way that's not GNU make specific, or > are you asking how to make automake not warn about it? For the latter, > add -Wno-portability to your automake options (globally in > AM_INIT_AUTOMAKE or per-Makefile in AUTOMAKE_OPTIONS.) For the former, > run the script at configure-time rather than at make-time and AC_SUBST > the resulting value. > > Brian > Thank you. Adding -Wno-portablility to AM_INIT_AUTOMAKE works. But I don't understand your other words: "For the former, run the script at configure-time rather than at make-time and AC_SUBST the resulting value."
Re: Warn: non-POSIX variable name
On Tue, Aug 19, 2008 at 3:43 PM, Brian Dessent <[EMAIL PROTECTED]> wrote: > Steven Woody wrote: > >> Thank you. Adding -Wno-portablility to AM_INIT_AUTOMAKE works. But I >> don't understand your other words: "For the former, >> run the script at configure-time rather than at make-time and AC_SUBST >> the resulting value." > > I mean adding something like the following to configure.ac: > > SVN_REV=`$top_srcdir/svnrev-sh` > SVN_DATE=`$top_srcdir/svndate-sh` > AC_SUBST([SVN_REV]) > AC_SUBST([SVN_DATE]) > > And then in your Makefile.am: > > rmeterd_CXXFLAGS = -DSVN_REV='@SVN_REV@' -DSVN_DATE='@SVN_DATE@' > > (That should most likely be CPPFLAGS not CXXFLAGS but that wasn't the > question.) > > The difference with this method is that the values are computed once > when configure is run, and then substituted into the Makefile when it is > generated after configure has completed. When you use $(shell ...) the > value is not computed until you run make, and the result is not stored > anywhere so it is recomputed each time that make is run. > > The main advantage of doing it this way is that it's portable to systems > without GNU make, since $(shell) is a feature of GNU make -- that is > what the automake warning is telling you. A second advantage is that > since the values are substituted into the generated Makefile, there is > no delay waiting for the scripts to execute each time you run make. > Whether this matters depends on how expensive the operations are, but > with very large trees some version control operations can take a lot of > time so it's generally a good idea to not have to run them over and over > again. On the other hand this also means that the stored version > information will not reflect the outcome of e.g. "svn up" as it will > only change after the package is reconfigured. However if most of your > configure tests are properly designed to support caching (and you enable > caching, e.g. configure -C) then "./config.status --recheck" ought to be > a fairly fast operation that you can run after performing a version > control operation in order to get the new revision information in the > generated Makefile. Thanks for the explaination, it improves my knowledge in automake. But, for the case, I wish the version information as updated as possible since team member may forget to run "./config.status --recheck", this will leave generated programs with a wrong version info. Thank you anyway.
Re: Warn: non-POSIX variable name
> Hi Steven, > > If I remember correctly a changed value in "-D flag" will not cause > re-compilation, so if it is important that the version information > propagates to your binary, it is likely better to generate a header file or > even a source file than using these CPPFLAGS. I'm doing that in one of my > projects in which the makefile.am looks something like this > > if HAVE_SVN_WC > @srcdir@/subversion_info.cc: subversion_info.cc.tmp > @$(SHELL) @top_srcdir@/build_support/move-if-change subversion_info.cc.tmp > \ > @srcdir@/subversion_info.cc > > subversion_info.cc.tmp: FORCE > @echo '// subversion_info.cc generated from subversion_info.cc.in.' > $@ > ;\ > revision=`svnversion $(top_srcdir)` ;\ > $(SED) -e 's/sub_2_svn_revision/'$$revision'/g' \ > @srcdir@/subversion_info.cc.in >> $@ ; > endif > > FORCE: > > Then I have a subversion_info.cc.in that have a string sub_2_svn_revision > where the revision is intended to be. So when I need `subversion_info.cc', a > `subversion_info.cc.tmp' is created from the `subversion_info.cc.in' using > the handy script, svnversion, provided by the svn team. Then the script > move-if-change replaces `subversion_info.cc' with `subversion_info.cc.tmp' > (like mv subversion_info_cc.tmp subversion_info.cc) but it does so only if > the two files are different. I introduced that "if" in order to avoid > re-compilation of subversion_info.o when not needed. > > Another thing is that if you plan on distributing your package, you have to > make sure that it works also when not building from a subversion working > copy. Either by adding this case in your script `svnrev-sh' or by checking > it at configure time and add automake conditionals (like I do with > HAVE_SVN_WC). In any case you probably need to add created source code > `subversion_info.cc' to your distribution. I used `make distcheck' to help > me get the details right. > > I am not sure exactly what you wanna do, but I hope this will help. > Thank you Peter. I have two more questions: 1, Where and how you set the HAVE_SVN_WC? 2. What's the difference between @varname@ and $(varname) in a Makefile.am? I noted you use many @@ Regards, woody
Re: Warn: non-POSIX variable name
Thanks! On Thu, Aug 21, 2008 at 1:42 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Peter Johansson wrote on Wed, Aug 20, 2008 at 05:23:10AM CEST: >> Steven Woody wrote: >>> 2. What's the difference between @varname@ and $(varname) in a >>> Makefile.am? I noted you use many @@ >>> >> I think the difference is that for example @builddir@ is substituted to >> '.' when the Makefile is created from Makefile.in, so for instance: > [...] > > Correct. > >> but since $(builddir) is set to `.', I dont think it matters if having >> @xxx@ or $(xxx) in this case. > > It doesn't matter for the contents of this rule, as 'make' sees it. > However, in general, @substitutions@ cannot be interpreted by automake, > while $(macros) typically can. Most of the time you want automake to > see as much of it as possible, so as a guide line, prefer $(macros) in > Makefile.am. > > Cheers, > Ralf >
Cross-compile tar-1.13
Hi, For some reasons I need to cross-compile a tar-1.13, the target is ARM and the build host is i686-pc-linux-gnu. The tar-1.13's source come with a configure, that seems generated from a very old version of automake. For recent automake version, I have success experience to do cross-compiling, that is, specify a '--host=arm-linux' when running the 'configure' script. But for the tar-1.13's configure script, I failed to do it. I tried the following method: 1, configure --host=arm-linux 2, configure --target=arm-linux 3, configure --host=arm-linux --build=i686-pc-linux-gnu but all failed: the 'configure' script did not try to find arm-linux-gcc, it still using gcc as compiler. So I think, I did not active the cross-compiling in the script. Do you know what should I do? Thanks. - woody
Re: Cross-compile tar-1.13
On Sun, Aug 31, 2008 at 11:21 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Steven, > > * Steven Woody wrote on Sat, Aug 30, 2008 at 05:10:06PM CEST: >> >> For some reasons I need to cross-compile a tar-1.13, the target is ARM >> and the build host is i686-pc-linux-gnu. The tar-1.13's source come >> with a configure, that seems generated from a very old version of >> automake. For recent automake version, I have success experience to >> do cross-compiling, that is, specify a '--host=arm-linux' when running >> the 'configure' script. But for the tar-1.13's configure script, I >> failed to do it. I tried the following method: >> >> 1, configure --host=arm-linux >> 2, configure --target=arm-linux >> 3, configure --host=arm-linux --build=i686-pc-linux-gnu >> >> but all failed: the 'configure' script did not try to find >> arm-linux-gcc, it still using gcc as compiler. So I think, I did not >> active the cross-compiling in the script. > > You did not mention which Autoconf version this tar's configure script > was created with. It should be mentioned near the head of the script > somewhere. > > Please try > ./configure arm-linux > > which was IIRC the way to do it with Autoconf 2.13. > Yes, it is 2.13 automake, I found the information in the comments of 'configure' script itself. But what you told './configure arm-linux' did not work neither ( it still use gcc instead of arm-linux-gcc). I attached the output for you information, please help if possible. Thanks in advance. - woody config.log Description: Binary data
Re: Cross-compile tar-1.13
On Tue, Sep 2, 2008 at 2:35 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Steven, > > * Steven Woody wrote on Sun, Aug 31, 2008 at 09:50:26AM CEST: >> On Sun, Aug 31, 2008 at 11:21 AM, Ralf Wildenhues wrote: >> >> >> > Please try >> > ./configure arm-linux >> > >> > which was IIRC the way to do it with Autoconf 2.13. >> > >> >> Yes, it is 2.13 automake, I found the information in the comments of >> 'configure' script itself. But what you told './configure arm-linux' >> did not work neither ( it still use gcc instead of arm-linux-gcc). I >> attached the output for you information, please help if possible. > > Erm, have you tried > CC=arm-linux-gcc ./configure > > yet? > > Cheers, > Ralf > Ralf, If I did that, I will get: loading cache ./config.cache checking host system type... ./config.guess: line 735: ./dummy-3089: cannot execute binary file ./config.guess: line 999: ./dummy-3089: cannot execute binary file configure: error: can not guess host type; you must specify one
Re: Cross-compile tar-1.13
On Sun, Sep 7, 2008 at 2:11 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Steven Woody wrote on Sun, Sep 07, 2008 at 07:53:43AM CEST: >> On Tue, Sep 2, 2008 at 2:35 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> > Erm, have you tried >> > CC=arm-linux-gcc ./configure >> > >> > yet? > >> If I did that, I will get: >> >> loading cache ./config.cache >> checking host system type... ./config.guess: line 735: ./dummy-3089: >> cannot execute binary file >> ./config.guess: line 999: ./dummy-3089: cannot execute binary file >> configure: error: can not guess host type; you must specify one > > And what about specifying both? > CC=arm-linux-gcc ./configure arm-linux > This works! Thank you very much!
configure can not determin 'HAVE_LIMITS'
i am using autoconf/automake in my currenty project. the project also use a third-party library which comes with a header file which i should include in my own sources. but in the header file, there is something like below: #ifdef HAVE_LIMITS #include #else #include #endif so, my code including the header will never pass compile becase HAVE_LIMITS was not set by the ./configure, hence the header will ask the which however does not exist on my system. does anyone know what's the cause and gets a solution? -- steven woody (id: narke) Can two friends sleep together and still love each other in the morning? - When Harry Met Sally... (1989)
Re: configure can not determin 'HAVE_LIMITS'
Stepan Kasal <[EMAIL PROTECTED]> writes: > Hello, > > On Tue, Oct 25, 2005 at 10:23:55PM +0800, Steven Woody wrote: >> #ifdef HAVE_LIMITS > > add line > > AC_CHECK_HEADERS([limits]) > > to configure.ac (or configure.in). > > HTH, > Stepan Kasal thanks. but still got problem. if i say, AC_CHECK_HEADERS([limits]) as you pointed, the the configure script will complain and the HAVE_LIMITS veriable would't be set because my system (Linux) only get limits.h instead of 'limits'. so to make 'configure' happy, i changed to AC_CHECK_HEADERS([limits.h]), this time, 'configure' feels happy and HAVE_LIMITS_H is set properly. but the third-party headers used in my project requires a HAVE_LIMITS that is still not set. my current solution is add the below line into 'config.h.in': #define HAVE_LIMITS 1 but i think this is not a decent way. any thinking? -- steven woody (id: narke) Can two friends sleep together and still love each other in the morning? - When Harry Met Sally... (1989)
Re: configure can not determin 'HAVE_LIMITS'
Andreas Schwab <[EMAIL PROTECTED]> writes: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > >> limits.h is a POSIX header. On linux it is supplied by GCC. >> >> So if you want to check for "limits", you should use >> AC_CHECK_HEADERS([limits]) >> >> If this fails, something else is broken and you will have to >> investigate. It could be a bug inside of "limits", it could be problem >> elsewhere inside of your configure script, or could be a problem with >> your include paths. > > Note that is a C++ header. By default, configure scripts don't > use the C++ compiler when checking for headers. > so ... what?
Re: configure can not determin 'HAVE_LIMITS'
Ralf Corsepius <[EMAIL PROTECTED]> writes: > On Wed, 2005-10-26 at 21:52 +0800, Steven Woody wrote: >> Stepan Kasal <[EMAIL PROTECTED]> writes: >> >> > Hello, >> > >> > On Tue, Oct 25, 2005 at 10:23:55PM +0800, Steven Woody wrote: >> >> #ifdef HAVE_LIMITS >> > >> > add line >> > >> > AC_CHECK_HEADERS([limits]) >> > >> > to configure.ac (or configure.in). >> > >> > HTH, >> >Stepan Kasal >> >> thanks. but still got problem. if i say, AC_CHECK_HEADERS([limits]) as you >> pointed, the the configure script will complain and the HAVE_LIMITS veriable >> would't be set because my system (Linux) only get limits.h instead of >> 'limits'. >> >> so to make 'configure' happy, i changed to AC_CHECK_HEADERS([limits.h]), this >> time, 'configure' feels happy and HAVE_LIMITS_H is set properly. but the >> third-party headers used in my project requires a HAVE_LIMITS that is still >> not >> set. >> >> my current solution is add the below line into 'config.h.in': >> >> #define HAVE_LIMITS 1 >> >> but i think this is not a decent way. any thinking? > > You seem to be confused and are outsmarting yourself ;) > > limits.h is a POSIX header. On linux it is supplied by GCC. > > So if you want to check for "limits", you should use > AC_CHECK_HEADERS([limits]) > but could you explain why AC_CHECK_HEADERS([limits]) failed but AC_CHECK_HEADERS([limits.h]) success? > If this fails, something else is broken and you will have to > investigate. It could be a bug inside of "limits", it could be problem > elsewhere inside of your configure script, or could be a problem with > your include paths. >
Re: configure can not determin 'HAVE_LIMITS'
Ralf Corsepius <[EMAIL PROTECTED]> writes: > > To check for C++-headers you normally have to tell the configure script > to switch languages/compilers. > > Example: > # This uses the c-compiler > AC_CHECK_HEADERS([limits.h]) > > # This uses the c++-compiler > AC_LANG_PUSH([C++]) > AC_CHECK_HEADERS([limits]) > AC_LANG_POP > > Ralf > thanks! it now okay!
add '-pg' to compiler/linker
i have a main.cpp in top directory and some modules in sub-directories. each module compiled as a .a library and the main.cpp staticly linked with those .a's. it work no problem for compile/link. but, now i want to add gprof capability to the resulting executable. so i add '-pg' to _CXXFLAGS for each modules's Makefile.am as well as to the main program's Makefile.am. automake reported no error and produced an executable. but after i run the executable, there is no .out profile generated. so i think '-pg' flag has not take effect. what's wroing with my steps? thanks for your help. -- steven woody (id: narke) Virginia Woolf: You cannot find peace by avoiding life, Leonard. - The Hours (2002)
Re: add '-pg' to compiler/linker
Ralf Wildenhues <[EMAIL PROTECTED]> writes: thank you Ralf. you solved the problem! > Hi Steven, > > * Steven Woody wrote on Thu, Nov 10, 2005 at 06:56:52PM CET: >> i have a main.cpp in top directory and some modules in sub-directories. each >> module compiled as a .a library and the main.cpp staticly linked with those >> .a's. it work no problem for compile/link. >> >> but, now i want to add gprof capability to the resulting executable. so i add >> '-pg' to _CXXFLAGS for each modules's Makefile.am as well as to the main >> program's Makefile.am. automake reported no error and produced an >> executable. but after i run the executable, there is no .out profile >> generated. so i think '-pg' flag has not take effect. > > Hmm. You should not have to modify any files at all for this. > > Just, in a new build directory, do > > ../source/configure CXXFLAGS=-pg > make > > and you should be set. If you use more than one language, you may want > to add CFLAGS=-pg as well. > > If that still doesn't work, maybe you should show a couple of compiler > commands executed by make. > > Hmm, do you use libtool perchance? Then, you might > make LDFLAGS=-Wc,-pg > (this will be fixed in Libtool-1.5.22). > > Cheers, > Ralf > > > -- steven woody (id: narke) Virginia Woolf: Someone has to die Leonard, in order that the rest of us should value our life more. - The Hours (2002)
How to write a Makefile letting 'ld' print a link map?
the 'ld' has an option letting me print a link map, but this option need an file name as argument. so i can not simply specify a LDFLAGS since that is different map file name for each object or executable. What do i do? thanks. -- steven woody (id: narke)
Re: How to write a Makefile letting 'ld' print a link map?
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hi Steven, > > * Steven Woody wrote on Tue, Nov 15, 2005 at 02:23:50PM CET: >> >> the 'ld' has an option letting me print a link map, but this option need an >> file name as argument. so i can not simply specify a LDFLAGS since that is >> different map file name for each object or executable. What do i do? thanks. > > Use per-target flags: > > bin_PROGRAMS = foo bar > foo_LDFLAGS = -some -flags > bar_LDFLAGS = -some -other -flags > > Cheers, > Ralf > thanks! -- steven woody (id: narke) Jesse: You want to know why I wrote that stupid book? Celine: Why? Jesse: So that you might come to a reading in Paris and I could walk up to you and ask, "Where the fuck were you?" Celine: [laughing] No - you thought I'd be here today? Jesse: I'm serious. I think I wrote it, in a way, to try to find you. Celine: Okay, that's - I know that's not true, but that's sweet of you to say. Jesse: I think it is true. - Before Sunset (2004)
How to make a 'pthread' program ?
on linux, simplly adding a '-pthread' option to the command line gcc, i can make a multi-thread c program. but if using automake, i only got many undefined reference to pthread_xxx errors. i've already add the '-pthread' to the myprogram_CFLAGS variable. can anyone help me? thanks. -- steven woody (id: narke) Celine: Each time I wear black, or like, lose my temper, or say anything about anything, you know, they always go, "Oh it's so French. It's so cute." Ugh! I hate that! - Before Sunrise (1995)
Re: How to make a 'pthread' program ?
On 1/3/06, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Tue, 3 Jan 2006, Steven Woody wrote: > > > on linux, simplly adding a '-pthread' option to the command line gcc, i can > > make a multi-thread c program. but if using automake, i only got many > > undefined reference to pthread_xxx errors. i've already add the '-pthread' > > to the myprogram_CFLAGS variable. > > The '-pthread' option is a non-standard compiler extension which > causes different pre-processor definitions to be applied, and > different/additional libraries to be applied. You should not assume > that other compilers/platforms work with '-pthread'. So if you insert > it into myprogram_CFLAGS then your package will only work if the > compiler supports the '-pthread' option. > > Note that CFLAGS is only applied when compiling. The LDFLAGS value is > used while linking so if you want to use '-pthread' then you should > supply it for both CFLAGS and LDFLAGS. > > The Autoconf macro archive includes a macro for determining the > correct options to use in a platform-independent way. thanks, the LDFLAGS works. and i also interest in what the determining macro you mentioned is and how i should use it. > > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > -- woody
-pthread in Linux and CygWin
i have a project which need to be build both on linux and cygwin. i have to set the LDFLAGS = -pthread in linux but it leads an error in cygwin. can automake help me? i inserted the LDFLAGS line in Makefile.am. thanks. -- woody then sun rose thinly from the sea and the old man could see the other boats, low on the water and well in toward the shore, spread out across the current.
Re: -pthread in Linux and CygWin
On 9/20/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: Hello Steven, * steven woody wrote on Wed, Sep 20, 2006 at 08:42:28AM CEST: > i have a project which need to be build both on linux and cygwin. i > have to set the LDFLAGS = -pthread in linux but it leads an error in > cygwin. can automake help me? i inserted the LDFLAGS line in > Makefile.am. Well. What are the requirements for your package? Does it need POSIX threads? Does it need some kind of thread support, and copes with the different kinds that exist? yes, i need to use thread, that's why i need the -pthread option. For the simplest part, throw out the LDFLAGS setting in Makefile.am (if anything you should be setting AM_LDFLAGS; LDFLAGS is reserved for the user). Then have the user on GNU/Linux do ./configure LDFLAGS=-pthread glad to know the method, i will try it! thank you very much. and on Cygwin ./configure Depending on what your project copes with, you may want to take a look at the ACX_PTHREAD macro in the Autoconf Macro Archive: http://autoconf-archive.cryp.to/acx_pthread.html Hope that helps. Cheers, Ralf -- woody then sun rose thinly from the sea and the old man could see the other boats, low on the water and well in toward the shore, spread out across the current.
