gpsd-dev
[Top][All Lists]
Advanced

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

Re: new challenges in scons cleaning, things basically ok


From: Bernd Zeimetz
Subject: Re: new challenges in scons cleaning, things basically ok
Date: Sun, 22 Dec 2019 19:03:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0


On 12/22/19 4:21 AM, Gary E. Miller wrote:

>> The other maybe-problem is that the provided LDFLAGS seem not to get
>> passed to the build of this test program, resulting in it not finding
>> some gtkmm stuff.   I realize that's fuzzy and will look into it post
>> release.
> 
> Yeah, that can wait.  As distros want to move to PIC, lto, etc, then
> LDFLAGS becomes important.


There are similar issues for CFLAGS, CPPFLAGS and others.
Scons munges and digests them into similar named, but different,
internal objects.

A bit of that mess is documented here:


commit d0e0864c2802860ff561fe0b39939b63d38b8c70
Author: Bernd Zeimetz <address@hidden>
Date:   Sun Jul 28 20:46:35 2019 +0200

    Fix the handling of defaults from the environment.
    
    The way whis was handled before had various issues:
    
    - scons' naming scheme for compiler flags is different from what we know
    from autotools and (afaik) all other build systems. As it seems to
    filter flags (or they are listed in the wrong environment variable and
    not used at the appropriate time), most of them get lost. So far I have
    not seen builds to fail becase of that.
    - to make sure flags end up in the appropriate setting, use
    env.MergeFlags for *FLAGS. This works well for me, but might break
    special CXX/CCFLAGS settings. So far I was not able to find a better way
    to handle this.
    - the lower/original MergeFlags part did not work at all as
      for flag in ....:
        if i in os.eviron:
    does not depend on the flag to be checked, but on the last checked flag
    from the loop before, where i was used. As TAR is usually not in the
    environment, this code was propably always dead.
    - the LD/SHLINK switch was done the wrong way around and was never able
    to work at all.
    
    tl;dr: the number of newly broken things is for sure less than the
    number of things that actually never worked before.
    
    Similar issues seems to exist in the part of the code where Python build
    configs are merged into the python env....



-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



reply via email to

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