[Scons-users] Generating header from cpp file causes cycle

[Jean-Baptiste Lab]

Hi,

SCons is doing the right thing here I believe...

> header = env.Header("test.h", "test.cpp")

This statements indicates that "test.h" depends on "test.cpp" (builders
implicitly make their targets dependent on their sources).

Then using:

> exe = env.Program("test.cpp")

you indicate that the "exe" target depends on "test.cpp". "test.cpp"
will be scanned by SCons for its dependencies, which will end up in
eventually in "test.cpp" depends on "test.h". SCons then realizes that
"Oh, I know how to build "test.h" and it depends on "test.cpp"" and
that's where the dependency cycle occurs ("->" in the following
indicates "depends on"):

exe -> test.o -> test.cpp -> test.h (through SCons scanner) -> test.cpp
(through env.Header) -> test.h ->... -> test.h -> test.cpp

The scenario you describe is: cpp file X is needed to build the header Y
that will be included in X which is correctly a circular dependency...
SCons has no way of figuring out when to build what:
- X has changed -> "I need to rebuild Y"
- wait, Y has changed -> "I need to rebuild X"
- wash, rinse, repeat

The usual way to solve this is to refactor the dependencies, maybe using
"test.h.in" file and use that as the source of you env.Header() builder...

Hope this helps,

JB


On 2017-03-19 09:51, Ivan Nedrehagen via Scons-users wrote:
>
> This is a case that reproduce the problem I have.
>
>
> It is not perfect, but it still illustrates the problem.
>
>
> the header I generate doesn't include anything. It becomes one line:
> "class Test {};"
>
> the test.cpp includes the file I generate of course. But in my
> understanding that only means that test.o depends on test.cpp and test.h
>
> This is reflected in the tree.
>
> For me it looks like that SCons decide that test.h depends on
> test.cpp, and that I therefore also must depend on test.h (since it is
> included)
>
> This is also reflected in the tree (if I changed the #include "test.h"
> in test.cpp into #include "test2.h", test.h seems to be dependant on
> test2.h)
>
>
> Please explain what I am doing wrong...
>
>
> On 2017-03-19 05:17, Bill Deegan wrote:
>> Your header file builder includes the header being generated.
>> There is a dependency cycle..
>> Is that really the code you have? (or just an example which doesn't
>> mimic your actual build?)
>>
>>
>> -Bill
>>
>> On Sat, Mar 18, 2017 at 10:00 PM, Ivan Nedrehagen via Scons-users
>> <scons-users at scons.org <mailto:scons-users at scons.org>> wrote:
>>
>>     I have a unit test library that generates headers from the cpp
>>     files that contains tests.
>>
>>     Lately with my updated version of SCons (2.5.0) I get dependency
>>     cycles.
>>
>>     (It is very hard to debug these cycles, because --tree doesn't
>>     output anything)
>>
>>
>>     A case that reproduce the problem:
>>
>>     --- SConstruct ---
>>
>>     def create_header(target, source, env):
>>         txt = " class Test {}; \n"
>>         file = open(str(target))
>>         file.write(txt)
>>
>>     env = Environment()
>>
>>     headerBuilder = env.Builder(action=create_header)
>>
>>     env.Append(BUILDERS={"Header": headerBuilder})
>>
>>     header = env.Header("test.h", "test.cpp")
>>     exe = env.Program("test.cpp")
>>
>>     --- test.cpp ---
>>
>>     #include "test.h"
>>
>>     int main() {
>>       Test test;
>>       return 0;
>>     }
>>
>>     --- Result ---
>>
>>     scons: *** Found dependency cycle(s):
>>       test.h -> test.h
>>
>>     --- End of Case ---
>>
>>     Why is this failing? I understand that the test.o should be
>>     dependent on test.h, but why is suddenly test.h depending on itself?
>>
>>     I tried to set target_scanner and source_scanner to None in the
>>     builder just to see if this made a difference, but no.
>>
>>     How can I express a builder that builds header files from cpp
>>     files without creating a builder that build dependency cycles?
>>
>>     _______________________________________________
>>     Scons-users mailing list
>>     Scons-users at scons.org <mailto:Scons-users at scons.org>
>>     https://pairlist4.pair.net/mailman/listinfo/scons-users
>>     <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/20170319/70af51f3/attachment.html>