texinfo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [6465] small fixes for XSParagraph


From: Dagobert Michelsen
Subject: Re: [6465] small fixes for XSParagraph
Date: Mon, 27 Jul 2015 08:34:03 +0200

Hi Gavin,

Am 27.07.2015 um 02:24 schrieb Gavin Smith <address@hidden>:
> On 27 July 2015 at 00:21, Karl Berry <address@hidden> wrote:
>>    +# Clear any flags set by configure at the top level, because the
>>    +# compiler used in this subdirectory might be different.
>>    +CFLAGS =
>> 
>> That doesn't seem right.  CFLAGS is supposed to be explicitly reserved
>> for users in the GNU world, and presumably those flags should still be
>> passed.  (Or a different user-reserved variable, maybe, since it's
>> possibly a different compiler.)
> 
> I was aware that this didn't match the GNU Coding Standards for
> Makefiles; however, I figured that these didn't fit when there were
> multiple compilers being (possibly) used in a single project. A
> different variable is probably what is needed, maybe "PERLCFLAGS" or
> "XSCFLAGS" or "EXTENSIONCFLAGS".
> 
>> To eradicate all configure-determined flags, I think several
>> other variables would have to be reset, since the basic compile command
>> looks like:
>> COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
>>        $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
>> 
>> But one would hope that there is a way to do this that does not involve
>> embedding such knowledge of how automake implements compilation ... -k
> 
> It's not as bad as that; it's only the user variables that are likely
> to be set on a configure run that need to be overridden, and these
> should be documented. I cleared CFLAGS after configuring with
> "./configure CFLAGS=-Wall" at the top-level, which broke when the
> compiler in the XSParagraph subdirectory didn't recognize the -Wall
> option. In this case it wasn't "configure-determined", that is not
> automatically determined, but user-provided.

From a downstream packager perspective this is IMHO acceptable. If you
are using different compilers it is your fault and you have to deal with
it. Trying to make this easier is commendable but leaving it as is would
be ok too. (I know what I am talking about - we are transitioning from
Sun Studio to GCC for quite a while now and the problems you are citing
happens from time to time).


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]