[Scons-users] Dealing with an odd dependency

[Dirk Bächle]

Hi Brian,

On 05.12.2014 19:59, Brian Cody wrote:
> Hello,
>
> I'm integrating a tool into our build system which behaves a little 
> differently than most. It constructs libraries, and then wants a path 
> mapping to those libraries to be placed into a file. This same file 
> has other information in it and it is required to already exist. So 
> the activity 'construct library' both depends this file, and has it as 
> a side effect. This alone is something that SCons complains about as a 
> circular dependency--it seems that there's a fine line between a 
> target and a side effect. I might be able to work around this, but it 
> gets a bit trickier since I might be constructing multiple libraries. 
> The side effect does guarantee that I won't construct multiple 
> libraries at the same time (which is good).
>

if your "side effect" file S is a prerequisite for your library L, and 
its contents depend on infos from creating L...then you have a 
dependency cycle S->L->S and SCons has all right to complain.
You have to be able to map the build dependencies on a DAG, no cycles 
allowed!

I didn't quite understand the rest of your build problem...it would help 
(me at least), if you could give some actual command lines for the 
required build steps (what would "make" do/call?).

Best regards,

Dirk

> Ideally I would like a solution that works this way:
> 1. The shared file doesn't exist. I have a builder that creates the 
> file in its initial state
> 2. A library can now be constructed since the shared file exists. It 
> does its library thing it does so well, and modifies the shared file.
> 3. Another library can now be constructed since the shared file 
> exists. It does its library thing it does so well, and modifies the 
> shared file.
> 4. We're done. While the two libraries depend on the shared file, they 
> only care when the builder in step #1 acts.
>
> If I run again with no modifications:
> 0. Nothing happens
>
> If I change the definition of the initial state of the shared file:
> 1. The builder re-creates the file in its (new) initial state.
> 2. A library is now constructed since the shared file was updated due 
> to the action in step #1. The shared file is updated.
> 3. A library is now constructed since the shared file was updated due 
> to the action in step #1. The shared file is updated.
> 4. We're done.
>
> Do you have any suggestions on how make SCons act in this manner?
>
> Thank you
>
>
> _______________________________________________
> 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/20141205/224165fe/attachment-0001.html>