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

[Daniel Moody]

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