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

Bill Deegan bill at baddogconsulting.com
Thu May 21 21:31:43 EDT 2020 

Ugh.
You're example makes my head hurt.

So let's start out with what you are trying to do.
1) you have sources and header files in ./src and ./include
2) you have an example in example/mingw/src
3) you'd like to build the derived objects (libmylib.a, Assert.o) into
example/mingw/target/mylib

Is that a correct summary?

On Thu, May 21, 2020 at 6:17 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

> Please file an issue on Github and reference this email and fill out all
> the requested information.
> If it works with duplicate=True it should work with duplicate=False
> (unless for some reason the build tool (gcc,.. ) can't deal with files not
> in the same directory..
> -Bill
>
> On Thu, May 21, 2020 at 3:32 PM 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/20200521/b6c74d07/attachment-0001.html>

More information about the Scons-users mailing list