Re: Automake 1.16 build failure
On Feb 27 2018, Mathieu Lirzin wrote: > What is the Perl version used? 5.18.2 > Can you open a bug report on for this issue? Done. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Automake 1.16 build failure
$ make -j4 GEN bin/automake GEN bin/aclocal GEN t/ax/shell-no-trail-bslash GEN t/ax/cc-no-c-o GEN runtest GEN doc/aclocal.1 GEN doc/automake.1 GEN lib/Automake/Config.pm GEN t/ax/test-defs.sh GEN bin/aclocal-1.16 GEN bin/automake-1.16 GEN doc/aclocal-1.16.1 GEN doc/automake-1.16.1 help2man: can't get `--help' info from automake-1.16 Try `--no-discard-stderr' if option outputs to stderr Makefile:3694: recipe for target 'doc/automake-1.16.1' failed make: *** [doc/automake-1.16.1] Error 255 make: *** Waiting for unfinished jobs $ ./pre-inst-env automake-1.16 --help "none" is not exported by the List::Util module Can't continue after import errors at /home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76. BEGIN failed--compilation aborted at /home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: dist-xz compression level
Am Montag 12 April 2010 20:31:22 schrieb Ralf Wildenhues: > My idea would be to implement this for master, and revert the recent > xz -9 patch on branch-1.11. Comments, criticism? if the environment variables can be used to set the compression, that is perfect for me. why write your own code, when the environment will be accepted automatically? but some documentation would help users I think. (also some man pages don't document these environment options, at least in the versions I have, but strings indicate they exist...) Regards, Andreas
Re: dist-xz compression level
Am Sonntag 11 April 2010 21:37:13 schrieb Andreas Jellinghaus: > isn't xz extremely slw with -9? > maybe it wasn't a bug, bit intentionally not used, > as that huge extra amount of time doesn't result in > that many bytes saved. > > is the compression level configureable somehow? I did two tests with medium size sources and xz -6 vs. xz -9 is not a big difference in speed or compression size. so please ignore my comment. Regards, Andreas
Re: dist-xz compression level
isn't xz extremely slw with -9? maybe it wasn't a bug, bit intentionally not used, as that huge extra amount of time doesn't result in that many bytes saved. is the compression level configureable somehow? Regards, Andreas
Re: unconditional version of EXTRA_DIST
Am Donnerstag 04 März 2010 03:31:04 schrieb Ralf Wildenhues: > > ah. ok, so back to the drawing board for my plan with > > optional documentation (see the thread a week ago or so). > > You can use either of > - wildcards, >EXTRA_DIST = pattern* > > - automake conditionals, >if COND >EXTRA_DIST += files... >endif > > - or plain old configure substitutions for variable content in > EXTRA_DIST. >EXTRA_DIST = file @list_of_files@ $(more_files) ok,thanks. will try wildcard. "*html" as patter will also work, if there is not even a single html file? Andreas
Re: unconditional version of EXTRA_DIST
Am Mittwoch 03 März 2010 20:32:53 schrieb Ralf Wildenhues: > Hello Andreas, > > * Andreas Jellinghaus wrote on Wed, Mar 03, 2010 at 02:11:52PM CET: > > I'm told EXTRA_DIST files are optional - automake > > will include them if they exist, but also go on, > > if those files do not exist. > > No, that is not true. Just try > EXTRA_DIST = does-not-exist > > and 'make dist' will fail. ah. ok, so back to the drawing board for my plan with optional documentation (see the thread a week ago or so). Thanks, Andreas
unconditional version of EXTRA_DIST
I'm told EXTRA_DIST files are optional - automake will include them if they exist, but also go on, if those files do not exist. so what do I use to include some file in the distribution, but not have automake do anything with it (change/install/..)? so far my Makefile.am uses EXTRA_DIST in some places, but I want automake to fail if the files are not there. (the files are not used by anything on unix/linux/gnu/mingw, for example "Makefile.mak" files for building with visual stdio/c). dist_DATA or something like that? Thanks, Andreas
create libraries with libtool, but don't install *.la files?
Hi, the combination autoconf/automake/libtool makes it quite easy to create shared libraries. but how can I install the file created as a single *.so file, but without any *.la file etc. the shared libraries we create implement a fixed plugin interface thus they don't need the normal versioning shared libraries have. also applications will only load the shared libraries using the plugin mechanism, so neither dynamic not statically linkinging in the library with application code is required. can you give an example how to archive this? Thanks, Andreas
Re: advice for pre-generating documentation
Ah, thanks. I didn't know about EXTRA_DIST. Is there some mechanism I can put a wildcard into automake files? for example it would be easier to specify "*.html", as the script downloads all wiki pages, and thus new pages would be added automaticaly that way. also I wonder: what about builddir vs. sourcedir? how do you handle that? if people have a tar.gz with pre-build documentation, it is in sourcedir. if people checkout svn and build in a seperate build root, the documentation is created in builddir. does automake handle that automaticaly? and is there a nice way to remove the documentation with "make clean" or "make distclean" if it was generated, but not remove it if it comes from the tar.gz? use the same if/else/endif around the CLEANFILES settings? Thanks! Regards, Andreas
advice for pre-generating documentation
Hi, we generate some docs with doxygen, others with a shell script using wget and xslt to download our wiki and create local html files from that). that mechanism is currently enabled with "--enable-doc", off by default as it is time-consuming and usualy not wanted. the problem I have is this: * I want people to checkout svn and compile and test the software without generating documentation. * if people want the docs, they should be able to create them too. * if I run "make distcheck", I want the existing documentation to be included in the tar.gz file. * if I run "make maintainer-clean", I want generate documentation to be removed, so I can diff between a modified checkout and an unmodified svn checkout. but our code to do all that is really ugly. so I wonder what the best way to implement something like this is. can you give me an advice? from my point of view documentation is on the same level as "configure" and "makefile.in" - something we don't keep in svn, but generate as first step after the checkout and then distribute as part of the tar.gz to users. is there some hook I can use to run custom commands easily from autoconf/make/libtool? maybe even in a way I can turn it on? (thus generate documentation only if asked) any better idea? thanks for your help. Regards, Andreas p.s. if you want to see the code we currently have: svn co http://www.opensc-project.org/svn/openct/trunk and look at the docs/ directory.
Re: problem --enable-shared and --enable-static together
Am Samstag 05 Dezember 2009 13:33:06 schrieb Ralf Wildenhues: > Hello Andreas, > > besides answers already given: > > * Andreas Otto wrote on Fri, Dec 04, 2009 at 09:41:16AM CET: > > as you see both *lo and *.o are created. the *.o are useless and just > > extend the compiling time > > > > Q: what can I do to avoid build static libraries ... > > foo_LIBTOOLFLAGS = -tag=disable-static > > for a target 'foo'. > > > I use "../libmsgque/*.lo" for in-project libraray dependency to avoid to > > link to my own shared libraray > > Sounds like you could profit from using convenience archives. from the info page: 8.3.5 Libtool Convenience Libraries --- Sometimes you want to build libtool libraries that should not be installed. These are called "libtool convenience libraries" and are typically used to encapsulate many sublibraries, later gathered into one big installed library. -> the problem is "not be installed" the base library from my project is "libmsgque" and this library is used for the following purpose: 1. installed as library 2. used as base library for a language-extension library 3. used as base library for some test-tools. for 2+3 I don't want to link again the shared libraray of "libmsgque" > > > 2. executables should build without library dependency. This mean that > > if configured with "--enable-static" the static object files should be > > used and if configureed without the shared object files should be used. > > Link the program against the library with -static. > > Hope that helps. > > Cheers, > Ralf
Re: problem --enable-shared and --enable-static together
Am Samstag 05 Dezember 2009 13:33:06 schrieb Ralf Wildenhues: > Hello Andreas, > > besides answers already given: > > * Andreas Otto wrote on Fri, Dec 04, 2009 at 09:41:16AM CET: > > as you see both *lo and *.o are created. the *.o are useless and just > > extend the compiling time > > > > Q: what can I do to avoid build static libraries ... > > foo_LIBTOOLFLAGS = -tag=disable-static Q: what is foo? I try "tclmsgque_LIBTOOLFLAGS" -> no change I look into the "Makefile" and get ... tclmsgque_la-context_tcl.lo: context_tcl.c $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $ (CPPFLAGS) $(tclmsgque_la_CFLAGS) $(CFLAGS) -MT tclmsgque_la-context_tcl.lo - MD -MP -MF $(DEPDIR)/tclmsgque_la-context_tcl.Tpo -c -o tclmsgq ue_la-context_tcl.lo `test -f 'context_tcl.c' || echo '$(srcdir)/'`context_tcl.c ... as you see only $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) are used ->I'm confused the info page speek about ... If `LIBRARY_LIBTOOLFLAGS' is not defined, the global `AM_LIBTOOLFLAGS' variable is used instead. ... about LIBRARY_LIBTOOLFLAGS well even the "LIBRARY" prefix does not work ->I'm more confused than I try AM_LIBTOOLFLAGS and get the following error... /bin/sh ../../libtool --tag=CC -tag=disable-static --mode=compile ccache gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -D_DEBUG -I./../libmsgque - I/home/dev1usr/ext/x86_64-suse-linux/thread/include -DUSE_TCL_STUBS - DMQ_IGNORE_EXTERN -g -O3 -Wall -Wcast-align -Wstrict-prototypes - fvisibility=hidden -g -O2 -pthread -MT tclmsgque_la-context_tcl.lo -MD -MP -MF .deps/tclmsgque_la-context_tcl.Tpo -c -o tclmsgque_la-context_tcl.lo `test -f 'context_tcl.c' || echo './'`context_tcl.c libtool: unrecognized option `-tag=disable-static' libtool: Try `libtool --help' for more information. make: *** [tclmsgque_la-context_tcl.lo] Fehler 1 after a look inti the info page I change "-tag" to "--tag" .. next try now it works ... summary: change: foo_LIBTOOLFLAGS = -tag=disable-static into AM_LIBTOOLFLAGS = --tag=disable-static than it is fine > > for a target 'foo'. > > > I use "../libmsgque/*.lo" for in-project libraray dependency to avoid to > > link to my own shared libraray > > Sounds like you could profit from using convenience archives. > > > 2. executables should build without library dependency. This mean that > > if configured with "--enable-static" the static object files should be > > used and if configureed without the shared object files should be used. > > Link the program against the library with -static. > > Hope that helps. > > Cheers, > Ralf
problem --enable-shared and --enable-static together
Hi, I have a project using together the both statements from above to configure. This project hase many different parts includig many shared libraries and executables. Now the problem. 1. I have libraries which are only useful as "shared" libraries. this libraries are language extension used to dl-open by an programming language. these libraries should "not" build the "static" object files example: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>< pkglib_LTLIBRARIES = tclmsgque.la tclmsgque_la_SOURCES = context_tcl.c misc_tcl.c msgque_tcl.c read_tcl.c send_tcl.c \ config_tcl.c service_tcl.c msgque_tcl.h slave_tcl.c \ MqBufferS_tcl.c error_tcl.c # use this if you want to include the libmsgque files into the tclmsgque libraray tclmsgque_la_CFLAGS = -I$(srcdir)/../libmsgque $(TCL_INCLUDE_SPEC) $(TCL_CFLAGS) $(AM_CFLAGS) -DMQ_IGNORE_EXTERN tclmsgque_la_LIBADD = ../libmsgque/*.lo tclmsgque_la_LDFLAGS = -shared -module -avoid-version -no-undefined $(TCL_LIBADD) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< the following object files are created >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -rw-rw-r-- 1 dev1usr users 1000 4. Dez 09:27 tclmsgque.la -rw-rw-r-- 1 dev1usr users323 4. Dez 09:27 tclmsgque_la-config_tcl.lo -rw-rw-r-- 1 dev1usr users 154528 4. Dez 09:27 tclmsgque_la-config_tcl.o -rw-rw-r-- 1 dev1usr users326 4. Dez 09:27 tclmsgque_la-context_tcl.lo -rw-rw-r-- 1 dev1usr users 120656 4. Dez 09:27 tclmsgque_la-context_tcl.o -rw-rw-r-- 1 dev1usr users320 4. Dez 09:27 tclmsgque_la-error_tcl.lo -rw-rw-r-- 1 dev1usr users 96240 4. Dez 09:27 tclmsgque_la-error_tcl.o -rw-rw-r-- 1 dev1usr users317 4. Dez 09:27 tclmsgque_la-misc_tcl.lo -rw-rw-r-- 1 dev1usr users 94800 4. Dez 09:27 tclmsgque_la-misc_tcl.o -rw-rw-r-- 1 dev1usr users332 4. Dez 09:27 tclmsgque_la-MqBufferS_tcl.lo -rw-rw-r-- 1 dev1usr users 97688 4. Dez 09:27 tclmsgque_la-MqBufferS_tcl.o -rw-rw-r-- 1 dev1usr users323 4. Dez 09:27 tclmsgque_la-msgque_tcl.lo -rw-rw-r-- 1 dev1usr users 103328 4. Dez 09:27 tclmsgque_la-msgque_tcl.o -rw-rw-r-- 1 dev1usr users317 4. Dez 09:27 tclmsgque_la-read_tcl.lo -rw-rw-r-- 1 dev1usr users 113008 4. Dez 09:27 tclmsgque_la-read_tcl.o -rw-rw-r-- 1 dev1usr users317 4. Dez 09:27 tclmsgque_la-send_tcl.lo -rw-rw-r-- 1 dev1usr users 122192 4. Dez 09:27 tclmsgque_la-send_tcl.o -rw-rw-r-- 1 dev1usr users326 4. Dez 09:27 tclmsgque_la-service_tcl.lo -rw-rw-r-- 1 dev1usr users 88400 4. Dez 09:27 tclmsgque_la-service_tcl.o -rw-rw-r-- 1 dev1usr users320 4. Dez 09:27 tclmsgque_la-slave_tcl.lo -rw-rw-r-- 1 dev1usr users 93392 4. Dez 09:27 tclmsgque_la-slave_tcl.o <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< as you see both *lo and *.o are created. the *.o are useless and just extend the compiling time I use "../libmsgque/*.lo" for in-project libraray dependency to avoid to link to my own shared libraray Q: what can I do to avoid build static libraries ... 2. executables should build without library dependency. This mean that if configured with "--enable-static" the static object files should be used and if configureed without the shared object files should be used. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> brain_SOURCES = brain.c brain_CFLAGS = -I../theLink/libmsgque -I$(BRAIN_HOME)/include - DMQ_LINK_WITH_LIBRARY_OBJECT_FILES if HAS_STATIC LIBMSQUE = ../theLink/libmsgque/*.o else LIBMSQUE = ../theLink/libmsgque/*.lo endif brain_LDADD = -lz -lbz2 -lrt -lm -lc $(LIBMSQUE) $(BRAIN_HOME)/lib/libtokyocabinet.a <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I need a HELPER called HAS_STATIC defined in configure.in with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AM_CONDITIONAL([HAS_STATIC], [test "$enable_static" = "yes"]) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Q: Is this OK or is something better is possible ? mfg Andreas Otto
question to the subpackage feature
Hi, I have integrated an subpackage into an already existing package everything works well but one problem still exists the debugging feature is turned on in the toplevel package with --enable-symbols and in the subpackage with --enable-debug some kind of translation is necessary -> how I can do this ? in generell all commandline arguments from the toplevel package are send to the subpackage even if the arguments have no meaning in the subpackage -> how I solve this issue ? example: toplevel ... + bash ./configure --prefix=/tmp/libmsgque-install --enable-symbols --enable- tcl --enable-cxx --enable-threads subpackage ... === configuring in tokyocabinet-1.4.39 (/home/dev1usr/Project/libbrain/tokyocabinet-1.4.39) configure: running /bin/sh ./configure --disable-option-checking '-- prefix=/tmp/libmsgque-install' '--enable-symbols' '--enable-tcl' '--ena ble-cxx' '--enable-threads' 'CC=ccache gcc' 'CXX=ccache g++' --cache- file=/dev/null --srcdir=. in addition: confiure --help does only show the help-page from the toplevel package and does not provide any information from the subpackage ... mfg Andreas Otto
Re: OS independent build results
Hi, this is my solution: this add a new target ".vpath_hook" to the build environment and this target copy the files/directories listed in "VPATH_FILES" from the src into the build environment. the "copy" is necessary because tools like "JAR" expect the files in the "build" directory. ".vpath_hook" is the FIRST target in BUILT_SOURCES to garantee that the copy is done before any furter action are done. 1. acinclude.m4 # # SC_SET_VPATH_HOOK -- # # add support for VPATH build # # Arguments: # none # need variable "VPATH_FILES" be defined # # Results: # # Add a new variable VPATH_HOOK/CLEANUP/DIST to automake # # AC_DEFUN([SC_SET_VPATH_HOOK], [ AC_MSG_CHECKING([add VPATH hook]) AC_SUBST([VPATH_HOOK], ['@if test ! -f .vpath_files -a "$(srcdir)" != "." ; then (cd "$(srcdir)" && cp -r $(VPATH_FILES) "$(abs_builddir)";) && touch ".vpath_files" && chmod -R u+w $(VPATH_FILES) && echo "VPATH copy"; else true; fi && touch ".vpath_hook"']) AC_SUBST([VPATH_HOOK_CLEANUP], ['-rm -f .vpath_hook; test -f .vpath_files && rm -fr .vpath_files $(VPATH_FILES)']) AC_SUBST([VPATH_HOOK_DIST], ['-rm -f $(distdir)/.vpath_hook']) ]) 2. example java Automake.am: ... # ## VPATH setup .vpath_hook: $(VPATH_HOOK) VPATH_FILES = javamsgque javamsgque_MqS.h javamsgque_MqBufferS.h javamsgque_MqS_WAIT.h javamsgque.jar BUILT_SOURCES = .vpath_hook $(mqs_DATA) javamsgque_MqS.h javamsgque_MqBufferS.h MAINTAINERCLEANFILES = $(BUILT_SOURCES) javamsgque_MqS_WAIT.h javamsgque/*.class ... distclean-local: $(VPATH_HOOK_CLEANUP) dist-hook: $(MQS_MAIN) $(VPATH_HOOK_DIST) mkdir "$(distdir)/javamsgque" chmod u+w "$(distdir)/javamsgque" cp javamsgque/*.class "$(distdir)/javamsgque" chmod u+w $(distdir)/javamsgque/*.class !important! is that "make clean" should not clean the *.class files. I use the "MAINTAINERCLEANFILES" to clean this files also
OS independent build results
Hi, currently I try to improve my build environment. I want to add "OS" independent build results like java "class" files or mono "clr" libraries/excutable into the distribution 1) the problem is the VPATH build. the files from above are in the "srcdir" and not in the "builddir" (1'st location) 2) if one of the "prerequisite" file are touched (java -> *.java", mono -> *.cs") the "new" class or clr file(s) are in the "builddir" (2'nd location) after the build -> now I have 2 locations from which the "dist" or a other command like the java "jar" can take the files 3) only for case 2) the VPATH build have to clean up the files 4) for a very special vase VB.NET CLR files can only be compiled on a special OS (Windows). A non-Windows OS should use the dist files and print a WARNING message if a build have to be done is a solution available? one solution would be that vor a VPATH build I can specify a set of dirs/files (in a variable) to COPIED first from the srcdir into the builddir, these copied files have to be removed in a "distclean" -> attention the copy have only be done if the target of the same name is not available mfg Andreas Otto
builddir question
Hi, is a "builddir" other than "." possible ? mfg aotto1968
Re: integration of perl with automake
Am Dienstag 20 Oktober 2009 21:07:35 schrieb Ralf Wildenhues: > * Andreas Otto wrote on Tue, Oct 20, 2009 at 08:53:14AM CEST: > > Am Dienstag 20 Oktober 2009 08:27:01 schrieb Ralf Wildenhues: > > > > distclean-local: > > > > test -f Net-Msgque/.distclean && rm -fr Net-Msgque > > > > > > Won't that also remove files from your package iff source and build > > > tree coincide? > > > > I use the flag file "Net-Msgque/.distclean" to distinguish the VPATH > > build from the non VPATH build. this flag is only set in the directory I > > copied from the source into the build tree and clean act on this flag > > OK, but then 'make distclean' wouldn't remove the files it should > remove, if source and build tree coincide, no? > > Cheers, > Ralf Hi, $(PERLMAKEFILE): $(PERLDEPEND) Makefile.am -test ! -d Net-Msgque && cp -pr $(srcdir)/Net-Msgque . && \ chmod -R u+w Net-Msgque && touch Net-Msgque/.distclean cd Net-Msgque && @PERL@ Makefile.PL $(PERLCONFIG) non VPATH -> build-tree == source-tree => no copy and no flag "Net-Msgque.distclean" => no distclean remove VPATH -> build-tree != source-tree => copy from Net-Msgque done and flag "Net-Msgque/.distclean" set => distclean remove performed is this does not explain your problem than I don't understand what you mean mfg Andreas Otto
Re: integration of perl with automake
Am Dienstag 20 Oktober 2009 08:27:01 schrieb Ralf Wildenhues: > Hello Andreas, > > thanks for sharing your solution. A couple of comments: > > * Andreas Otto wrote on Mon, Oct 19, 2009 at 12:20:26PM CEST: > > if USE_PERL > > > > PERLMAKEFILE = Net-Msgque/Makefile > > PERLDEPEND= Net-Msgque/Makefile.PL Net-Msgque/typemap Net- > > Msgque/lib/Net/Msgque.pm > > PERLCONFIG= PREFIX=$(prefix) \ > > It would be prudent to quote $(prefix), too. > > > INC="-Wall -I. -I../$(top_srcdir)/src" \ > > OBJECT="\$$(O_FILES) ../$(top_builddir)/src/.libs/*.o" > > > > install-exec-local: > > cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(DESTDIR) > > install > > Likewise, I'd quote $(DESTDIR) here, or even better, omit > DESTDIR=$(DESTDIR) unless Net-Msgque/Makefile initializes it. > > > uninstall-local: > > rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/Net/Msgque.pm > > Please remove the slash between $(DESTDIR) and $(prefix) here and in > following lines. Otherwise you risk breaking the installation on w32 > with --prefix=C:/foo and empty DESTDIR. Also, again it would be prudent > to quote the $(DESTDIR)$(prefix) part of the strings. > > > rm -f > > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.so > > rm -f > > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.bs > > rm -f > > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/autosplit.ix > > rm -f > > $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/.packlist > > rm -f $(DESTDIR)/$(prefix)/lib/*/*/*/perllocal.pod > > rm -f $(DESTDIR)/$(prefix)/share/man/man3/Net::Msgque.3 > > > > distclean-local: > > test -f Net-Msgque/.distclean && rm -fr Net-Msgque > > Won't that also remove files from your package iff source and build tree > coincide? Hi, I add your suggestions ... I use the flag file "Net-Msgque/.distclean" to distinguish the VPATH build from the non VPATH build. this flag is only set in the directory I copied from the source into the build tree and clean act on this flag mfg Andreas Otto
Re: integration of perl with automake
Hi, this is my solution: I have coosen a Makefile.am wrapper and the perl-extension is in a subdirectory of the wrapper. I changed the extension-name to Net::Msgque (as requested by the perl community) the automake configuration is complete (as of my needs) including a VPATH build and including the "distclean" check. PERL - MakeMaker does not support a VPATH build but a work- around is possible to copy the perl extension directory into the build directory. This have to be cleaned-up in distclean-local. now the Makefile: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if USE_PERL PERLMAKEFILE = Net-Msgque/Makefile PERLDEPEND= Net-Msgque/Makefile.PL Net-Msgque/typemap Net- Msgque/lib/Net/Msgque.pm PERLCONFIG= PREFIX=$(prefix) \ INC="-Wall -I. -I../$(top_srcdir)/src" \ OBJECT="\$$(O_FILES) ../$(top_builddir)/src/.libs/*.o" if DEBUG PERLCONFIG+= OPTIMIZE=-g endif $(PERLMAKEFILE): $(PERLDEPEND) Makefile.am -test ! -d Net-Msgque && cp -pr $(srcdir)/Net-Msgque . && chmod -R u+w Net-Msgque && touch Net-Msgque/.distclean cd Net-Msgque && @PERL@ Makefile.PL $(PERLCONFIG) all-local: $(PERLMAKEFILE) cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS) clean-local: $(PERLMAKEFILE) cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS) clean install-exec-local: cd Net-Msgque && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(DESTDIR) install uninstall-local: rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/Net/Msgque.pm rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.so rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.bs rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/autosplit.ix rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/.packlist rm -f $(DESTDIR)/$(prefix)/lib/*/*/*/perllocal.pod rm -f $(DESTDIR)/$(prefix)/share/man/man3/Net::Msgque.3 distclean-local: test -f Net-Msgque/.distclean && rm -fr Net-Msgque endif EXTRA_DIST = \ Net-Msgque/ppport.h \ Net-Msgque/Msgque.xs \ Net-Msgque/lib/Net/Msgque.pm \ Net-Msgque/Makefile.PL \ Net-Msgque/README \ Net-Msgque/t/Net-Msgque.t \ Net-Msgque/Changes \ Net-Msgque/MANIFEST \ Net-Msgque/typemap <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< mfg Andreas Otto
integration of perl with automake
Hi, to build a perl extension it's best to use the perl build-system based on perl Makefile.PL the command create a Makefile in the same directory of Makefile.PL self and in the toplefel-position "perlmsgque/Makefile". I can use this makefile in an automake build environment using SUBDIRS += perlmsgque from the toplevel now the problem. a "make clean" clean the file perlmsgque/Makefile. this is coded in the "Makefile.PL" create Makefile 1. I need automake code to check if "perlmsgque/Makefile" is avilable and build this makefile again if missing (after make clean) or extend the toplevel Makefile to do a (cd perlmsgque;perl Makefile.PL) after all "make clean" was done 2. related to this problem Is the initial build of the "perlmsgque/Makefile" currently I use the autoconf to do the "perl Makefile.PL" but I thing it should be better done on need in the toplevel makefile. I hope this is not to complicated -> thanks for help mfg aotto1968
I need a hint to integrate a php-extension build into an existing automake
Hi, I want to add a "php" extension into an allready existing project creating various extensions to other languages as well I use automake/autoconf for build top-level project. My new "php" extension has the name "phpmsgque" build in the subdirectory of the same name. The sudirectory is filled with all files necessary to build a php extension php requires the following steps to build an extension, 1. change into the phpmsgque directory 2. run the tool: phpize -> this tool create a complete autoconf build environment including "configure.in" 3. run the command: ./configure --enable-phpmsgque -> this create a "Makefile" 4. now use make for build now my problem: 1. while running the toplevel "automake" (or autoreconf) I would like to run the tool "phpize" in the phpmsgque subdirectory to create the php build environment. I have the "Makefile.am" (not used in the php build) to add instructions to link the both build environments. 2. while run toplevel "configure" I would like to run the "configure" script in the "phpmsgque" subdirectory as well so I looking for an integration of 2 build environments the second question is easy to solve I use AC_CONFIG_SUBDIRS([phpmsgque]) in the toplevel configure.in but the php build environment has "no" AM_INIT_AUTOMAKE to get a "full" integration I use the docs from automake info pages to get the info from above to integrate two packages:
using C# in automake
Hi, I want to create an language binding for a "C" libraray this mean I have as input an file called "csmsgque.cs" and get as output an "csmsgque.dll" on unix My current makefile looks like: = .dll.cs: mkdir .libs $(CSCOMP) -v -unsafe -nologo -out:./.libs/$@ -target:library $< pkglib_LIBRARIES = csmsgque.dll csmsgque_dll_sources = csmsgque.cs = but I get the following error csmsgque/Makefile.am:17: `csmsgque.dll' is not a standard library name csmsgque/Makefile.am:17: did you mean `libcsmsgque.a'? I need docs on howto create NON-C language project which create language specific executables or libraries into automake I want to create this libraries into the ".libs" directory as "libtool" does and finally I want to install these files into the "pkglibdir" / "bindir" directory for install .. ... and I want that the language specific source files "*.cs" be included into the dist ... and I want that this is tested during distcheck as well -> lot of stuff, but a template would be fine for other users as well mfg Andreas Otto
Re: cross-compiling on 64 to 32-bit Linux
Jan Engelhardt writes: >>needs to use $CC/$CXX anyway. > > CCLD/CXXLD. Which default to $CC/$CXX anyway. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: cross-compiling on 64 to 32-bit Linux
Bruno Haible writes: > - The -m32 flag has to be passed as part of both CC / CXX and LDFLAGS. That should not be necessaray, since any command that uses $LDFLAGS needs to use $CC/$CXX anyway. > - The -m64 flag is the default on bi-arch Linux systems. This is wrong. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
shared libraries with used defined extension
Hi, Unix/Linux is using *.so as shared libraray extension ... Windows is using *.dll as shared libraray extension... Python requires the postfix *.pyd as shared library extension Question: it is possible to use it own shared library extension using automake, autoconf, libtool ... mfg Andreas Otto
binary distribution build with automake
Hi, I missing one target in automake to create a binary distribution Reason: 1. the default prefix is "/usr/local" -> thats ok 2. this prefix is required for libraray "rpath" feature -> thats ok 3. to buid and install a sw in "/usr/local" is a problem because it belons to "root" and not to the "user" ans should not be used in "normal" sw development what I want 1. a new target "binary-dist" 2. to create a binary distribution: "$(PACKAGE)-$(PACKAGE_VERSION)-$(build).tar.gz" -> I choose "build" as hw/os identification string 3. able to use "--prefix" as system-directory !without! installation requirement mfg Andreas Otto
Re: rebuilding following a change in prefix?
Jan Engelhardt writes: > Well, automake (unfortunately?) does not currently issue a recompile > when the compiler command changed. > It would be really cool to have that, though. But that should be optional. I don't want to do a complete rebuild just because I want to do a quick recompile of a single object file with different options. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: rebuilding following a change in prefix?
Adam Mercer writes: > I have noticed some strange behaviour with the build system on a > project I am working on, consider the following: > > $ ./configure --prefix=/path/1 > $ make > $ make install > $ ./configure --prefix=/path/2 > $ make > $ make install I'd suggest using separate build directories for each build. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Setting shared lib version not functioning
John Calcote writes: > One thing that bothers me a little is that we never really did solve > Gerald's original problem. He said his library was created just fine when > he was passing 2:0:0, but when he switched to 2:0:1, it created a library > with a version number of 1:1:0. Now, why would Libtool do this? Granted, > he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So > why did Libtool convert it to 1:1:0? For the linux way of library versioning the library suffix is computed as (current-age).age.revision, thus 2:0:1 maps to 1.1.0. A libtool version of 1:1:0 whould map to 1.0.1. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Example on JNI compilation
Am Samstag 18 April 2009 23:08:58 schrieb LCID Fire: > I'm currently stuck with compiling a JNI library, which java does not > recognize. I'm not too sure about what options I have to provide to > automake and which are already builtin. Does anybody know an example of > how a jni lib is built using automake? Hi, in my project: http://libmsgque.sourceforge.net/ you can find a implementation useable as template 1. download the sources 2. go into the "javamsgque" directory 3. don't forget to add the autoconf macros for JNI from the "m4" subdirectory and the "acinclude.m4" file mfg Andreas Otto
problem to create a "noinst_LTLIBRARIES" shared libraray
Hi,
I currently writing a java JNI extension used only for local "check" and
this library should *not* be installed.
The problem is that I need a shared library for dlopen using java
file: TestMain.java
===
public abstract class TestMain extends MqS.Main {
static {
System.loadLibrary("javatestmsgque");
}
...
===
but automake/libtool only create a *static* library even if the "_LDFLAGS"
-module is used
file: Makefile.am
===
noinst_LTLIBRARIES = libjavatestmsgque.la
libjavatestmsgque_la_SOURCES = test_java.c TestMain.h
libjavatestmsgque_la_CFLAGS = -I$(top_srcdir)/src $(AM_CFLAGS)
libjavatestmsgque_la_LIBADD = ../src/libmsgque.la
libjavatestmsgque_la_LDFLAGS = -module
===
this are the "static "libraries created using the "noinst_" prefix
buildsubdirectory: .libs
===
-rw-r--r-- libjavatestmsgque.a
lrwxrwxrwx libjavatestmsgque.la -> ../libjavatestmsgque.la
-rw-r--r-- libjavatestmsgque_la-test_java.o
===
using the "pkglib_" or the "lib_" prefix I get the shared libraries
subdirectory: .libs
==
lrwxrwxrwx libjavatestmsgque.la -> ../libjavatestmsgque.la
-rw-r--r-- 1libjavatestmsgque.lai
-rw-r--r-- 1libjavatestmsgque_la-test_java.o
lrwxrwxrwx libjavatestmsgque.so -> libjavatestmsgque.so.0.0.0
lrwxrwxrwx libjavatestmsgque.so.0 -> libjavatestmsgque.so.0.0.0
-rwxr-xr-x 1libjavatestmsgque.so.0.0.0
===
Question: what can I do to get a shared LTLIBRARIES using the "noinst"
prefix ?
every answer is welcome ...
Spurious testsuite failures
I'm getting several failures in the automake testsuite, for example: FAIL: libtool.test (exit: 1) /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests:/opt/kde3/bin:/home/andreas/bin/ccache:/home/andreas/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin:/sbin:/usr/local/m68k-linux/gcc/bin:/usr/local/m68k-linux/bin:/usr/local/ia64-linux/bin:/usr/lib/git libtool: running libtool --version ltmain.sh (GNU libtool) 2.2.6 Written by Gordon Matzigkeit , 1996 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. === Running test ./libtool.test ++ pwd /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests/libtool.dir + cat + : + : + : + : + aclocal-1.10b -Werror -Wno-syntax -I /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests/../m4 -I /usr/local/share/aclocal -I /usr/share/aclocal aclocal: couldn't open directory `/usr/local/share/aclocal': No such file or directory + Exit 1 + set +e + exit 1 + exit 1 + exit_status=1 + cd /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests + case $exit_status,$keep_testdirs in + test 0 '!=' 0 + echo ': exit 1' : exit 1 + exit 1 The problem is that /usr/share/aclocal/dirlist contains the (non-existing) directory /usr/local/share/aclocal. Normally aclocal would ignore such a directory, but by adding it explicitly with -I aclocal now complains. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: blank line following trailing backslash
Am Montag, 26. Januar 2009 schrieb Ralf Wildenhues: > Hello Andreas, > > * Andreas wrote on Sun, Jan 25, 2009 at 06:42:52PM CET: > > fileA.c \ > > fileB.c \ > > fileC.c > > [...] > > > This is not nice so I thought well let's add a backslash after the > > last file and add an empty line at the end. Then there's no need to > > modify the fileC line and everybody just adds a line to the list. This > > can be resolved. But automake doesn't like this at all. Even though it > > is clearly visible that this is not wrong it complains. It doesn't > > even warn about this it produces an error. > > Jan already provided a way around this. Here's why automake warns about > it at all: it is not portable to have a backslash followed by a blank > line, as some make implementations are rather unpredictable with it: > <http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewlin >e_002dNewline.html> > <http://www.gnu.org/software/autoconf/manual/html_node/Backslash_002dNewlin >e-Comments.html> > > Hope that helps. > > Cheers, > Ralf Ok, ich verstehe. Ich muß zugeben meine Make und Automake Kenntnisse sind eher gering, aber könnte man nicht eine Warnung ausgeben und den letzten Backslash entfernen? Immerhin erkennt man ihn, es sollte also möglich sein ihn auch weg zu nehmen Andreas
blank line following trailing backslash
Hello everybody, I just had an ingenious idea to limit conflicts in versioning systems. When you specify a list of files for a rule you put every file in a line like this. fileA.c \ fileB.c \ fileC.c now if 2 independent people add another file fileD and fileE to that list you have a conflict because both of them modify the line with fileC.c to add the necessary backslash. This is not nice so I thought well let's add a backslash after the last file and add an empty line at the end. Then there's no need to modify the fileC line and everybody just adds a line to the list. This can be resolved. But automake doesn't like this at all. Even though it is clearly visible that this is not wrong it complains. It doesn't even warn about this it produces an error. I think this is not nice. Is there a way around this problem? Can I do something to make all file list entries identical? Or can I tell automake to ignore this or only produce a warning? Thanks a lot Andreas
Re: Portable suffix rules question
Jan Engelhardt writes: > I reckon that %-style suffix rules (e.g. "%.o: %.c") are rather > unportable, but I wonder how the old-fashioned suffix rule for > > %.1: %.1.php > > would look like. There is none. A suffix rule can contain at most two periods, so the closest you can get is this: .php: Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: automake manual: distclean
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> This is not quite portable -- unless GNU find, which implies a
> path of "." if nothing else is specified, Solaris's explicitly requires
> a path to find. It should therefor read
>
> distcleancheck_listfiles = \
>find . -type f -exec sh -c 'test -f $(srcdir)/{} || echo {}' ';'
This isn't quite portable either. POSIX only requires that find -exec
substitutes in arguments consisting of exactly {}.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Generating Autotools files without autoreconf
Roberto Bagnara <[EMAIL PROTECTED]> writes: > In other words, we would need something that acts like autoreconf except > for the fact that it would not attempt to build configure from configure.ac. $ AUTOCONF=true autoreconf ... Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Problems with conditional sources
John Calcote <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: >> John Calcote <[EMAIL PROTECTED]> writes: >> >>> Make is a two-pass utility. The first pass completely assimilates all >>> macro data specified in the Makefile. THEN, the second pass generates >>> the rule dependency tree. >> >> This is not true. Variable refences in target and dependency lists are >> expanded when they are read. Any later redefinition will not change >> them. >> >> Andreas. >> > > This is only true if you use ':=' assignment. You are mistaken. RTFM. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Problems with conditional sources
John Calcote <[EMAIL PROTECTED]> writes: > Make is a two-pass utility. The first pass completely assimilates all > macro data specified in the Makefile. THEN, the second pass generates > the rule dependency tree. This is not true. Variable refences in target and dependency lists are expanded when they are read. Any later redefinition will not change them. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Problems with conditional sources
David Sveningsson <[EMAIL PROTECTED]> writes:
> Hi, I am having some problems with conditional sources. This is what I
> have in Makefile.am:
>
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_SOURCES = foo.cpp
> if WANT_BAR
> libfoo_la_SOURCES += a.cpp
> else
> libfoo_la_SOURCES += b.cpp
> endif
>
> AM_CPPFLAGS = -I${top_srcdir}/include
> libfoo_la_LDFLAGS = -version-info 0:0:0
>
> I have been reading both autoconf and automake manuals and as far as I can
> see the above should work. However the files (a.cpp or b.cpp) is always
> added at the bottom of the generated Makefile and are therefore not used
> in the compilation. No matter what I try I cannot get even the above code
> to generate a correct makefile but obviously I am doing something wrong.
Remove the indentation.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Warn: non-POSIX variable name
Brian Dessent <[EMAIL PROTECTED]> writes: > 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. Even worse, it is recomputed each time the variable is _used_, ie. for every compilation job started by make. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: How can I change shared library's version number?
"Steven Woody" <[EMAIL PROTECTED]> writes: > 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. See (libtool)Versioning. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: bug in automake? Getting ARFLAGS to work...
Ed Hartnett <[EMAIL PROTECTED]> writes: > In order to build on AIX in 64-bit mode, I have to be able to set the > ARFLAGS, but I can't get that to work. No matter what I do, automake > ignores my ARFLAGS and just uses "cru". This is a libtool issue, nothing to do with automake. For whatever reason, libtool is using AR_FLAGS, not ARFLAGS. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: build configuration help
John Calcote <[EMAIL PROTECTED]> writes: > The way you implement this is to use $(prefix)/lib, or $(libdir) in your > -R option, which will resolve to the configured library installation > directory - /home/bob/foo/lib. When you use -R like this, however, just > realize that this binary can only be installed on this one non-standard > location (it can still be installed in standard locations). You can use -R '$ORIGIN/../lib' to make the binary relocatable. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: proper autotools ordering?
[EMAIL PROTECTED] (Karl Berry) writes: > I've been using aclocal - autoheader - automake - autoconf for years, > but have no idea any more where I got that ordering. I see that > autoreconf runs autoconf before autoheader, and ah before am, so I > suppose this is it: > aclocal - autoconf - autoheader - automake. There is no real dependency between autoconf/autoheader/automake. The only requirement is that aclocal is run before any of them, and sometimes it has to be run twice if libtoolize enters the scene. > Whatever the answer is, I suggest adding it to the manual(s). The manual should recommend autoreconf if it doesn't already. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Forcing an AC_CHECK to fail
"Michael B Allen" <[EMAIL PROTECTED]> writes: > So how to do I preset a cache variable before running configure? You can put it in the environment, or use config.site. See (autoconf)Site Defaults. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Forcing an AC_CHECK to fail
"Michael B Allen" <[EMAIL PROTECTED]> writes: > So is there a way to tell a specific check to fail? You can preset the cache variable before running configure. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Makefile.am assistance
NightStrike <[EMAIL PROTECTED]> writes: > Ok. I just tested your idea, and I am going to move all .a custom > targets to a _DATA primary, and leave the _SCRIPTS primary for just > the custom executable targets (like crt1.o, etc). crt1.o is DATA as well. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: read-only git mirror of automake cvs repository
Jim Meyering <[EMAIL PROTECTED]> writes: > I admit it was took more than a few iterations to get it right. > One of the big points was to realize that cvsps' cache was causing > trouble. So I'm careful to make git-cvsimport run cvsps in such a > way that the cache can't interfere. > One way to do that is to point HOME= at an empty directory > for the git-cvsimport run. I think you should be able to use '-p -x' to pass -x to cvsps. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: multi-line AC_SUBSTs as targets in Makefile.am
William Pursell <[EMAIL PROTECTED]> writes: > I'd like to get away from AC_SUBST_FILE, but I don't see a way > around the manner in which automake is building the Makefile. > Is there a way to construct a generic target via AC_SUBST? How about using AM_CONDITIONAL instead? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: strange choice of compiler on HP-UX
[EMAIL PROTECTED] (Bob Proulx) writes: > Since on HP-UX with the optional HP ANSI C compiler installed 'cc' is > a symlink in /usr/bin and also /bin on HP-UX is a symlink to /usr/bin > resulting in a single large bin directory with everything in it all in > one place so it would be difficult to change this by adjusting PATH. You are free to create your own directory. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: strange choice of compiler on HP-UX
Joao Miguel Ferreira <[EMAIL PROTECTED]> writes: > Question: How do I tell the tools to use only aCC for both types of > files, when compiling on an HPUX (we also build on Linux/gcc and > Solaris/gcc) ? ./configure CC=foo CXX=bar > PS: the cc is a link in /usr/bin that point to /opt/ansic/bin/cc !!! I > am not root of this system :-( You don't need to be root to change PATH. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: ${} and $()
Jan Engelhardt <[EMAIL PROTECTED]> writes: > (And the stupid reply: am I on automake@gnu.org or [EMAIL PROTECTED] :-) automake both about makefiles and configue scripts. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: ${} and $()
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> is there any real difference between $(var) and ${var}, and is the
> latter as much POSIX as the first?
Depends on the context. For a shell there is a big difference between
them. When interpreted by make they are identical.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: multiple cpu's
Bob Rossi <[EMAIL PROTECTED]> writes: > Can automake take advantage of multiple cpu's? This has nothing to do with automake. Just use the appropriate switch for make to enable parallel execution. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: PING: Automake list
NightStrike <[EMAIL PROTECTED]> writes: > Where should I look instead for automake archives? Since the list is @gnu.org, you should be looking at lists.gnu.org. (Also, Gmane is a good place to look.) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: %-style pattern rules
Lorenzo Bettini <[EMAIL PROTECTED]> writes: > Ralf Wildenhues wrote: >> Hello Lorenzo, >> >> * Lorenzo Bettini wrote on Fri, Jul 27, 2007 at 05:18:48PM CEST: >>> and what if I need two files (with two different extensions) depend on >>> a single file? >> >> That is not possible portably, i.e., with inference rules. So either >> you can just choose to rely on GNU make, or write one rule per instance. > > apart from multiple files, I also tried to update some Makefile.am as > follows: > > SUFFIXES = .cc.html .cs.html .h.html > > .cs.cs.html: > $(CSHARP2HTML) -i $< -o $@ This is not a recognized suffix rule, you'll have to register the .cs suffix manually. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Circular dependecy linker trouble
Søren Boll Overgaard <[EMAIL PROTECTED]> writes: > Framework code depends on services code and vice versa. > Linking fails to resolve dependencies. The linker command line > essentially looks like this: > > g++ -g -O2 ../src/framework/libframework.a ../src/services/ > liblmsservices.a -o program main.o -lpthread Note that the command line as shown won't pull anything from the archives, because at the time they are processed there are no unresolved symbols yet (except for the symbol main). You should always list the libraries after the objects that reference symbols out of them. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: generated ChangeLog
Stepan Kasal <[EMAIL PROTECTED]> writes: > if a projects wants to generate ChangeLog dynamicly, from a > versioning system, by a make rule, how it can be done? > If you write the rule for ChangeLog to Makefile.am, then Automake > complains that the file does not exist at the time Automake is run. If you use AUTOMAKE_OPTIONS = foreign then automake should not complain. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Desktop file and exec path
Benoit Sigoure <[EMAIL PROTECTED]> writes: > Although two ways of solving this issue have been proposed already, there is > also another way out: using an AC_CONFIG_FILES. > > glpegsolitaire.desktop.in > -- > [Desktop Entry] > Name=Peg Solitaire > Comment=A "Peg Solitaire" for Gnome > [EMAIL PROTECTED]@ > Icon=glpegsolitaire.png > Terminal=false > Type=Application > Categories=GNOME;Game;BoardGame > StartupNotify=true > -- > > In your configure.ac: > AC_CONFIG_FILES([path/to/glpegsolitaire.desktop]) Such substitutions only work correctly in makefiles, since they can expand to references to other substituted variables that are supposed to be recursively expanded as done by make. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Desktop file and exec path
Enrico Sardi <[EMAIL PROTECTED]> writes: > glpegsolitaire.desktop > -- > [Desktop Entry] > Name=Peg Solitaire > Comment=A "Peg Solitaire" for Gnome > Exec=glpegsolitaire > Icon=glpegsolitaire.png > Terminal=false > Type=Application > Categories=GNOME;Game;BoardGame > StartupNotify=true > > -- > > and I want that if I give the command "make install" the path in the > Exec field will be replaced by the value of the $(datadir) variable. Is > this possible? Use @DATADIR@ in glpegsolitaire.desktop.in and put this in your makefile: glpegsolitaire.desktop: $(srcdir)/glpegsolitaire.desktop.in sed 's:@DATADIR@:$(datadir):' $(srcdir)/glpegsolitaire.desktop.in > glpegsolitaire.desktop.in Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: adding libraries and header file directories
"Jim Rainville" <[EMAIL PROTECTED]> writes: > Doh! Sometimes I fail to see the forest for the trees. So I copied the > link line and added the --perserve-dup-deps flag. Something weird > happens here. It's cutting off a lot of the file names. I thought at > first it was a copy and paste error but its not It is almost certainly a paste error. > [EMAIL PROTECTED] vlc-0.8.5]$ /bin/sh ./libtool --preserve-dup-deps > --mode=link --tag=CC gcc -Wsign-compare -Wall -pipe -o vlc vlc -vlc.o ^^^ > src/libvlc.a -Wl,--start-group -lelem_chkpt_api -lelem_chmgmt_api > -lelem_ core_api -lelem_mobj_api -lelem_fault_api -lelem_rel_api etc. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: How do I get configuration files installed?
Jim Lynch <[EMAIL PROTECTED]> writes: > I'm trying to figure out how to add a file to be installed in > $prefix/bin/lib. Are you sure you want that and not $libdir or even $datadir? > But when I put > bin_SCRIPTS=bin/float.pl bin/work.pl bin/lib/cipher.txt > in there, it simply puts ciper.txt in bin also. How can I tell it that I > want that file to end up in bin/lib? binlibdir = $(bindir)/lib binlib_DATA = bin/lib/cipher.txt Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Eric Blake <[EMAIL PROTECTED]> writes: > If they really want to stop parsing options, and pass all remaining > arguments to gcc, then they should be using -- between the options they > give gcc and the remaining arguments that they pass unchanged. Which unfortunately does not work since gcc interprets -- as an ambigous abbreviation instead of the end-of-option-marker. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > The issue is > much more special in this case: the FreeBSD compiler wrapper c89 > accepts the options > -MP -MD -MF -MT > > if they appear _after_ all the other command line arguments, The wrapper probably just stops parsing options at the first non-option, and passes all remaining arguments unchanged. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Forcing static link of libstdc++
Mike Melanson <[EMAIL PROTECTED]> writes: > If I install gcc 4.0.2 as a separate compiler on > an older machine, I wonder if it will be an option to link to > libstdc++.so.5? That won't work. The C++ runtime library is tightly coupled with the compiler. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: convenience libraries & binary size
Pieter Grimmerink <[EMAIL PROTECTED]> writes: > 1. move all >200 sourcefiles back into a single directory... > 2. stop using autotools, so we no longer need convenience libs to handle > subdirectories You don't need convenience libraries to handle subdirectories. Have you tried subdir-objects? (*Note (automake)Options::.) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: aclocal.m4 using m4_include or inlining macros?
Andreas Vinsander wrote: > Hi! > > I just saw that aclocal v1.9.6 did something I don't understand the > reason for. > > When doing aclocal -I ../../build_tools/m4, I end up with a aclocal.m4 > file having a m4_include([../../build_tools/m4/somemacroiuse.m4]) > > But when doing aclocal -I /home/proj/standalone/HEAD/drat/build_tools/m4 > (actually the same directory as before but with an absolute path), I end > up with aclocal.m4 containing the inlined macro instead of the include > directive. > > It still works fine, I am just curious to why this is happening. Forget this, I should have done more extensive RTFM... It's all in the info pages... /Andreas
aclocal.m4 using m4_include or inlining macros?
Hi! I just saw that aclocal v1.9.6 did something I don't understand the reason for. When doing aclocal -I ../../build_tools/m4, I end up with a aclocal.m4 file having a m4_include([../../build_tools/m4/somemacroiuse.m4]) But when doing aclocal -I /home/proj/standalone/HEAD/drat/build_tools/m4 (actually the same directory as before but with an absolute path), I end up with aclocal.m4 containing the inlined macro instead of the include directive. It still works fine, I am just curious to why this is happening. /Andreas
Re: How to build src/server and src/client separately?
Mark, Ralf, thank you very much for your replies! Works fine now, just what I wanted. Much appreciated! Thanks, Andreas -- Andreas "daff" Ntaflos Vienna, Austria GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 pgp6aXmAdIrhF.pgp Description: PGP signature
How to build src/server and src/client separately?
Hello list, I think this shouldn't be too difficult, but I couldn't find it in the automake manual (possibly because I don't know exactly what to look for). My project consists of $(topdir)/src/server and $(topdir)/src/client. Issuing `./configure && make' in $(topdir) correctly builds server and client, two otherwise unrelated programs. I would like to be able to issue `make' to build both (current behaviour) as well as `make server' and `make client' to build them separately if I want to do so. I'd appreciate it if anyone could point me to the right section in TFM or give me clues how to configure my project for the desired behaviour. Thanks in advance! Andreas -- Andreas "daff" Ntaflos Vienna, Austria GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 pgparBUvbUMkS.pgp Description: PGP signature
Re: mailing list administrivia (was: aclocal 1.9.6 and drive letters)
Bob Proulx schrieb: > > Ralf Wildenhues wrote: > > * Andreas Büning wrote: > > > Some weeks ago I sent a mail to the automake-patches mailing list > > > but it never appeared there. Then I tried the bug-automake > > > mailing list. I checked the mailing list archives on lists.gnu.org > > > my posting never appeared. > > > > That is weird, sounds like some spam filter gone too picky. > > Bob, Stepan? > > Your message to the automake list went through fine. And all of the > lists are configured virtually identically. The spam filtering is > identical between them although the list configurations are > independent. > > I looked through the spam trap archive and could not find any messages > posted from your address. I looked at the automake-patches list and > you are subscribed there where puts your address in the whitelist. No > checking will be done and any mail with your from address will pass > through without filtering. On the bug-automake list I see your > address in the whitelist which means messages from you were posted > there and accepted there previously as a non-subscriber and added to > the whitelist. > > Did you possibly post from a different address previously? No. > Was it > different form the one you just now used to post to the list? Slightly. I've attached the automatic replies. The first one also contains the original message. > I am not really sure what to suggest might be the problem. But it > would seem to be a problem between your site and the gnu.org site > where the messages never arrived at gnu.org. If you could look in > your MTA logs to see what the disposition of that message was it would > probably point to a problem there. What is an MTA log and where can I find it? Regards, Andreas BüningReturn-Path: <[EMAIL PROTECTED]> X-Original-To: [EMAIL PROTECTED] Received: from localhost (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id AF6B7CB43D for <[EMAIL PROTECTED]>; Sun, 7 May 2006 18:34:08 +0200 (CEST) Received: from mail-in-07.arcor-online.net ([127.0.0.1]) by localhost (mail-in-07 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27101-01-33 for <[EMAIL PROTECTED]>; Sun, 7 May 2006 18:34:08 +0200 (CEST) Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 1D507164062 for <[EMAIL PROTECTED]>; Sun, 7 May 2006 18:34:08 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FcmCs-00033x-Ex for [EMAIL PROTECTED]; Sun, 07 May 2006 12:34:06 -0400 Subject: The results of your email commands From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===2066722360==" Message-ID: <[EMAIL PROTECTED]> Date: Sun, 07 May 2006 12:34:02 -0400 Precedence: bulk X-BeenThere: automake-patches@gnu.org X-Mailman-Version: 2.1.5 List-Id: Patches for Automake X-List-Administrivia: yes Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-Virus-Scanned: amavisd-new at arcor.de X-DCC-servers-Metrics: mail-in-01-z2 1049; Body=1 Fuz1=1 Fuz2=1 X-Arcor-Antispam: SPF_PASS_AT_FORMER_RECEIVED X-Spamcount: -1 X-Spamsensitivity: 12 X-Mozilla-Status: 8001 X-Mozilla-Status2: X-UIDL: UID23111-1075230453 --===2066722360== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: I tried to use aclocal 1.9.6 on OS/2 and encountered the following problem: If using a drive letter for the installation path the $_ variable (see below) will contain something like "c:/usr/share/aclocal-1.9/init.m4:AC_INIT_AUTOMAKE.". This will obviously break when the split function is called because $file will be initializes to "c" and $macro to "/usr/share/aclocal-1.9/init.m4". Finally, init.m4 will not be considered as a file needed for aclocal.m4, and won't be included there. This means, AC_INIT_AUTOMAKE and all other standard macros won't be in aclocal.m4 and any call of automake will fail. I replaced split(/:/) by split (/(?<=3D\w\w):/) which will ignore the first colon if there aren't at least two characters before the colon. Maybe you'll find a better solution since I'm not a perl expert. --- old/automake-1.9.6/aclocal.in Sat Jul 9 11:28:44 2005 +++ gnu/automake-1.9.6/aclocal.in Sun May 7 00:51:24 2006 @@ -423,7 +423,8 @@ while ($_ =3D $tracefh->getlin
aclocal 1.9.6 and drive letters
Hello!
Some weeks ago I sent a mail to the automake-patches mailing list
but it never appeared there. Then I tried the bug-automake
mailing list. I checked the mailing list archives on lists.gnu.org
my posting never appeared. So I'm trying again on the automake
mailing list:
I tried to use aclocal 1.9.6 on OS/2 and encountered the following
problem: If using a drive letter for the installation path the $_
variable (see below) will contain something like
"c:/usr/share/aclocal-1.9/init.m4:AC_INIT_AUTOMAKE.". This will
obviously break when the split function is called because $file will
be initializes to "c" and $macro to "/usr/share/aclocal-1.9/init.m4".
Finally, init.m4 will not be considered as a file needed for aclocal.m4,
and won't be included there. This means, AC_INIT_AUTOMAKE and all other
standard macros won't be in aclocal.m4 and any call of automake will
fail.
I replaced split(/:/) by split (/(?<=\w\w):/) which will ignore the
first colon if there aren't at least two characters before the colon.
Maybe you'll find a better solution since I'm not a perl expert.
Regards,
Andreas Büning--- old/automake-1.9.6/aclocal.in Sat Jul 9 11:28:44 2005
+++ gnu/automake-1.9.6/aclocal.in Sun May 7 00:51:24 2006
@@ -423,7 +423,8 @@
while ($_ = $tracefh->getline)
{
chomp;
- my ($file, $macro, $arg1) = split (/:/);
+ # make sure that the filename does not start with a drive letter like
x:/usr/...
+ my ($file, $macro, $arg1) = split (/(?<=\w\w):/);
$traced{$macro} = 1 if $macro_seen{$macro};
Re: make distcheck not finding custom code generation script
On Saturday 13 May 2006 10:23, Ralf Wildenhues wrote: > The concept that is probably new to you is when source tree and build > tree are not the same. You can achieve that yourself (without > distcheck) by something like this: > mkdir build > cd build > ../source-tree/configure [OPTIONS] > make Ralf, thank you too very, very much for another great explanation! That concept was indeed new to me (autotools newbie), but now I understand well enough I think, which I am very happy about :) > BTW, what a well-written bug report! Why, thank you :) It got me at least two great answers so it was definately worth writing it. Thanks, once again! Andreas -- Andreas "daff" Ntaflos daff AT dword DOT org Vienna, Austria GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 GPG Public Key ID: 090CA9B4 GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc
Re: make distcheck not finding custom code generation script
On Saturday 13 May 2006 10:16, Andreas Ntaflos wrote: > It seems you replied off-list? Nevermind, I didn't realize the automake list was apparently CC'd. Need some sleep and better procmail rules. -- Andreas "daff" Ntaflos daff AT dword DOT org Vienna, Austria GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 GPG Public Key ID: 090CA9B4 GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc
Re: make distcheck not finding custom code generation script
On Saturday 13 May 2006 09:54, Brian Dessent wrote:
> So the answer to your question is that you shouldn't assume that you
> are in the source tree when referring to files. Try having your
> macro expand the path as "$(srcdir)/tools/wrapper.sh" instead of
> "../tools/wrapper.sh". I'm not entirely sure of the correct quoting
> here, but I'm pretty sure you want it to expand as $(srcdir) in the
> final generated Makefile rule, so this might involve quoting the ('s
> and )'s in m4, I don't know.
Brian,
I can't thank you enough for taking the time to read that long post of
mine /and/ reply with such a detailed and well-written explanation!
And of course you are correct, having the m4 macro expand the variable
to $(srcdir)/tools/wrapper.sh (and, along the same lines, rewriting the
build rule to refer to $(srcdir)/foo.ice) solved that problem just
fine!
About the quoting in the m4 macro:
ac_foo2cpp="\$(srcdir)/tools/wrapper.sh ${ac_foo2cpp}"
was apparently the right way to do this.
It seems you replied off-list? Would you consider posting to the list
what you wrote? Your explanation is definately worth archiving and I
know for a fact that many of my fellow students will be having similar
problems pretty soon.
If you don't want to I could forward your message or quote it in a
follow-up or whatever.
Again, thank you very much! You spared me a lot of further trouble :)
Andreas
--
Andreas "daff" Ntaflos
daff AT dword DOT org
Vienna, Austria
GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
GPG Public Key ID: 090CA9B4
GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc
make distcheck not finding custom code generation script
Hello list, this is my first post here, and it is regarding `make distcheck'. What I have to do is a bit tricky to explain but hopefully I can make myself clear enough to get some input from more experienced automake users than me (I am basically a newbie). I would really appreciate it. Background: To build successfully, my package needs two files (foo.cc and foo.hh) that are generated during build time from another file (foo.ice) using a special program, let's call it `foo2cpp'. This program's path is machine/installation dependent and is determined during configure time and set correctly by the m4 macro that checks for it. This m4 makro creates a Makefile variable $(ICE_FOO2CPP) which looks like this: `../tools/wrapper.sh /correct/path/to/foo2cpp'. You see, in the topmost directory of my package there is a directory `tools' which contains a `wrapper.sh' script. This is needed to set various paths (like LD_LIBRARY_PATH) in order for foo2cpp to run correctly on all test machines. So to translate foo.ice to foo.cc and foo.hh I need to run (in my $(topdir)/src subdirectory) ../tools/wrapper.sh /path/to/foo2cpp foo.ice In src/Makefile.am there is a target that does just that: foo.cc foo.hh: foo.ice $(ICE_FOO2CPP) foo.ice It does so very nicely. Remember $(ICE_FOO2CPP) is set during configure after the m4 macro checked for it. These generated files are of course not part of the distribution but are nodist_foo_SOURCES and set in BUILT_SOURCES, accoring to the automake info section on built sources. This part is working fine. I of course included the tools/wrapper.sh script in EXTRA_DIST in the top level Makefile.am. I am also including foo.ice in EXTRA_DIST of src/Makefile.am. What works: configuring and making the package is no problem at all, everything is set correctly and compiling fine. Making a distribution with `make dist' and then unpacking and building this distribution is also no problem. What doesn't work: The problem is that `make distcheck' fails right at the beginning of the build process, after configuring. It complains about not finding the tools/wrapper.sh script: make[1]: Entering directory `/path/to/foo_project/foo-1.0/_build' make all-recursive make[2]: Entering directory `/path/to/foo_project/foo-1.0/_build' Making all in src make[3]: Entering directory `/path/to/foo_project/foo-1.0/_build/src' ../tools/wrapper.sh /usr/bin/foo2cpp foo.ice make[3]: ../tools/wrapper.sh: Command not found Which is correct, there is no wrapper.sh script from where make distcheck is looking (i.e. from inside /path/to/foo_project/foo-1.0/_build/src). Also there are no other files in foo-1.0/_build/src, so even if the wrapper.sh script could be found it would choke on not finding foo.ice. The wrapper.sh script is in foo-1.0/tools where it belongs and where it is found fine when building a readily distributed package of foo (make dist). Question: The question is: what do I have to do to satisfy make distcheck about the location of the script? Or am I doing something wrong here? Did I forget to set a special variable that lets make distcheck know that there are files that need to be built from other files before being able to `make' anyting? Do I have to define the path to the script otherwise? Please note that I encountered the same problem when the wrapper.sh script was placed directly in the src/ subdirectory (and distributed correctly). Or did I hit a limitation of automake? Is it not able to deal with such things? To reiterate: building a `make dist'ed package works fine and so does building the package in it's root directory. It's just make distcheck that fails. Sorry for this much too long post, I hope I explained my problem well enough for somebody (who was brave enough to read it all) to be able to help me. Any help is appreciated! Especially RTFM answers that contain links to TFM and the relevant sections :) Thanks in advance! Andreas -- Andreas "daff" Ntaflos daff AT dword DOT org Vienna, Austria GPG Fingerprint:6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4 GPG Public Key ID: 090CA9B4 GPG Public Key: http://daffit.meownz.info/publickey/andreas_ntaflos.asc
Re: Broken makefile given Autoconf version mismatch
Keith Marshall <[EMAIL PROTECTED]> writes:
> Let me turn that around, and ask if you can provide any documentary
> evidence, other than anecdotal, to suggest that this use of semicolons
> *should* be supported? SUSv3 *expressly* demands that sed directives be
> separated by newlines:
> http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html
"The command can be preceded by s and/or semicolons. The function
can be preceded by s. These optional characters shall have no
effect."
"Command verbs other than {, a, b, c, i, r, t, w, :, and # can be followed
by a semicolon, optional s, and another command verb."
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Broken makefile given Autoconf version mismatch
Keith Marshall <[EMAIL PROTECTED]> writes: > On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote: >> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote: >> > here's a patch that I think does more or less what Bruno's patch >> > intends to do, against current CVS. >> >> I worked on the same issue. We both use the same pattern >> `sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...` > > I'd like, if I may, to sound a note of caution concerning this sed > command syntax: the use of semicolons as command separators in the sed > script is an implementation dependent extension, which is not portable. > On some platforms, the test using this sed syntax *will* fail, not > because the feature you are testing is unsupported, but because the test > itself is invalid. > > In November 2005, Robert Goulding posted these bug reports on > groff@gnu.org: > http://lists.gnu.org/archive/html/groff/2005-11/msg4.html > http://lists.gnu.org/archive/html/groff/2005-11/msg00074.html > > It turns out that Robert was having a problem building CVS groff, > which requires texinfo >= 4.8 to compile the info files, under Mac OS X, > and configure was saying his texinfo was too old, in spite of him having > explicitly just installed texinfo-4.8. The actual problem was that the > configure test employed a sed command with this same semicolon usage, > and was not behaving as expected -- the test failed because *it* was > invalid, *not* because the detected texinfo was too old! Is there any evidence that there exists a sed implementation that does not support the semicolon as command separator? Note that the thread you quote above is _not_ about semicolons being unsupported, but rather about missing ones. Autoconf is using semicolons in sed expressions already for many years (eg in the AC_OUTPUT_FILES macro). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: best aclocal include practice wanted
Thomas Porschberg <[EMAIL PROTECTED]> writes: > what is the recommended way to include project-written m4 macros ? Many projects use a directory named m4, but there is no common convention. > I include the macros in /config/m4 > and call in autogen.sh "aclocal -I config/m4" > > The config directory itself is configured in configure.ac > with AC_CONFIG_AUX_DIR(config). This macro is unrelated to the placement of the input files for aclocal. > Is there something wrong with this approach ? No. > What could be done better ? > How should autoreconf find the m4-macros in such a case ? Add this line to the toplevel Makefile.am: ACLOCAL_AMFLAGS = -I config/m4 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: build paths and generated sources
Thomas Porschberg <[EMAIL PROTECTED]> writes: > %.cpp %.h: %.ui > @UIC@ -o $(<:%.ui=%.h) $< > @UIC@ -i $(<:%.ui=%.h) -o $(<:%.ui=%.cpp) $< You should not use $< for constructing targets, only $@ will contain the right name to create. IIUC the commands are creating the each of two targets separately, thus you should use two separate rules: %.h: %.ui @UIC@ -o $@ $< %.cpp: %.h %.ui @UIC@ -o $@ -i $^ This make sure that each comand argument has the correct directory part. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Alternative compiling for debug/optimized code?
"Daniel Kraft" <[EMAIL PROTECTED]> writes: > Using automake the default compiler flags seem to be -g -O2; but most of the > time I don't need debug code You'll need it most when you don't have it. > so I want to disable that -g - option. ./configure CFLAGS=-O2 > And it is possible to do something similiar to the alternative compiling > described above - i.e. to have a simple way for switching opt/debug mode, > maybe > without having to reconfigure? make CFLAGS=-O2 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: shared library from smaller pieces
Vlad Skvortsov <[EMAIL PROTECTED]> writes: > When I use something like this: > > lib_LT_LIBRARIES = libbig.la > libbig_la_LIBADD = .../libaaa.la .../li.la .../libccc.la > > I end up with the shared library that contains _references_ to _shared_ > libraries aaa, bbb and ccc. But I just want their contents to be packed > inside. > > How can I achieve that? Make the small pieces convenience libraries, by using noinst_LTLIBRARIES. *Note (automake)Libtool Convenience Libraries::. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Moving from manual Makefiles to Automake
Paulo Jorge Matos <[EMAIL PROTECTED]> writes: > if g++ -DHAVE_CONFIG_H -I. -I. -I..-I./include -ansi -std=c++98 > -pedantic -Wall -DBUILDDATE=`date +'%Y-%b-%d %R'` -g -O2 -MT ^ You need to quote the output of the command substitution since it contains a space. -DBUILDDATE="`date +'%Y-%b-%d %R'`" Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: AM_FCFLAGS not working as I expect...
Ed Hartnett <[EMAIL PROTECTED]> writes: > What am I missing here? I define the following in my Makefile.am: > > # Point the fortran compiler to current directory. > AM_FFLAGS = -I$(srcdir) > > But no matter what I do, that -I. never appears when the compile > happens: > > f95 -g -O2 -ff2c -c typeSizes.f90 -fPIC -o .libs/typeSizes.o FFLAGS is only used for Fortran 77 compilations. For Fortran 9x compilations FCFLAGS is used. See Fortran 77 Support and Fortran 9x Support in the automake manual. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Defining Macros With Literal Values
Eric Lemings <[EMAIL PROTECTED]> writes: > Greetings, > > I have a tricky little problem I was hoping someone could > help me with. I am trying to write an Autotools macro that > extracts the value of a macro from a system header file > and defines another preprocessor macro with the same value. You can use AC_DEFINE_UNQUOTED to define a macro to the result of a shell substitution. You can easily extract the value from the output of the preprocessor. Don't use the output of a compiled program because that would make cross-compiling impossible. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: configure can not determin 'HAVE_LIMITS'
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. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Avoiding installation
John Kodis <[EMAIL PROTECTED]> writes: > I'd like a program to be built when I type "make", but not have it > installed when I type "make install". Is there a provision for this? Use the noinst prefix, like noinst_PROGRAMS. See (automake)Uniform. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: I can't get xxx_AR to work
Patrik Jonsson wrote: > I'm trying to convert my little project to autotools, and I'm running > into the problem that under AIX, to make a 64-bit library, you need to > pass -X64 as an option to ar. I've tried setting libmcrx_a_AR = > something, ARFLAGS =something and AR =something in the Makefile.am, but > no matter how I do this, the Makefile always comes out having: I had a similar problem and played around with it long time ago. The simplest (though inconvenient) way is to call 'make AR="ar -X64"' every time you need it. Otherwise, you could write some shell code in configure.ac to determine AR or ARFLAGS and to set them with AC_SUBST. I think this should work. Andreas
Re: Specifying AM_CPPFLAGS from within configure.ac
Jirka Hanika <[EMAIL PROTECTED]> writes:
> For example I'll try to upgrade the "unused variable" warning avoidance
> code to something like
>
> if (((int)argv) * ((int)argv) < 0 || argc < 0) printf("");
conftest.c: In function ‘main’:
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: zero-length printf format string
conftest.cc: In function ‘int main(int, char**)’:
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: warning: zero-length printf format string
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: .DELETE_ON_ERROR ?
Stepan Kasal <[EMAIL PROTECTED]> writes: > Hello, > I've just stumbled over this problem: > Makefile.am contains: > > foo.h: foo.x > $(GENERATOR) foo.x >foo.h > > But the GENERATOR command failed and I have empty foo.h. Use a temporary file and rename that afterwards. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: F90 vs. F77
Scott Kruger <[EMAIL PROTECTED]> writes: > I am using automake version 1.8.2 This is quite old, the latest version is 1.9.5. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: 5.9 The Future of `aclocal'
Bruce Korb <[EMAIL PROTECTED]> writes: > In fiddling with sharutils, I discovered that it is too early to encourage > the dropping of bootstrap scripts just yet. "autoreconf" does not provide > a way of convincing automake to run with the options, "--gnu" and > "--add-missing". Sure it does. "--gnu" comes from AUTOMAKE_OPTIONS in Makefile.am or from AM_INIT_AUTOMAKE, and "--add-missing" is added with "--install". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: CCing list replies (was: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?)
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > This is not addressed at me, but I also had to learn the hard way > that > - some gnu.org lists but not all automatically exclude subscribers if > they are listed in To: or Cc:. This is customizable, see the mailman options page. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: troubles with conditional install using automake
Stepan Kasal <[EMAIL PROTECTED]> writes: > Hi, > > while I am not able to address your main problem, I'd like to address one > misunderstanding of the make language: > > On Wed, Dec 01, 2004 at 03:29:10PM +0100, Guillaume Rousse wrote: >> initrd_SCRIPTS is defined to $(INITRD) at the beginning of the Makefile, >> while INITRD is defined at the end of the Makefile, with other >> conditional variables, and thus appears empty when it is evaluated. > > No, make doesn't work this way; consider the makefile: > > A = $(BB) > > e: > echo $(A) > > BB=x > > > Then ``make'' runs ``echo x'' But when $(A) appears on the dependency list of e, for example, it will be expanded already while the makefile is being read in. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Error because README is missing
"Paul D. Smith" <[EMAIL PROTECTED]> writes: > However, I actually had a second error that I didn't mention because I > figured it would be the same problem... but it's not. > > The second error is this: > > $ automake --add-missing --no-force > configure.in:398: required file `build.sh.in' not found > > This file is being created with this in my configure.in file: > > if test -f $srcdir/build.sh.in; then > AC_CONFIG_FILES(build.sh) > fi AC_CONFIG_FILES is a declaration-like macro, you can't execute it conditionallyon the shell level. If you want to make it conditional on the existence of the input file you need to do that on the m4 level. Untested code ahead. m4_syscmd([test -f build.sh.in])dnl m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)]) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Disabling optimization
"Thomas 'Tom' R. Treadway III" <[EMAIL PROTECTED]> writes: > CXXFLAGS="`echo $CXXFLAGS | sed -e 's|-O2||'`" This assumes that CXXFLAGS does not contain "-frob-O2any". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Disabling optimization
Stepan Kasal <[EMAIL PROTECTED]> writes:
> out of curiosity, what would be wrong with the following?
>
> if test -n "${CXXFLAGS}"; then
> CXXFLAGS="-g"
> fi
> AC_PROG_CXX
I think you got it backwards. This makes it impossible to override
CXXFLAGS.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
