Produce symlink into builddir on VPATH?
Other than resorting to the shell in a target, is there a way to cause Automake to produce a symlink from the source tree into the build tree if-and-only-if the build is VPATH? I've some non-generated Python code (srcdir) relying on generated Python code (builddir) and I'd like to be able to just use it from the builddir (hence the symlink from srcdir) without monkeying with PYTHONPATH. Thanks, Rhys
Re: install-strip variant that strips then installs?
So strip before install would not be portable. Drat. Thank you all for the ideas and explanations. - Rhys
Re: install-strip variant that strips then installs?
I'm tempted to believe the DESTDIR feature could be useful here with something like make install-strip DESTDIR=`pwd`/tmp and then copy files under 'tmp' into your final destination. This idea should cover what I need to do for a development/testing situation. Thank you. - Rhys
install-strip variant that strips then installs?
I gather that 'make install-strip' installs and then strips binaries. Is there some variant that reverses the order? If not, any recommendations for how to write one in an Automake-compliant manner? My unstripped binaries are absurdly large and my installation directory is NFS-mounted. So I get to pay lots of network overhead to install what eventually becomes O(100MB) of binaries because the unstripped copy is O(1.5GB). Thanks, Rhys
$(OBJEXT) equivalent for .lo files?
Hi all, Explicit dependencies look like foo.$(OBJEXT) : $(srcdir)/foo.F90 bar.$(OBJEXT) where $(OBJEXT) serves to insulate one from whether or not the suffix is .o for an object file. What's the $(OBJEXT) equivalent for a .lo file? I'm providing explicit dependencies for some Fortran files and need to express things like foo.lo : $(srcdir)/foo.F90 bar.lo Or, is the .lo extension guaranteed across platforms? Thanks, Rhys
Propagating $(FCLIBS) within a convenience library
Hi all, I believe this is Automake, but feel free to tell me to try the libtool lists... I've used AC_FC_LIBRARY_LDFLAGS to populate $(FCLIBS). Using libtool, I'm trying to compile a Fortran-based convenience library: AM_LIBTOOLFLAGS = --tag=FC noinst_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = module.F90 libfoo_la_LIBADD = $(FCLIBS) In another directory, I want FCLIBS to be propagated whenever I do something like libbar_la_LIBADD = ../anotherdir/libfoo.la. so that libbar.la doesn't need to know that libfoo used Fortran. I've noticed that this propagation seems to work for gfortran (judging from the contents of libfoo.la which will contain other .la files) but it does not for ifort (where libfoo.la lists none of the runtime libraries in .la form or otherwise). This confuses me. Am I misunderstanding something about LIBADD's behavior when $(FCLIBS) contains non-libtool libraries? Am I incorrectly expressing the dependency on the Fortran runtime libraries? Thanks, Rhys
Getting current directory name into mumble
If I'm underneath the subdirectory foo is there a way to get mumble$(subdir)else_SOURCES to be equivalent to specifying mumblefooelse_SOURCES? My goal is to get installed binaries where binary name depends on the subdirectory name. This is related to but different from program_transform_name a la autoconf. A couple of quick trials have all failed, e.g. HEYYOU = yesyou bin_PROGRAMS += helloworld$(HEYYOU) helloworld$(HEYYOU)_SOURCES = helloworld.cpp Thanks, Rhys
Re: Do convenience libraries propagate -R linker flags?
Hi Ralf, I've got a convenience library where the LDFLAGS includes -R: noinst_LTLIBRARIES = libsomething.la ... libsomething_la_LDFLAGS = -Rsomewhere and I indeed see -Rsomewhere appear within libsomething.la's dependency_libs line the way I expect. In another directory, I build a program depending on libsomething.la bin_PROGRAMS = myprog myprog_LDADD = ../lib/libsomething.la and then issue 'make install' to install it. After installation, I'm not seeing '-Rsomething' appear within the installed binary's rpath according to 'readelf -d myprog'. 'ldd myprog' issued after emptying my LD_LIBRARY_PATH confirms that -Rsomething isn't present. Should I expect -R flags provided at convenience library creation time to be propagated to an installed binary which uses that convenience library? I think they are not propagated currently for convenience archives. As to whether they should, I'm not sure. I remember that this has been reported before. I also remember that the issue has not been entirely noncontroversial. Somebody would have to dig in mailing list and commit history (of the Libtool project) to find out for sure. Thanks for the quick response. Took me a little time to do the digging... This same issue was reported and discussed within http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg5.html. Comically, I too am trying to use -R to have an installed binary automatically find the right Intel MKL installation. An earlier report is http://lists.gnu.org/archive/html/bug-libtool/2009-09/msg00037.html. Original reasons for the behavior apparently stem from http://lists.gnu.org/archive/html/libtool-patches/2003-03/msg00086.html. In http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00016.html Todd Gamblin says I imagine a lot of people probably expect the current behavior, so maybe the practical thing to do short-term is to fix the documentation... the manual still claims that -R gets propagated, but it looks like that hasn't been the case since 2003. That's not to say that I like the current behavior (I would like -R propagation) but I was surprised when this didn't work for me. which I'll second. The current documentation says, -R libdir If output-file is a program, add libdir to its run-time path. If output-file is a library, add -Rlibdir to its dependency_libs, so that, whenever the library is linked into a program, libdir will be added to its run-time path.) which I kept reading and thinking I doing something wrong. From what I can glean, that second sentence should be replaced with If output-file is a library, add -Rlibdir to its dependency_libs. However, subsequently linking a program against this library will not add libdir to the program's run-time path. To accomplish this aim, you must again supply -Rlibdir when linking the program. Any suggestions, aside from some minor sed work, for how to manually dig this -Rlibdir from a library's dependency_libs so it can be re-supplied? This way a program could poll libsomething.la for any -Rsomewhere information it provides. Mildly related, is there an option to insert content into inherited_linker_flags? I'm debating abusing inherited_linker_flags to accomplish -R propagation. This would allow a library to push -Rsomewhere information to others. Thank you for your time, Rhys
Do convenience libraries propagate -R linker flags?
Sort of an odd question at the intersection of automake and libtool... I've got a convenience library where the LDFLAGS includes -R: noinst_LTLIBRARIES = libsomething.la ... libsomething_la_LDFLAGS = -Rsomewhere and I indeed see -Rsomewhere appear within libsomething.la's dependency_libs line the way I expect. In another directory, I build a program depending on libsomething.la bin_PROGRAMS = myprog myprog_LDADD = ../lib/libsomething.la and then issue 'make install' to install it. After installation, I'm not seeing '-Rsomething' appear within the installed binary's rpath according to 'readelf -d myprog'. 'ldd myprog' issued after emptying my LD_LIBRARY_PATH confirms that -Rsomething isn't present. Should I expect -R flags provided at convenience library creation time to be propagated to an installed binary which uses that convenience library? If not, I'll stop trying. If so, I'll see if I can get a recreate for what I'm observing. Thanks, Rhys
Mucking with ltmain.sh
'Afternoon, I've run into a known libtool hiccup where '-fopenmp' is not stored within libsomething.la. Binaries later linked against libsomething.la run into linker problems because -fopenmp is not specified at link time. A workaround appears to be at http://lists.gnu.org/archive/html/bug-libtool/2011-03/msg00015.html which involves stitching up ltmain.sh. Can anyone recommend either a clean way to perform the ltmain.sh surgery at bootstrap? Or, better, does someone have experience manually stitching up inherited_linker_flags within libsomething.la? Thanks, Rhys
LTFCCOMPILE and FCFLAGS_f90
Hi all, I'm having a miserable time trying to figure out when LTFCCOMPILE picked up FCFLAGS_f90 per AC_FC_SRCEXT. Anyone know offhand what tool versions I need? Getting FCFLAGS_f90 handling right is important for gfortran pre-4.4's need for -x f95-cpp-input to play nice with libtool. Otherwise that flag treats all the object files as Fortran sources and (not surprisingly) blows up. :) - Rhys
mumble_LDADD before AM_LDFLAGS?
Hi all, I have a convenience library (say libconv.la) that depends on some external libraries kept in AM_LDFLAGS (say -L/opt/ext/lib -lext). If there a clean way to specify that libconv.la should appear in the link line before AM_LDFLAGS? Using mumble_LDADD places libconv.la after AM_LDFLAGS which fails to resolve the appropriate symbols. Workaround seem like they'd manipulate mumble_LDFLAGS and require messing with mumble_DEPENDENCIES... Thanks, Rhys
Disabling parallel builds in subdirectory
Within my Makefile.am I have the usual SUBDIRS = lib suzerain tests apps writeup which walks the subdirectories in my build tree. Is there some way to disable a parallel 'make -j#' build in just one subdirectory? Thanks, Rhys
Re: Disabling parallel builds in subdirectory
Is there some way to disable a parallel 'make -j#' build in just one subdirectory? You can put .NOTPARALLEL: in a Makefile.am, and GNU make and some versions of BSD make will not run things in parallel in this makefile. Thank you Ralf. Worked like a charm. - Rhys
Re: Can 'make ctags' create tags in top_builddir?
Could the ctags -a argument (or some other mechanism) be used to simulate the inclusion mechanism? AFAIK there is no such mechanism in ctags files, nor in vi or its clones who read tags files. It may be possible to use ctags' -a/--append option here. Maybe having 'make ctags' run in $top_builddir do something like rm -f $top_builddir/ctags. After that, the 'make ctags' target in all subdirectories appends to $top_builddir/ctags using 'ctags -a $top_builddir/ctags'. If that vague description sounds useful, I'll take a pass at getting it working. Let me know. If that's not something you think generally useful, I'm happy to stick to ctags -R for my own work. Thanks, Rhys
Re: Expressing non-source dependency for a VPATH build
That worked. I also ran across AC_CONFIG_LINKS which seems to be another option. Thanks Ralf, Rhys On Wed, Feb 11, 2009 at 1:05 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello Rhys, * Rhys Ulerich wrote on Wed, Feb 11, 2009 at 03:59:36AM CET: I've got an autotooled project which I can successfully configure/build using something like ../project/configure make. Is there some way to express a non-source dependency so that it gets picked up in a VPATH build? Maybe symlinked? Yes, you can add prerequisites to the all-local target. You can write rules for these prerequisites the same way you would write rules for them in a Makefile. Specifically, I've got a log4cxx.properties file used by my 'make check' tests. If I run 'make check' in a non-VPATH build the log4cxx.properties file is present and my tests output correctly. However, when I run 'make check' in a VPATH build my tests cannot find log4cxx.properties (its in the source tree, not the build tree) and they don't operate the way I'd like. Well, it depends on your specific setup whether symlinking/copying the file to the build tree is preferable, or using $(srcdir) appropriately elsewhere. If you decide to symlink/copy, you can use $(LN_S) (put AC_PROG_LN_S in configure.ac). In order to have a deterministic rule, input and output file should have different names (e.g., foo.in - foo) or not be identifiable by VPATH. Hope that helps. Cheers, Ralf
Expressing non-source dependency for a VPATH build
Hi all, I've got an autotooled project which I can successfully configure/build using something like ../project/configure make. Is there some way to express a non-source dependency so that it gets picked up in a VPATH build? Maybe symlinked? Specifically, I've got a log4cxx.properties file used by my 'make check' tests. If I run 'make check' in a non-VPATH build the log4cxx.properties file is present and my tests output correctly. However, when I run 'make check' in a VPATH build my tests cannot find log4cxx.properties (its in the source tree, not the build tree) and they don't operate the way I'd like. Any help appreciated, Rhys
Re: playing w/ GCC warnings
Some variation on the AC_COMPILE_WARNINGS macro at the cryp.to archive may be what you want (http://autoconf-archive.cryp.to/ac_compile_warnings.html). There are several other warnings-related macros there. - Rhys On Wed, Aug 13, 2008 at 7:07 AM, Thien-Thi Nguyen [EMAIL PROTECTED] wrote: What do people do to make experimentation w/ GCC warnings easy? In Guile-PG's configure.in, there is: |## If we're using GCC, ask for aggressive warnings. |if test x$GCC = xyes ; then | AGGRESSIVE_WARNINGS=-std=gnu99 -pedantic | for x in all extra float-equal declaration-after-statement \ | undef shadow pointer-arith cast-qual cast-align aggregate-return \ | old-style-definition no-missing-field-initializers \ | nested-externs inline volatile-register-var disabled-optimization |do AGGRESSIVE_WARNINGS=$AGGRESSIVE_WARNINGS -W$x | done |fi |AC_SUBST([AGGRESSIVE_WARNINGS]) and in the src/Makefile.am: | AM_CFLAGS = $(AGGRESSIVE_WARNINGS) $(MORE_AGGRESSIVE_WARNINGS) I do this in order to not touch CFLAGS. I wonder if this is contra-indicated somehow, and if not, if the result can be achieved in a better (more idiomatic, more standard) way. thi ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
