Re: [gpsd-dev] Purpose of LIBPATH Overrides

[Fred Wright]

On Tue, 26 Jan 2016, Gary E. Miller wrote:
> On Tue, 26 Jan 2016 18:17:41 -0800 (PST)
> Fred Wright <address@hidden> wrote:
>
> > In getting the build to work in the MacPorts environment, first for
> > 3.15 and then for 3.16,
>
> Cool, thanks!

Thanks may be premature - my fix hasn't been accepted yet. :-) See:

        https://trac.macports.org/ticket/50288

> > It's also worth noting that cross-building with the sysroot option is
> > probably broken for the same reason.
>
> Possibly, but I'd hate to go down that rabbit hole w/o a tester and a
> bug report.

Yeah, though I believe cross-building has been broken since 3.15 for the
same reason that the MacPorts build got broken.  If anyone has a working
cross-build setup, it should be easy to check.

> > I didn't file a bug for this in case I'm missing something.
>
> Can you come up with a narrowly focused patch that targets just your
> build environment?  We can add it, you get your bug fixed in the
> mainline and no worries about breaking things unknown.

I don't think there's any reasonable way to get more "narrowly focused"
than the current approach, where the MacPorts build patches out all 20 of
the "LIBPATH='.'" overrides.  Doing this conditionally in SConstruct would
be even messier.  I believe it would be appropriate to do unconditionally,
but I was hoping for a response from Eric or someone else who fully
understands his chrpath-removal change.

Right now, SConstruct has code to set up what it thinks is a proper
LIBPATH, plus code to discard that value and substitute '.' in pretty much
every case that would matter.  Doing both doesn't make much sense, though
admittedly it's not overriding LIBPATH when linking *libraries*.

Now that all of the *code* patches from Macports have been incorporated
into the mainline, I'd like to at least reduce, if not eliminate, the
SConstruct patches, to improve maintainability.  The LIBPATH patches (not
needed prior to 3.15) constitute the largest portion of the SConstruct
patches.

Since the complete diff for SConstruct contains several patches for
different purposes, it probably makes more sense to send git commits for
individual patches, rather than plain diffs.  If this were GitHub, I'd
push my commits to my own fork and then send a pull request, but AFAICT
Savannah has no "fork" feature, so I guess one needs to use the "commit
email" approach (as the closest approximation to "moderated commits").

Fred Wright