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

Hans-Christian Wild hchr.wild at gmail.com
Fri May 22 07:19:47 EDT 2020 

Yes, your summary is absolutely correct, that's what I'd like to do.

Meanwhile I had some progress. I can fix the path problem, by using
srcnode() on the Dir() object in the SConscript file:

(
https://github.com/hchrwild/scons01/commit/025167704cd901147e55d46703421a3644f199da
 )

headers = env.Dir('include/').srcnode()

Now it becomes an absolute path (yellow), and the include directory is thus
valid for the outer SConstruct file as well:

/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\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.

One inconsistency about this is the fact, that SCons will no longer use the
duplicated headers even when I enable duplication.

Maybe there is a much better way than this? All I want is that the
SConscript reports to the SConstruct: Hey, there is a directory relative to
me, let's call it mylib_h, when you compile against me, use that in your
includes.

However, the seconds problem from my original email persists, I have no I
idea why scons duplicates the include paths during compilation of the
static library (blue)?!

On Fri, May 22, 2020 at 3:32 AM Bill Deegan <bill at baddogconsulting.com>
wrote:

> 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
>>>
>> _______________________________________________
> 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/46fa812a/attachment-0001.html>

More information about the Scons-users mailing list