gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] patches from pkgsrc: SConstruct


From: Greg Troxel
Subject: Re: [gpsd-dev] patches from pkgsrc: SConstruct
Date: Thu, 20 Jun 2019 10:17:40 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

> Yo Greg!
>
> On Wed, 19 Jun 2019 20:28:17 -0400
> Greg Troxel <address@hidden> wrote:
>
>> scons appears to nuke the environment, which I realize has pluses and
>> minuses.
>
> I wish it was that simple...
>
> Thinks like CFLAGS, LDFLAGS, etc. often over write scons decisions.

That's a matter of opinion about how that should work; tradtionally
those are inputs to the build and should be respected (i.e., just added
to).  But that's not the issue.


>> And same issue for using ccache.
>
> AFAIK, gpsd does not use that.  Why would you bother to speed up
> recompilation unless you were developing?  And then I would not
> trust it.

It's not about whether gpsd "uses" ccache.  It's about whether the
person/system compiling gpsd is using ccache.

It's quite trustworthy; it hashes the inputs.  I have found about one
issue in over 10 years, due to fs corruption of cache files.

I use it because pkgsrc rebuilds packages when dependencies change, and
often most .c files don't really need recompilation.  It often saves 50%
of the build time in a "rebuild packages" run.

>> I would think that people on other
>> systems would have trouble with ccache not finding the cache dir.
>> There seems to be a tradition of accomodating many build systems; I
>> can change the style to match and push myself if this would be
>> acceptable.
>
> Have at it, if you can keep it from interfering with normal functions.
>
> Passing some environment variables seems benign.  I hope.

OK - I was only wanting to add these two, which if anybody has set they
want preserved.

> Just be careful to pull just before committing.  I have also been working
> in SConstruct and GitLab does not hanlde merges well.

I'm quite used to git.  And "git pull" harmful, vs "git remote update
-p" and "git reabse @{u}" :-)



reply via email to

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