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

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

$(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

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

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

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

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

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

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

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

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

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

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

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