we'll need a proper disclaimer from *all* the people who have written
this code before incorporating it in the automake repository. So I ask:
Would you and the other people that have written this code be willing
to assign the copyright to the Free Software Foundation, so that we
On 1/12/12 2:16 PM, Bill Sacks sa...@ucar.edu 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
-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
Please
-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 recognized
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 -tp
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 -tp
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 = \
-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, Apr 4,
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
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.
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
-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 Jeff,
* Daily, Jeff A wrote on Mon
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.
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
Okay with a proper log entry, and crediting Jeff for the bug report,
including addition to THANKS (unless Jeff rejects that).
No need for testsuite exposure.
Credit is always appreciated, thank you.
Jeff
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 this
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
#*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)/build-aux/wapi.py $
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.
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
needs to
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 would be
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)
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
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 file and
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_PROGRAMS
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?
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
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
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:
if
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
31 matches
Mail list logo
