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

[Ivan Nedrehagen]

Hi,

I have printed the tree where I have replaced the #include "test.h" with 
"test2.h"

g++ -o test.o -c test.cpp
+-.
   +-SConstruct
   +-test
   | +-test.o
   | | +-test.cpp
   | | +-test2.h
   | | +-/usr/bin/g++
   | +-/usr/bin/g++
   +-test.cpp
   +-test.h
   | +-test.cpp
   | +-test2.h
   +-[test.o]
   +-test2.h

Here you can see that test.cpp depends on nothing (it cannot, it isn't 
built), however the test.o depends on test.cpp and test2.h (which is 
correct)

But somehow the test.h has also got a dependency on test2.h

As I understand SCons, test.cpp should be scanned by the Header builders 
scanner

It behave as if the header builder was a object builder with a standard 
cpp scanner

So it must be my understanding of the scanners or SCons dependencies 
that are wrong.

But there definitely doesn't have to be a cycle here.

If test.h changes test.o must be rebuilt

If test.cpp changes test.h and test.o must be rebuilt


On 2017-03-19 10:11, Jean-Baptiste Lab wrote:
> 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
>
>
>
>
> _______________________________________________
> 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/4d160674/attachment-0001.html>