Hi Ralf,
I have been struggling with the 'single file disable optimization
issue' for a while and used to have a somewhat ugly solution up to
this point.
The recent fixes in automake that ensure that target_??FLAGS always
overrides AM_??FLAGS make your suggestion a valid solution now.
In
tember 2005, but unfortunately http://
sources.redhat.com/ml/automake/2005-09/ seems to come up empty :(
Below is a copy of an e-mail I send to the list back then.
On 26-sep-2005, at 11:09, Sander Niemeijer wrote:
On zaterdag, sep 24, 2005, at 20:05 Europe/Amsterdam, Brian wrote:
I have a need
Hi,
I do not know whether it is recommended behavior, but you could add
the following to the top of your Makefile.am
---
F77=$(FC)
FFLAGS=$(FCFLAGS)
---
and only use a AC_PROG_FC in your configure.ac.
This is what I usually do when I have mixed F77/F90 code.
Best regards,
Sander
On 8-jan-20
Hi,
On 4-jan-2006, at 21:00, Stepan Kasal wrote:
Hello,
On Wed, Jan 04, 2006 at 06:12:11PM +0100, Sander Niemeijer wrote:
distdir: $(DISTFILES)
$(am__remove_distdir)
mkdir $(distdir)
--->$(mkdir_p) $(distdir)/$(top_srcdir)/data
The problem is caused by the follow
; != "."; then \
dir="/$$dir"; \
$(mkdir_p) "$(distdir)$$dir"; \
else \
dir=''; \
fi; \
---
which seems to take care of creation of the directory if it did not
already exist.
foo-1.0.tar.gz
Description: GNU Zip compressed data
Best regards,
Sander Niemeijer
On woensdag, sep 28, 2005, at 17:04 Europe/Amsterdam, Harald Dunkel
wrote:
autoconf sets CFLAGS/CXXFLAGS to "reasonable defaults", that's all. If
these defaults cause problems on your platforms, you have to override
them.
They cannot be called "defaults", if they get a higher priority
than
Hi All,
On woensdag, sep 28, 2005, at 06:24 Europe/Amsterdam, Ralf Corsepius
wrote:
On Tue, 2005-09-27 at 19:38 -0600, Brian wrote:
We have several files which are not able to be optimized, and when
our mac
mini tries to build the project it chokes up when attempting to do
so. It
seems inco
copy foo.c from the
source directory to the Makefile directory (this rule also works when
you use separate source and build directories):
---
foo.c: $(top_builddir)//foo.c
cp `test -f '$(top_builddir)//foo.c' || echo
'$(srcdir)/'`$(top_builddir)//foo.c foo.c
---
Best regards,
Sander Niemeijer
On vrijdag, dec 10, 2004, at 21:35 Europe/Amsterdam, Alexandre
Duret-Lutz wrote:
user_CFLAGS=$CFLAGS
AC_PROG_CC
if test "x$user_CFLAGS" = x; then
# If the user didn't specify CFLAGS, then CFLAGS contains
# a subset of -g -O2 selected by AC_PROG_CC. This is not
# a user setting, and we want
user_CFLAGS=$CFLAGS
AC_PROG_CC
if test "x$user_CFLAGS" = x; then
# If the user didn't specify CFLAGS, then CFLAGS contains
# a subset of -g -O2 selected by AC_PROG_CC. This is not
# a user setting, and we want to be able to override this
# locally in our rules, so put these flags in a sepa
On vrijdag, dec 10, 2004, at 21:39 Europe/Amsterdam, Alexandre
Duret-Lutz wrote:
That documentation was delivered to your mailbox 10 days ago.
It will be in 1.9.4.
From: Alexandre Duret-Lutz <[EMAIL PROTECTED]>
Subject: RFC for new FAQ entry: Flag Variables Ordering
To: [EMAIL PROTECTED]
kefile.in aclocal.m4 compile config.guess config.sub configure \
config.h.in depcomp install-sh ltmain.sh missing py-compile ylwrap
if test "$1" != "clean" ; then
# bootstrap
echo "---autoreconf---"
autoreconf -v -i -f
fi
---
Feel free to use this as a temp
On dinsdag, maa 9, 2004, at 23:04 Europe/Amsterdam, Bob Friesenhahn
wrote:
Wildcards are for lazy programmers who are willing to allow wrong
files to be built or distributed by accident.
I don't agree when it comes to a bunch of files (>100) that get
generated automatically by a tool (such as do
On vrijdag, maa 5, 2004, at 19:54 Europe/Amsterdam, Hans Deragon wrote:
Sander Niemeijer wrote:
Hi Hans,
Automake does not support wildcard specification of files (e.g. whole
directories). This is to make sure that:
- a 'make dist' only includes those files from your subdirectories
t
Hi Hans,
Automake does not support wildcard specification of files (e.g. whole
directories). This is to make sure that:
- a 'make dist' only includes those files from your subdirectories that
really should go in a distribution
- a 'make distcheck' is able to check whether any generated files in
really welcome it if
automake would gain support for installing libtool libraries in the
appropriate order.
Regards,
Sander Niemeijer
On donderdag, jan 15, 2004, at 21:03 Europe/Amsterdam, Bob Friesenhahn
wrote:
I am using Automake 1.8 with libtool. Automake is doing a good job at
building
Hmmm... Seems I failed to read the right postings in the autoconf
archive.
I did some catching up and it all makes sense now. Sorry for the
noise...
Regards,
Sander
On donderdag, okt 9, 2003, at 20:29 Europe/Amsterdam, Steven G. Johnson
wrote:
On Thu, 9 Oct 2003, Sander Niemeijer wrote:
I can
Hi,
I can understand keeping F77/FFLAGS/FLIBS/AC_PROG_F77 for backwards
compatibility.
However, the current approach is to keep using these macros and
variables for f77 and use the new FC* ones only for f90 and upwards. My
question is whether it is not possible to also include f77 in the FC
ap
Yes. At least for libraries. For libtool you use noinst_LTLIBRARIES to
create convenience libraries. These are often used as intermediate
libraries for a series of object files that are later on included in a
final executable or library which /will/ be installed.
Regards,
Sander
On maandag, sep
. And of course the biggest advantage is that
automake now only creates one rule to generate foo.h.
Regards,
Sander
On woensdag, sep 17, 2003, at 12:12 Europe/Amsterdam, Sander Niemeijer
wrote:
Hi all,
I am using a yacc/bison source file in a libtool library, but I create
both an installable
single .y file that reproduces the problem.
Regards,
Sander Niemeijer
FYI: It is indeed possible to have libtool create static libraries even
when you provided --enable-shared and --disable-static to ./configure.
This happens for instance if you use options like:
libfoo_la_CFLAGS = -static
libfoo_la_LDFLAGS = -static
Regards,
Sander Niemeijer
On vrijdag
Hi,
I have a package that uses multiple makefiles: one toplevel makefile
and some makefiles in subdirectories.
The build in several of these subdirectories requires the use of a
single include file (lets call it foo.h) that is created from foo.h.in
by configure. Now I recently discovered that a
,
Sander Niemeijer
On Monday, Feb 3, 2003, at 23:20 Europe/Amsterdam, [EMAIL PROTECTED]
wrote:
I have a shell script which I want to run as part of a testsuite.
However
when I do a 'make distcheck' this script (which does not get
configured or
anything at build time) ends up wi
w whether that could brake any other
packages (like e.g. autoconf) that might depend on this macro. Anybody
any idea about that?
Regards,
Sander Niemeijer
25 matches
Mail list logo
