[Scons-users] Why is File() changing the path I give it?
Bill Deegan
bill at baddogconsulting.com
Fri Apr 24 11:36:06 EDT 2020
not sure what to tell you then.
SCons normallizes paths based on it's own representation.
It doesn't store the path you specified the file with.
On Fri, Apr 24, 2020 at 8:31 AM Luke Robison <lukerobison at gmail.com> wrote:
> I realize that the result of the File() constructor is an object, not just
> a string. What I was attempting to point out was my surprise at the
> behavior of the constructor. I was operating under The Principle of Least
> Surprise, and changing a fully-resolved file path to a new file path
> surprised me. Less surprising outcomes would have been a "No rule to build
> file XXX" error, or perhaps a "you can't make a Node.FS object from a file
> which doesn't yet exist". I found the behavior quite confusing.
>
> On Thu, Apr 23, 2020 at 1:58 PM Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> File() creates a node in SCons's datastructures.
>> It does not create a string to hold the representation of that file you
>> passed to File().
>>
>> SCons has a canonical representation of files and also how to generate
>> strings from that representation.
>>
>> Does that help?
>>
>> On Fri, Apr 17, 2020 at 1:20 PM Luke Robison <lukerobison at gmail.com>
>> wrote:
>>
>>> I'm trying to explicitly add dependencies to an scons build with
>>> multiple subdirectories and variant_dir builds. My custom add dependency
>>> function goes something like this (trying to make my build_tgt depend on
>>> lib.
>>> built_libname = env['LIBPREFIX'] + lib + env['LIBSUFFIX']
>>> full_name = env.Literal("{}/{}/build-{}/{}".format(env.Dir(
>>> '#').abspath,lib,self.short_flavor(env),built_libname))
>>>
>>> # full_name is like "/c/robison/code/xorshift/build-gd/libxorshift.a"
>>> build_dep = env.File(full_name)
>>>
>>> # build_dep is like "/c/robison/code/xorshift/source/libxorshift.a"
>>> env.Depends( build_tgt, build_dep )
>>>
>>> But I am completely confused as to why the File() function changing the
>>> path out from under me (see the inline comments). It seems to be replacing
>>> a variant_dir with "source" when the explicitly given path does not exist
>>> (which is often the case on a fresh build)
>>>
>>> For some context, my Sconstruct is at code/, and my Sconscript files are
>>> in code/<library>/source/Sconscript
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20200424/0fac5c61/attachment.html>
More information about the Scons-users
mailing list