Message: 4
Date: Wed, 10 Dec 2008 07:39:04 +0100
From: Ralf Wildenhues <[EMAIL PROTECTED]>
Subject: Re: GNU Make Extensions
To: Tom Browder <[EMAIL PROTECTED]>
Cc: automake@gnu.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Hello Tom,
* Tom Browder wrote on Wed, D
>From: Ralf Wildenhues <[EMAIL PROTECTED]>
>
>Wow. It would be interesting to see how much faster things get with the
>chances. Are the libraries all created with libtool? Because then I
>guess they will end up being the remaining bottleneck (that would be
>interesting to see, too).
>
>> If in
Is there a good/easy/maintainable way to set the same CFLAGS/CPPFLAGS
for the entire project except for one specific subtree?
I'm using a recursive automake build where a few flags are default
set by configure (e.g. overrides the default "-O2 -g" to different
flags). I'd like to enable m
Counterproductive presumptuous flamings aside, there are compelling
arguments on both sides of the issue for having or quelling verbose
compilation output. Depending on at least the development
environment, requirements, expectations, and values of the
developers, I've been in situations w
Apologies on the delayed reply, but I felt like taking the bait..
I respectfully and fully disagree that running make in a subdirectory is
admission of anything other than a need to clean some a subset of a given
project in a convenient manner. The reason someone might want to do a make
clean
Ralf Corsepius <[EMAIL PROTECTED]> wrote:
scripts that give you information like includes, libraries,
etc... is there
some autoconf/automake/other magic i can use to automatically
generate one
of these for my distribution?
Nope. Such *-config scripts are ordinary, manually written
applicatio
m is regardless of their usage or
situation can be provided like found on the BMW by a AM_CC_FILTER or somesuch,
even better. ;-)
Cheers!
Sean
On Thursday, May 25, 2006, at 01:59AM, Ralf Wildenhues <[EMAIL PROTECTED]>
wrote:
>Hi Sean,
>
>* Christopher Sean Morrison wrote on
On Wed, 2006-05-24 at 13:57 +0200, Ralf Wildenhues wrote:
[snip..]
- Non-recursive makefiles are suitable for projects of mediocre
complexity. For complex projects the price of flat Makefile is high
and
often doesn't pay off.
Hear hear! After spending a fair bit of time considering the non
Date: Mon, 24 Apr 2006 23:29:34 +1000
From: Brendon Costa <[EMAIL PROTECTED]>
Subject: Re: Reducing verbosity of automake
To: automake@gnu.org, Brendon Costa <[EMAIL PROTECTED]>
All patches I've seen add quite a bit of bloat to Makefile.in's, for
dubious value (remember the compile rules may be
charset=us-ascii
Hello,
On Tue, Jun 28, 2005 at 01:42:19PM -0400, Christopher Sean Morrison
wrote:
AM_INIT_AUTOMAKE
...
AM_INIT_AUTOMAKE([no-dependencies])
I think that this option tells automake to generate different
Makefile.in,
which is horter and doesn't include
Thanks for the tip and it does look useful, though that doesn't affect
whether or not all compilations are run through depcomp does it? Our
non-CVS source distributions are easily treated as static sources that
won't change much beyond simple build tweaking and minor bug fixing.
So the extra
Hello,
I've have a section in a configure.ac that attempts to dynamically
determine whether or not to enable dependency tracking and it seems to
be causing quite a bit of hassle on at least some versions of automake.
Basically, I have the following:
AC_MSG_CHECKING([whether dependency track
MAKE="env PERL5LIB=./lib `pwd`/automake --amdir=."
AC_PATH_PROG(PERL, perl)
if test -z "$PERL"; then
Enjoy,
Dave
--
David Morrison Brookhaven National Laboratory phone: 631-344-5840
Physics Department, Bldg 510 Cfax: 631-344-3253
Upton, NY 11973-5000 email: [EMAIL PROTECTED]
h to protect that line with something like
if (defined $extension_map{$key}) {
...
}
but I don't know if that would break something else somewhere else.
Dave
--
David Morrison Brookhaven National Laboratory phone: 631-344-5840
Physics Department, Bldg 510 Cfax: 631-344-3253
14 matches
Mail list logo
