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

Thu May 21 17:51:30 EDT 2020

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