[Scons-users] Path expansion with multiple SConscripts

[Eric Lunderberg]

Bill,

Thank you for the suggestion, and you are correct; I am looking for a bit
more flexibility than there would be with absolute paths.  I have a few
libraries that I tend to use in many projects, pulling them in as git
submodules.  All of the other paths are relative to the SConscript, and so
it is sufficient to point the top-level SConstruct at the library's
SConscript without the library needing to know where it is.  The different
PATH variables are the one exception to this, since relative paths can be
expanded strangely, and the absolute path may be different depending on
where the library is placed.

I've been looking for an excuse to read more of the internals of scons, so
I might see if it would be easy/useful to add a way to automatically expand
relative paths from SConscripts.  I imagine that LIBPATH, FORTRANPATH, etc
would also be able to benefit from it.

Eric

On Thu, Dec 8, 2016 at 8:22 PM, Bill Deegan <bill at baddogconsulting.com>
wrote:

> Eric,
>
> It's python so you could always monkey patch the behavior in.
> That said, I wouldn't recommend it.
>
> Seems like something similar to '#' might be right for this.
> The usual way folks implement this is:
>
> env.Append(CPPPATH=['#/path/to/real/source'])
>
> So you're looking for more flexibility than that...
>
> Or similar to:
>
> ${SOURCE.rsrcdir}    => /usr/repository/src
>
> But in your context SOURCE isn't defined...
>
> -Bill
>
>
>
> On Thu, Dec 8, 2016 at 5:00 PM, Eric Lunderberg <eric.lunderberg at gmail.com
> > wrote:
>
>> I have something of a work-around at the moment.  Instead of using
>> env.Append(CPPPATH=['.']) or env.Append(CPPPATH=[Dir('.')]), I can use
>> env.Append(CPPPATH=[Dir('.').RDirs('.')]).  This forces the expansion of
>> '.' to be done immediately, while still in the bottom-level SConscript, and
>> expands to both the source directory and the variant directory.
>>
>> Is there a way to set this as the default behavior from the top-level
>> SConstruct?  It seems like a bit of an awkward work-around at the moment,
>> needing to remember to do so in each SConscript.
>>
>>
>> On Mon, Dec 5, 2016 at 3:44 PM, Eric Lunderberg <
>> eric.lunderberg at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I believe I have run into a bug involving the include path generated for
>>> C++ compilation.  I am attempting to set up a modular SConstruct to compile
>>> multiple shared libraries, some of which depend on the others.  When a
>>> SConscript adds the current directory to the CPPPATH of a shared
>>> environment, the "." is expanded to the directory of the SConscript that
>>> defines a compilation rule, rather than the SConscript that appended to the
>>> CPPPATH.
>>>
>>> This becomes an issue when using variant_dir and duplicate=False,
>>> because it becomes impossible to use the Dir('.') syntax to force an early
>>> expansion of the directory.  In this case, it resolves to a path to the
>>> variant_dir, rather than expanding to both the variant_dir and location of
>>> the SConscript, as usually happens when using duplicate=False.
>>>
>>> The directory structure, contents of the SConstruct and SConscript, and
>>> resulting error messages are shown here (http://pastebin.com/mpBWvEQG).
>>> A short discussion of this issue can be found here
>>> <http://stackoverflow.com/q/40424482/2689797> on stack overflow, where
>>> it was suggested that the bug report be brought to the mailing list.
>>>
>>> Thank you,
>>> Eric Lunderberg
>>>
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20161208/beea297c/attachment-0001.html>