Hello Alex,
On 28.03.2022 4:55, Alex Ameen wrote:
This is a message I meant send to "all", I'm sending again for the wider
discussion.
Please let me know if my understanding of include order is incorrect.
Essentially I'm more concerned about relative placement of `AM_CPPFLAGS'
and `CPPFLAGS'
Hello Karl,
On 28.03.2022 0:22, Karl Berry wrote:
It seems the basic inconsistency is whether CPPFLAGS is considered a
"user variable" or not. In earlier eras, it wasn't, but from your msg,
I gather it is now.
The GNU standards node about it, that you mentioned,
https://www.gnu.org/prep/sta
This is a message I meant send to "all", I'm sending again for the wider
discussion.
Please let me know if my understanding of include order is incorrect.
Essentially I'm more concerned about relative placement of `AM_CPPFLAGS'
and `CPPFLAGS' in any future changes.
Moving CPPFLAGS to the end of t
On Mon, 28 Mar 2022, Jan Engelhardt wrote:
I went to the GNU make git repo to check on CPPFLAGS; it appeared first in
documentation rather than source (which seems like a history import mishap),
but even back then in '94, the documentation was inconsistent, sometimes
providing example descriptio
On Sunday 2022-03-27 23:22, Karl Berry wrote:
>It seems the basic inconsistency is whether CPPFLAGS is considered a
>"user variable" or not. In earlier eras, it wasn't [...]
In earlier eras of what exactly?
As for make, it never made a distinction between user variables or otherwise,
at least
It seems the basic inconsistency is whether CPPFLAGS is considered a
"user variable" or not. In earlier eras, it wasn't, but from your msg,
I gather it is now.
The GNU standards node about it, that you mentioned,
https://www.gnu.org/prep/standards/standards.html#Command-Variables
does not clearl
Hello,
This discussion was started initially in the autoconf list. [1]
Automake and autoconf use compiler and preprocessor flags in different
order.
Within 'configure' scripts, compile checks/tests are performed as [2]:
$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&AS_MESSAGE_LOG_FD
but resulting
Hello Daniel,
* Daniel Neuberger wrote on Wed, Apr 20, 2011 at 03:56:15PM CEST:
> Is there any way to make a dependent library implicitly use any
> compiler flags used by a library on which it depends?
Not automatically. libtool has 'inherited_linker_flags', but it is not
appr
Is there any way to make a dependent library implicitly use any
compiler flags used by a library on which it depends? I'm running
into two problems that this would solve.
The first is illustrated by these Makefile.amS:
# libfoo
AM_CPPFLAGS = -I/some/include_path
lib_LTLIBRARIES = libf
Is there any way to make a dependent library implicitly use any
compiler flags used by a library on which it depends? I'm running
into two problems that this would solve.
The first is illustrated by these Makefile.amS:
# libfoo
AM_CPPFLAGS = -I/some/include_path
lib_LTLIBRARIES = libf
). In this (upcoming)
release I also include a configure option --disable-flag-setting,
which the user can use to turn off all these attempts to set compiler
flags. Then he is on his own.
This is the compromise I've stuck. Do you think it's a good approach?
And thanks for all
>>> "gd" == Guido Draheim <[EMAIL PROTECTED]> writes:
[...]
gd> (a) per file compile flags:
gd> - it's an faq and later automake supports it natively
This has yet to be implemented (any taker?). What Automake
supports presently is per-target flags. The usual way
to emulate per-object flags i
Markus Werle wrote:
Hi!
Consider the following case:
File VeryImportant.C contains code that really needs some
optimization available. But all other files could (at least during development)
be compiled without optimization, for the sake of not drinking too much coffee
due to long compilation ti
Hi!
Consider the following case:
File VeryImportant.C contains code that really needs some
optimization available. But all other files could (at least during development)
be compiled without optimization, for the sake of not drinking too much coffee
due to long compilation times.
Is there a conv
This is an autoconf.at.gnu.org question...
Michael Lemke wrote:
Today I've been trying to learn automake&autoconf. Something I can't
figure out although it is the main reason I am investigating automake:
How do I set compiler flags based on the compiler? For example, g77
req
Today I've been trying to learn automake&autoconf. Something I can't
figure out although it is the main reason I am investigating automake:
How do I set compiler flags based on the compiler? For example, g77
requires -fdollar-ok but Sun Fortran won't like that. How can
On Mon, 20 Nov 2000, Tim Heath wrote:
> AM_CXXFLAGS = -D_POSIX1C_SOURCE -D_HPUX_SOURCE -D_REENTRANT
[...]
> If you know of a better way please feel free to share it with me. I am
> interested in how to do and if/then to use this only if I am compiling
> on HPUX 11.0 with aCC etc.
Why only wi
" == Simon Richter <[EMAIL PROTECTED]>
>writes:
>
> >> On Fri, 17 Nov 2000, Tim Heath wrote:
> >> How do I add compiler flags? What AM is necessary to accomplish that?
>
> Simon> Make your configure.in add them to $CFLAGS, before AC_PROG_CC
> Simon>
compiling
on HPUX 11.0 with aCC etc.
Tom Tromey wrote:
>
> >>>>> "Simon" == Simon Richter <[EMAIL PROTECTED]>
>writes:
>
> >> On Fri, 17 Nov 2000, Tim Heath wrote:
> >> How do I add compiler flags? What AM is necessary to accomplish
>>>>> "Simon" == Simon Richter <[EMAIL PROTECTED]>
>writes:
>> On Fri, 17 Nov 2000, Tim Heath wrote:
>> How do I add compiler flags? What AM is necessary to accomplish that?
Simon> Make your configure.in add them to $CFLAGS, before AC_PROG_CC
S
Hi,
On Sat, Nov 18, 2000 at 06:41:17PM +0100, Simon Richter wrote:
> On Fri, 17 Nov 2000, Tim Heath wrote:
>
> > How do I add compiler flags? What AM is necessary to accomplish that?
>
> Make your configure.in add them to $CFLAGS, before AC_PROG_CC (to make
> sure
On Fri, 17 Nov 2000, Tim Heath wrote:
> How do I add compiler flags? What AM is necessary to accomplish that?
Make your configure.in add them to $CFLAGS, before AC_PROG_CC (to make
sure the compiler actually accepts them).
Simon
--
GPG public key available from h
On Fri, 17 Nov 2000, Tim Heath wrote:
> I don't know of a way to use a #define within a source file for a
> compiler flag. Can you tell me the other way to accomplish this goal?
-D is the compiler flag for "add this definition as if it were
#defined". Thus, the source should begin with
#defin
I seem to remember that the documentation suggests adding them to
INCLUDES:
INCLUDES = -D_POSIX1C_SOURCE -D_HPUX_SOURCE -D_REENTRANT
--
Paul Berrevoets
Tim Heath wrote:
> I have to add to DEFS:
>
> -D_POSIX1C_SOURCE -D_HPUX_SOURCE -D_REENTRANT
>
> in my Makefile.
>
> Is there a way to automate
How do I add compiler flags? What AM is necessary to accomplish that?
Thanks,
Tim Heath
On Thu, 16 Nov 2000, Tim Heath wrote:
> -D_POSIX1C_SOURCE -D_HPUX_SOURCE -D_REENTRANT
> Is there a way to automate this with an AM or something?
There is, in fact, but these definitions are better placed as "#define"s
at the beginning of source files. This way, you can easily tell from the
sour
I have to add to DEFS:
-D_POSIX1C_SOURCE -D_HPUX_SOURCE -D_REENTRANT
in my Makefile.
Is there a way to automate this with an AM or something?
Thanks,
Tim Heath
27 matches
Mail list logo