[Scons-users] Dealing with an odd dependency

[Brian Cody]

Hey, no argument from me about SCons having a legitimate complaint.

The tool is modelsim. Modelsim relies on an INI file to tell it where
things exist in your file system, e.g. lib_a is c:\here\liba, lib_b is
c:\here\libb, etc. The library is the location of where compiled objects
have been replaced. A caveat to this is that if lib B depends on lib A,
then lib A must be compiled and in the ini file before lib B is compiled.
Then if there's a lib C with a similar dependency on lib B, things start to
chain together.

Now I've got the library creation and compilation all worked out and happy.
It dynamically determines what libraries exist, what their dependencies
are, library build order, etc. No problem there. The one compromise is that
I have the ini file fully loaded with pre-ordained knowledge of what
libraries will exist and where--which is slightly less than optimal.

Modelsim has a handy command (vmap) which will open its own ini file and
add a library listing. It will detect if the library already exists in the
ini file and if it does, it will replace the entry rather than adding a
duplicate.

Library "creation": vlib
Library compilation: vcom
Update ini file: vmap

The library creation does not depend on the ini file. They all can (and do)
run simultaneously. It really just creates a directory with a text file
with some internal modelsim information.
Next vcom can run on any library that depends on no other library.
Next vmap should be run to place those libraries in the ini file (vmap
would definitely need to treat the ini as a side effect at least)
Next vcom can run on any library that depends on just the previously
created libraries.
etc.

The end result is a mass of compiled libraries and an ini file to rule them
all. One possibility I'm now thinking of is maybe we can have an ini file
get generated for each individual library with the entries needed just for
that library's vcom. It might be a little less ideal but it would meet my
goal. Any other ideas?

Thanks


On Fri, Dec 5, 2014 at 2:39 PM, Dirk Bächle <tshortik at gmx.de> wrote:

>  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 listScons-users at scons.orghttps://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/20141205/52f2b583/attachment.html>