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

[Greg Troxel]

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

>> 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.
>
> What to do is a matter of opinion.  But the fact is that using CFLAGS
> and LDFLAGS currently breaks some of the gpsd scons modes.
>
> Overrides need to be used with care.

Sure.  But packaging systems can pass -fstack-protector and other such
things if those are configured on, and gpsd needs to override those with
care too.  It's a hard situation with no clear answer.

>> It's not about whether gpsd "uses" ccache.  It's about whether the
>> person/system compiling gpsd is using ccache.
>
> As long as you can test it.  Very few use it.

I have tested it and it works fine.  The pkgsrc build scrolls by fast
and takes 51s, and ccache reports:

  cache directory                     /home/gdt/.ccache
  primary config                      /home/gdt/.ccache/ccache.conf
  secondary config      (readonly)    /usr/pkg/etc/ccache.conf
  stats updated                       Thu Jun 20 15:07:42 2019
  stats zeroed                        Thu Jun 20 15:06:54 2019
  cache hit (direct)                   269
  cache hit (preprocessed)              25
  cache miss                             2
  cache hit rate                     99.32 %
  called for link                       84
  compile failed                         2
  preprocessor error                    12
  no input file                         10
  cleanups performed                     0
  files in cache                    211455
  cache size                           9.0 GB
  max cache size                      10.0 GB

A fair bit of this is building docs.

Without ccache (with CCACHE_RECACHE=t, really), it takes 95s, and

  cache hit (direct)                     0
  cache hit (preprocessed)               0
  cache miss                           296

For a package that doesn't have heavy doc-building tools, the speedup is
usually greater.

>> > 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}" :-)
>
> Been there, done that, recent Gitlab fails for me, and others, that
> way. YMMV.

Interesting; I wonder if they are doing something odd.  Thanks for the
warning -- I'll be extra careful.