[Scons-users] Problems with ParseFlags()

[Fred Wright]

First collecting the responses and removing most of the quoted text.

On Sun, 27 Mar 2016, William Blevins wrote:

> Oh! Do --cflags instead. SCons expects compiler flags and not linker flags
> :)

I believe it handles both.

> I just reviewed the pkg-config man page. Try "--cflags". I should look at
> the SCons User Guide and see what it says now.

The actual case uses both, but I left out the --cflags in the interests of
brevity, given that the compiler flags weren't relevant to the problem.

In the real case, ParseFlags() is fed the combined compile/link flags,
and I believe the idea is that it parcels out the recognized flags into
the appropriate categories, with anything unrecognized dumped into
CCFLAGS.

On Sun, 27 Mar 2016, William Blevins wrote:

> Any chance of a File/Dir exception stack trace from "scons
> --debug=stacktrace"?

I could arrange that, but what additional information would it provide
that I haven't already posted?  It was definitely trying to create a file
node when a directory node of that name already existed, and that's
certainly the expected behavior when -rpath isn't recognized.  The only
thing that isn't definitely known is how the directory node got created,
but I don't think that's especially relevant.

Due to the poor exception handling in --debug=pdb mode, I debugged it by
modifying SConstruct to wrap a try/except block around the failing call,
and then set a breakpoint in the except clause.

On Sun, 27 Mar 2016, William Blevins wrote:

> The User Guide examples use both "--libs" and "--cflags" so I'm not sure if
> you are expected to use both or not. It isn't explicit.

It depends on what you're feeding them to.  If you're running just a
compile, then --cflags is appropriate,  If you're running just a link,
then --libs is appropriate.  If you're doing combined compiling/linking,
then you need both.

On Sun, 27 Mar 2016, Dirk Bächle wrote:

> here are two links to discussions of this issue:
>
>    https://reviews.freebsd.org/D5129
>    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178732
>
> , which make me wonder whether SCons should bother about "-rpath" at
> all. I see that there might be room for improvement regarding the
> exception handling and error messaging for ParseFlags()*, but I don't
> see the missing "-rpath" option as a bug...it's simply not implemented.
> And for good reasons as it looks... ;)

The first link seems to involve confusion over whether the linker was
being run directly or via the compile front end.  And the "fix" was to
change *from* the -Wl,rpath= construct that SCons *does* recognize *to*
the -rpath construct that it *doesn't*.  So that "fix" is the trigger for
the problem I'm seeing.

The second link is about precisely the problem I'm seeing, except that it
takes the approach of trying to get it fixed in ncurses, but it's
incorrect in assuming that ncurses is the only package with the issue.
It also appears that the "fix" is just changing it back to the way it was
when it was causing the problem reported in the first link.

BTW, even just in the GPSD case alone, the same issue exists with the
tinfo package as well as ncurses.  The pkgconfig data for FreeBSD ncurses
specifies including tinfo, but apparently that's not true on all
platforms, so GPSD's SConstruct applies pkgconfig data for both.

On Sun, 27 Mar 2016, William Blevins wrote:

> Dirk,
>
> I'm not sure that this is a bug. It may just be that the SCons User's Guide
> is not specific about the assumptions of ParseConfig implementation.
>
> It appears that SCons ParseConfig is expecting results from pkg-config in
> the form given by "--cflags" and not "--libs" (at least in terms of rpath).
> It may be that BOTH options are required based on the SCons User's Guide
> examples, but we should really cross reference the code in
> src/engine/SCons/Environment.py:do_parse against known gcc/g++ flags vs ld
> flags to guarantee that this is a consistent assumption and update SCons
> User's Guide documentation respectively.

On Sun, 27 Mar 2016, Dirk Bächle wrote:

> William,
>
> On 27.03.2016 16:19, William Blevins wrote:
> > Dirk,
> >
> > I'm not sure that this is a bug. It may just be that the SCons User's
> > Guide is not specific about the assumptions of ParseConfig
> > implementation.
> >
>
> the documentation of ParseFlags is specific enough for this case in my opinion:
>
>    "[...] Any other strings not associated with options are assumed to
> be the names of libraries and added to the $LIBS construction variable.
> [...]"
>
> There is no need to be specific about whether "--cflags" or "--libs"
> should be used when calling "pkg_config". The listed options/flags are
> supported and that's it. Note, how ParseFlags also doesn't require you
> to call "pkg_config"...the provided flags can come from anywhere...

The issue here is that the -rpath argument is a library *directory*, not a
library *file*, and "assumed to be names of libraries" is invalid.  And
aside from the file vs. directory issue, it should really be adding the
argument to RPATH, though I don't think that actually matters in this
particular case.

On Sun, 27 Mar 2016, William Blevins wrote:

> Do you have a link to the specification for the options that ParseConfig
> needs to support?

I don't know about a link, but I did notice that the FreeBSD compiler
doesn't list -rpath in the usage text but does accept it.  This is:

$ cc --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix

The "accept but don't advertise" behavior may be an indication of
deprecation, but I don't see that there's a downside of handling -rpath in
ParseFlags() unless there's some toolchain that uses a flag of that name
for a different purpose (other than general bloat of the elif chain, but
that's largely unavoidable).

On Sun, 27 Mar 2016, Dirk Bächle wrote:

> On 27.03.2016 17:03, William Blevins wrote:
> > Do you have a link to the specification for the options that ParseConfig needs to support?
> >
>
> Again, the ParseFlags() documentation lists the supported flags...I'm
> not sure of this counts as "specification", but it makes the expected
> behaviour of the method pretty obvious from my angle. ;)

Well there's expected behavior, and then there's desired behavior. :-)

On Sun, 27 Mar 2016, William Blevins wrote:

> Dirk,
>
> I must not understand then.
>
> SCons ParseFlags appears to support the items in the documentation and
> "-rpath" is not included:
> http://scons.org/doc/HTML/scons-man.html#f-ParseFlags. I could see that it
> is a feature enhancement possibly? The man page specifically states "Parses
> one or more strings containing typical command-line flags for GCC tool
> chains" as the first line which implies the options from pkg-config as
> given by "--cflags" which are GCC specific versus "--libs" which is LD
> specific: http://linux.die.net/man/1/pkg-config. This implies that the
> User's Guide example may not be correct since "--libs" format may not be
> supported, so we should be explicit.

No, --libs isn't a different format, it's just different information.
It's flags related to linking passed in the appropriate form for running
the linker via the compiler.  If --libs didn't work, zillions of things
would be broken.

The Internet Robustness Principle states "be liberal in what you accept,
and conservative in what you generate".  In this scenario, both the
ncurses pkgconfig data and SCons are failing to follow it.

Fred Wright