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

Fri May 22 07:20:32 EDT 2020

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200522/92dc8a48/attachment-0001.html>