On 1/12/12 2:16 PM, "Bill Sacks" wrote:
> I work on a climate model (CESM); this is mostly written in Fortran 90, with a
> bit of C, but we are starting to add some C++ code, too. Until now, we have
> used our own, custom build system, but as the build becomes more complex, we
> are thinking of m
> -Original Message-
> From: automake-bounces+jeff.daily=pnl@gnu.org [mailto:automake-
> bounces+jeff.daily=pnl@gnu.org] On Behalf Of
> adrianc...@hotmail.co.uk
> Sent: Tuesday, October 25, 2011 11:31 PM
> To: automake@gnu.org
> Subject: Automake: How to force dynamic linking
>
> P
> -Original Message-
> From: automake-bounces+jeff.daily=pnl@gnu.org [mailto:automake-
> bounces+jeff.daily=pnl@gnu.org] On Behalf Of Nicolai Stange
> Sent: Friday, July 29, 2011 2:17 AM
> To: automake@gnu.org
> Subject: Fortran and AC_DEFINE's
>
> Howdy everybody,
>
> we r
I'm using automake 1.11.1 and I was puzzled why "checking dependency style of
pgcc" would result in "none". It's a fairly modern compiler, right? I dug a
little deeper. It looks like pgcc has some options for generating Makefile
output.
$ pgcc -V
pgcc 11.2-0 64-bit target on x86-64 Linux -
I'm using automake 1.11.1's 'parallel-tests' test suite capabilities. It's
been fine so far. I even hacked it a little to support launching my MPI
programs. I have some tests that run serially (without MPI) and some that
do:
TESTS = $(SERIAL_TESTS) $(PARALLEL_TESTS)
LOG_COMPILER = \
maybe_mpi=`
> -Original Message-
> From: automake-bounces+jeff.daily=pnl@gnu.org [mailto:automake-
> bounces+jeff.daily=pnl@gnu.org] On Behalf Of Reuben Hawkins
> Sent: Tuesday, April 05, 2011 12:18 AM
> To: Reuben Hawkins; automake@gnu.org
> Subject: Re: install to top_builddir
>
> On Mon, Ap
> -Original Message-
> From: Daily, Jeff A
> Sent: Friday, February 25, 2011 10:05 AM
> To: 'Ralf Wildenhues'; 'John Calcote'
> Cc: automake@gnu.org
> Subject: RE: dynamic executables for check_PROGRAMS?
>
> > -Original Message-
I wrote a profiling layer for my library utilizing weak symbols. I thought for
starters it would be nice to profile some of my test programs, to make sure
things are working okay. I'm using autoconf, automake, and libtool, so I
configured using --enable-shared --disable-static, however, my tes
> From: automake-bounces+jeff.daily=pnl@gnu.org
> [automake-bounces+jeff.daily=pnl@gnu.org] On Behalf Of Ralf Hemmecke
> [hemme...@gmail.com]
> Sent: Friday, February 11, 2011 11:18 AM
> To: automake@gnu.org
> Subject: Test support for automake
>
> I have a non-recursive Makefile.am with
I'm aware of GNU make's text processing functions. Specifically, I'm looking
for the $(strip string) functionality, but hopefully portable. Is this
functionality available portably? Thanks.
> -Original Message-
> From: Ralf Wildenhues [mailto:ralf.wildenh...@gmx.de]
> Sent: Monday, November 29, 2010 2:33 PM
> To: Daily, Jeff A
> Cc: automake@gnu.org
> Subject: Re: make distclean fails for conditional nested package with VPATH
> build
>
> Hello
I had a user point out that "make distclean" from within their VPATH build
failed due to a missing, optional nested package. The nested package is called
"tascel". I have in configure.ac:
AC_ARG_ENABLE([tascel], [omit for brevity], [], [enable_tascel=no])
AM_CONDITIONAL([ENABLE_TASCEL], [test
Some of my test programs require generated input files - perhaps one per test
program. I want to generate them as dependencies of the particular test
programs which use them. However, I don't want to replace the dependencies
which automake already determines for my test programs. maude_DEPEND
I should note first there was a similar question sent to the list, but the
solution doesn't work for me since my case is slightly different.
http://lists.gnu.org/archive/html/automake/2010-03/msg00059.html
I have an assembly file which is generated from a C file. The C file uses GCC
inline as
I feel a bit silly pointing out something so trivial, but while looking at my
configure --help output, I notice that the help messages generated for
AM_SILENT_RULES are the only ones not aligned with the rest. Any reason this
can't be fixed?
Thanks.
Jeff
> Weird. I cannot reproduce your issue with that make version on
> GNU/Linux.
>
> Which file system does this happen on, maybe a case-insensitive one and
> there is another file in the source or the build tree matching the name
> (or parts of the dirname) case-insensitively?
Great tip! I forgot
> > > Which make version and implementation,
>
> Please answer this one as well.
Sorry for missing that. GNU Make 3.81 built for i386-apple-darwin9.0.
> > #*snip*
> > BUILT_SOURCES =
> > lib_LTLIBRARIES = libfoo.la
> > libfoo_la_SOURCES =
> > #*snip*
> > If HAVE_PYTHON
> > BUILT_SOURCES += foo/bar/wapi.c
> > foo/bar/wapi.c: foo/bar/papi.h $(top_srcdir)/build-aux/wapi.py
> > -rm -f foo/bar/wapi.c && \
> > $(PYTHON) $(top_srcdir)/bu
I have almost the same situation as a post many years ago. The solution didn't
seem to apply, however,
http://www.opensubscriber.com/message/automake@gnu.org/3498366.html
I am using subdir-objects and I have a single, top-level Makefile.am:
#*snip*
BUILT_SOURCES =
lib_LTLIBRARIES = libfoo.la
l
> So one complication with Fortran modules is that we don't know the
> order
> in which we need to compile files for the first time. If you want to
> allow file edits to arbitrarily change where modules are defined in,
> then this is true for rebuilds as well. So module dependency tracking
> need
> > Why doesn't automake have dependency tracking for preprocessed
> Fortran?
>
> Because nobody has implemented it yet.
>
> Well, I guess dependency tracking could be implemented similarly to how
> it is done for C and C++. Using makedepend could be a start, sure, but
> testing for a depmode wo
Why doesn't automake have dependency tracking for preprocessed Fortran?
Wouldn't the following work? Note that there is a space before include so that
automake doesn't process it, but rather it appears verbatim in the generated
Makefile.in.
F77DEPMODE = makedepend
.F.o:
$(AM_V_PPF77) \
> Just add your own rule that depends on $(check_PROGRAMS):
>
> .PHONY: check-norun
> check-norun: $(check_PROGRAMS)
>
> and type `make check-norun' instead of `make check'.
I copied the above from the link since I had trouble navigating to it.
This is a great solution for building the check_PRO
> > Ok, fair enough. But what's the easiest way to create a new
> recursive
> > target such as checkprogs? Hopefully there's a more or less
> automatic
> > way using automake.
>
> No, it's not, which is a real bummer. Best you can do is somehow copy
> the $(RECURSIVE_TARGETS) rule as a fragment
> > I attempted to split the "make check" target into "make check"
> > (build check_PROGRAMS) and "make test" (run check_PROGRAMS).
> > However, I get warnings that check-am was overridden. How might I
> > split the building and running of check_PROGRAMS and still use the
> > generated parallel-te
I attempted to split the "make check" target into "make check" (build
check_PROGRAMS) and "make test" (run check_PROGRAMS). However, I get warnings
that check-am was overridden. How might I split the building and running of
check_PROGRAMS and still use the generated parallel-tests using TESTS?
> I have a case where sometimes I want to compile fortran code with a C
> interface, and sometimes I do not. In this case, I ran into the linker
> problem, and I ended up substituting in the configure script as you
> mention. Here is a snippet of what I do in configure.ac. In this case
> I am using
> > > > But regardless of whether NOFORT is true, the Fortran linker is
> > > > always chosen. What should I be doing? Thanks.
> > >
> > > Override FCLD (if Makefile-global is acceptable) or
> > > libtest_la_LINK.
> > >
> >
> > Just to clarify, I'm using F77 and libtool. After looking at one of
> > The documented automake behavior states that automake chooses the
> > linker based on a static list of source files. This is not
> > sufficient. I'm hoping I've missed a detail somewhere, but my
> > experience backs up the documented claims. I've tried using
> > AM_CONDITIONALs like so:
> >
I am familiar with the automake documentation section How the Linker is Chosen
as well as the nodist_EXTRA_..._SOURCES trick described in the Libtool
Convenience Libraries section. I'm using the bleeding edge releases of
autoconf, automake, and libtool (2.65, 1.11.1, 2.2.6b).
We have a mixed F
30 matches
Mail list logo
