[Scons-users] Caching and variant_dir

[Glen Gibb]

Hi Bill,

Attached is a simple example that illustrates this problem. The example is
structured as follows:

vardir_prob
   |
   + proj
   |    |
   |    + build
   |    |
   |    + src
   |
   + external_proj

The main project (proj) is including files from external_proj. When you run
scons in vardir_prob/proj, most of the outputs are placed in
vardir_prob/build, except for ext.o, which is placed in vardir_prob/proj.


ext.c resides at the top level of external_proj, but I'd still like the .o
file to be generated in the build directory.

Regards,
Glen


On Fri, Nov 20, 2015 at 2:01 PM, Bill Deegan <bill at baddogconsulting.com>
wrote:

> Glen,
>
> Any chance I can get you make a tarball of an example which reproduces
> this?
>
> -Bill
> Co-Manager SCons project
>
> On Fri, Nov 20, 2015 at 11:45 AM, Glen Gibb <glen at barefootnetworks.com>
> wrote:
>
>> Hi William,
>>
>> I had come across that answer on StackOverflow before posting to the
>> list. I do have the same problem that Brady (the StackOverflow poster) had.
>>
>> Brady states at the end of his reply:
>>
>>> The fact that SCons places the compiled object file in the source
>>> directory seems like a bug to me. At the very least, it should be placed in
>>> the variant_dir root directory.
>>>
>>
>> This is the exact same problem that I have, and I tend to agree with
>> Brady that the compiled object should be placed in the variant_dir.
>>
>> Do you know if there are any intentions by the developers to address this?
>>
>> Regards,
>> Glen
>>
>> On Fri, Nov 20, 2015 at 11:20 AM, William Blevins <wblevins001 at gmail.com>
>> wrote:
>>
>>> Here is feedback from one of the project managers for a related
>>> questions:
>>> http://stackoverflow.com/questions/10209961/source-code-compiled-from-a-repository-is-not-put-in-the-variant-dir-for-a-hie
>>>
>>> If that link doesn't help your case, I may have to defer this question
>>> to one of the project managers.  I am not as familiar with repository and
>>> variantdir configurations as other pieces of the core SConstruct model.
>>>
>>> V/R,
>>> William
>>>
>>> On Fri, Nov 20, 2015 at 6:58 PM, Glen Gibb <glen at barefootnetworks.com>
>>> wrote:
>>>
>>>> Thanks William,
>>>>
>>>> I played with a variant that moved the SConstruct file up a level of
>>>> hierarchy.
>>>>
>>>> E.g.,
>>>> /home/example/SConstruct:
>>>> SConscript('src/sconscript', variant_dir='build')
>>>>
>>>> This does work as expected if all source files are in the src directory
>>>> with the SConscript file.
>>>>
>>>> Unfortunately my build is a little more complicated complicated than my
>>>> initial example. It pulls in files from an external repository, in addition
>>>> to files sitting in the source directory. Here's a simplified version:
>>>>
>>>> CacheDir('/my_cache')
>>>> Repository('/external/src')
>>>> env = Environment()
>>>> env.SharedLibrary('mylib', ['mylib.cpp', '#external_file.cpp'])
>>>>
>>>> The problem with this version is that external_file.os is generated in
>>>> /home/example/src, rather than /home/example/build where I would expect to
>>>> find it.
>>>>
>>>> Any idea how to make sure all output goes to the variant_dir, rather
>>>> than the source dir?
>>>>
>>>> Thanks,
>>>> Glen
>>>>
>>>>
>>>> On Thu, Nov 19, 2015 at 11:51 PM, William Blevins <
>>>> wblevins001 at gmail.com> wrote:
>>>>
>>>>> I think that this happens because the Node in question exists outside
>>>>> the SConstruct directory tree.
>>>>>
>>>>> On Fri, Nov 20, 2015 at 4:28 AM, Glen Gibb <glen at barefootnetworks.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Caching does not behave as I expect when the variant_dir starts with
>>>>>> '..' (i.e., pointing up a directory). In this case, caching uses the
>>>>>> absolute path to the files, rather than the relative path I had hoped it
>>>>>> would store.
>>>>>>
>>>>>> To illustrate, assume my source directory is /home/example/src. My
>>>>>> sconsript file is:
>>>>>>
>>>>>> CacheDir('/my_cache')
>>>>>> env = Environment()
>>>>>> env.SharedLibrary('mylib', ['mylib.cpp'])
>>>>>>
>>>>>>
>>>>>> The following SConscript line line:
>>>>>>      SConscript('sconscript', variant_dir='build')
>>>>>> results in caching storing a path beginning with build as I expect:
>>>>>> 'build/mylib.so'
>>>>>>
>>>>>> However, the SConstruct line:
>>>>>>      SConscript('sconscript', variant_dir='../build')
>>>>>> results in caching storing the full path:
>>>>>> '/home/example/build/mylib.so'
>>>>>>
>>>>>>
>>>>>> Is there a way to stop scons from resolving the .. in my variant_dir
>>>>>> to an absolute directory?
>>>>>>
>>>>>> Regards,
>>>>>> Glen
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20151120/bafbfd6d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scons_vardir_prob.tgz
Type: application/x-gzip
Size: 639 bytes
Desc: not available
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151120/bafbfd6d/attachment.bin>