[Scons-users] Problems with SConscript files using variant_dir and duplicate=False

Bill Deegan bill at baddogconsulting.com
Fri May 22 12:27:26 EDT 2020 

If you have to go that route.. I can pretty much guarantee you've done
something wrong.
I've cloned your repo and I'll take a look at it this weekend.
Pretty sure it's the combo of SConscript variant dir and partial separate
VariantDir() for other dirs which is causing an issue.

On Fri, May 22, 2020 at 4:20 AM Hans-Christian Wild <hchr.wild at gmail.com>
wrote:

> OK, thank you for the clarification!
>
> On Fri, May 22, 2020 at 12:32 AM Daniel Moody <dmoody256 at gmail.com> wrote:
>
>> Ah my mistake, I ran scons first with duplication on, then modified the
>> SConstruct to disable it and ran scons -c, which scons then did not cleaned
>> the duplicated files because of my change, so they were still there when I
>> built again. So that is not working for me either.
>>
>> On Thu, May 21, 2020 at 4:51 PM Hans-Christian Wild <hchr.wild at gmail.com>
>> wrote:
>>
>>> Hi Daniel,
>>>
>>> thank you for taking the time to answer! Unfortunately, there are still
>>> problems.
>>>
>>> Firstly, your suggestion does not work for me?! I am puzzled,,
>>>
>>> When I just change the following line, the output still reads:
>>>
>>> mylib_a, mylib_h = SConscript('../../SConscript', exports='env',
>>> variant_dir='../../target/mylib', duplicate=False)
>>>
>>> /w/Projects/mylib/example/mingw
>>> $ scons
>>> scons: Reading SConscript files ...
>>> scons: done reading SConscript files.
>>> scons: Building targets ...
>>> scons: building associated VariantDir targets: .
>>> gcc -o target\src\main.obj -c -IW:\Projects\mylib\target\mylib\include
>>> target\src\main.c
>>> target\src\main.c:4:10: fatal error: Types.h: No such file or directory
>>>  #include <Types.h>
>>>           ^~~~~~~~~
>>> compilation terminated.
>>> scons: *** [target\src\main.obj] Error 1
>>> scons: building terminated because of errors.
>>>
>>> So only the effect was that SCons has decided to put a absolute path to
>>> the wrong location, instead of the relative one.
>>>
>>> Secondly, I am aware of that sentence from the docs and this is what I
>>> would like! I need X examples building X different version of mylib.
>>>
>>> Also, I assumed that when I do a (in /SConscript)
>>>
>>> headers = env.Dir('include/')
>>>
>>> by the docs:
>>>
>>> Dir(name, [directory]) , env.Dir(name, [directory])
>>> [...] If no directory is specified, the current script's directory is
>>> used as the parent.
>>>
>>> .. that this would mean that scons remembers a relative path and the
>>> current SConscript file as parent and is able to compute and abs or
>>> relative path to if from where ever scons is called our what variant dirs
>>> you specify.
>>>
>>> SCons does so correctly when you have duplication on, if not, it doesn't.
>>>
>>> -hans
>>>
>>> On Thu, May 21, 2020 at 10:22 PM Daniel Moody <dmoody256 at gmail.com>
>>> wrote:
>>>
>>>> Also should note, I am not saying its "not a bug", just what worked
>>>> when I was messing with your example. It seems like its "not a bug" and if
>>>> you really want your variant dir in the location of the SConstruct you
>>>> should use duplicated tree. So probably more of a feature request if you
>>>> were to submit an issue.
>>>>
>>>> On Thu, May 21, 2020 at 2:12 PM Daniel Moody <dmoody256 at gmail.com>
>>>> wrote:
>>>>
>>>>> the docs say:
>>>>> https://scons.org/doc/3.1.2/HTML/scons-man.html#f-SConscript
>>>>> "The variant_dir argument is interpreted relative to the directory of
>>>>> the calling SConscript file."
>>>>>
>>>>> So in the case the SConstruct is the "calling SConscript" and you are
>>>>> saying the variant dir for the SConscript should be target/mylib, but its
>>>>> not, its ../../target/mylib relative to the calling SConstruct.
>>>>>
>>>>> So you need to call it like this:
>>>>> mylib_a, mylib_h = SConscript('../../SConscript', exports='env',
>>>>> variant_dir='../../target/mylib', duplicate=False)
>>>>>
>>>>> For a non duplicated variant dir, the variant dir will be
>>>>> substituted with the source dir when resolving paths for the build, which
>>>>> means substituting "target/mylib/include" to "./include" where
>>>>> 'target/mylib' is the variant dir and '.' is the source dir, will not work
>>>>> from the calling SConstructs location. It should be substituted with
>>>>> "../../target/mylib" so the variant dir resolved to the correct location.
>>>>>
>>>>> On Thu, May 21, 2020 at 12:54 PM Hans-Christian Wild <
>>>>> hchr.wild at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have two questions about SCons, I have uploaded a *working* example
>>>>>> as base where SCons does everything nearly as I want it. The problems start
>>>>>> to occur only when we do slight modifications to this example.
>>>>>>
>>>>>> https://github.com/hchrwild/scons01/tree/master
>>>>>>
>>>>>> In the project we have a main SConstruct file in `/example/mingw/`
>>>>>> which imports a library SConscript file from `/`. The SConscript file
>>>>>> creates its little library for the given environment and returns it
>>>>>> together with its public header include path. The SConstruct file in turn
>>>>>> builds an executable linking the static library and using the public header
>>>>>> include path.
>>>>>>
>>>>>> Output:
>>>>>>
>>>>>> scons: Reading SConscript files ...
>>>>>> scons: done reading SConscript files.
>>>>>> scons: Building targets ...
>>>>>> scons: building associated VariantDir targets:
>>>>>> target\mylib\example\mingw
>>>>>> gcc -o target\src\main.obj -c -Itarget\mylib\include target\src\main.c
>>>>>> gcc -o target\mylib\src\Assert.obj -c -Itarget\mylib\include
>>>>>> -Itarget\mylib\src\include target\mylib\src\Assert.c
>>>>>> ar rc target\mylib\libmylib.a target\mylib\src\Assert.obj
>>>>>> gcc -o target\mingw-example.exe target\src\main.obj
>>>>>> target\mylib\libmylib.a
>>>>>> scons: done building targets.
>>>>>>
>>>>>> *Perfect!*
>>>>>> (Although I don't understand why it prints `building associated
>>>>>> VariantDir targets: *target\mylib\example\mingw*` which to me does
>>>>>> not make sense, IMO it should be *`example/mingw/target/mylib`* if
>>>>>> anything, but let's put that aside..)
>>>>>>
>>>>>> *Now the actual problems:*
>>>>>>
>>>>>> 1) I don't like that SCons duplicates everything. What I really want
>>>>>> is an out-of-source variant build. When I set `duplicate=False`, the build
>>>>>> fails, however:
>>>>>>
>>>>>> mylib_a, mylib_h = SConscript('../../SConscript', exports='env',
>>>>>> variant_dir='target/mylib', duplicate=False)
>>>>>>
>>>>>> scons: Reading SConscript files ...
>>>>>> scons: done reading SConscript files.
>>>>>> scons: Building targets ...
>>>>>> scons: building associated VariantDir targets: .
>>>>>> gcc -o target\src\main.obj -c *-Itarget\mylib\include*
>>>>>> target\src\main.c
>>>>>> target\src\main.c:4:10: fatal error: Types.h: No such file or
>>>>>> directory
>>>>>>  #include <Types.h>
>>>>>>           ^~~~~~~~~
>>>>>> compilation terminated.
>>>>>> scons: *** [target\src\main.obj] Error 1
>>>>>> scons: building terminated because of errors.
>>>>>>
>>>>>> As marked in above output, the include path is not updated. The
>>>>>> SConscript file is at `../../` relative to SConstruct, and the include
>>>>>> folder is ./include relative to SConscript. Therefore, without duplication,
>>>>>> the correct include path relative to SConstruct would be `../../include` ,
>>>>>> which SCons does not seem to compute however. Is this expected or a missing
>>>>>> feature/bug? I really like the idea, that the SConstruct file really only
>>>>>> needs to know where the SConscript file is located and having everything
>>>>>> else being figured out by the build system...
>>>>>>
>>>>>> 2) Let's put that aside and keep above change, but hardcode the
>>>>>> expected include path in SConstruct file:
>>>>>>
>>>>>> program = env.Program('target/mingw-example', sources, CPPPATH=[
>>>>>> '../../include'], LIBS=[mylib_a])
>>>>>>
>>>>>> scons: Reading SConscript files ...
>>>>>> scons: done reading SConscript files.
>>>>>> scons: Building targets ...
>>>>>> scons: building associated VariantDir targets: .
>>>>>> gcc -o target\src\main.obj -c -IW:\Projects\mylib\include
>>>>>> target\src\main.c
>>>>>> gcc -o target\mylib\src\Assert.obj -c *-Itarget\mylib\include
>>>>>> -IW:\Projects\mylib\include -Itarget\mylib\src\include
>>>>>> -IW:\Projects\mylib\src\include* W:\Projects\mylib\src\Assert.c
>>>>>> ar rc target\mylib\libmylib.a target\mylib\src\Assert.obj
>>>>>> gcc -o target\mingw-example.exe target\src\main.obj
>>>>>> target\mylib\libmylib.a
>>>>>> scons: done building targets.
>>>>>>
>>>>>> Now the compilation succeeds. However, scons has now duplicated the
>>>>>> include paths for the static library! One time with the invalid
>>>>>> variant-with-duplication path, and one time with the correct (absolute
>>>>>> path). Why does it do that? Is this a bug?
>>>>>>
>>>>>> Sorry for the long post. Any feedback appreciated!
>>>>>>
>>>>>> -hans
>>>>>> _______________________________________________
>>>>>> 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/20200522/851ace6f/attachment-0001.html>

More information about the Scons-users mailing list