[Scons-users] Problem with Repository build

[Martin Ritter]

Hi Dirk,

On 03/08/16 19:20, Dirk Bächle wrote:
> ahhh "The Belle II"! Awesome, and welcome to the SCons User mailing
> list.

Thanks :)

> Can you tell us a little bit more about how you run your builds?

Our build system assumes that code is organized in a specific way: We
have a set of "package" directories which contain a number of special 
directories (one for unit tests, one for libraries loaded at runtime 
with dlopen, one for objects to be serialized, ...)

Then we traverse the directory tree and use Glob() to basically compile
all C/C++/Fortran files in these directories into one shared library
each (with some exceptions and special rules). So from our ~2000 source
files (~ 2 MLOC, mostly C++ and some legacy Fortran) we compile around 
~300 shared libraries and a few binaries. We use a VariantDir("build", 
".", duplicate=0) as build directory.

To allow users to use a existing release with modifications to one of 
the packages we also provide a "central release" which gets used as 
Repository(). The user only needs to check out the package he wants to 
modify locally and all the other sources are taken from the central 
release directory.

In that case we traverse the directories for locally existing packages 
first and then the directories for all other packages in the central 
release to create the targets.

If I do a full build, e.g. not using the Repository(), everything seems 
to work.

> Do you see a difference between "-j n" builds and single-core ones?

-j seems to have no effect, it's very specific and it's always the same
file, independently of -j.

> Are there any custom Builders and/or Emitters involved?

Yes, there are a few custom builders/emitters that create
reflection/serialization information for our C++ classes using ROOT. 
Disabling this part of the build process seems to make no difference.

> And in the error example you gave, does the target "MilleData.os"
> exist afterwards?

No, it stops before doing anything, no commandos get executed as far as
I can see, the build directory is not even created.

If I run scons with --tree=all I get the error twice: once during the 
build as posted before and then again when printing the tree.

If there's any specific debugging option I should run or patches to 
SCons I should try I'm happy to do so. So far I have not been able to 
extract a minimal example to reproduce that error.

Best Regards,

Martin

PS: We're really looking forward to SCons supporting python 3, that 
would help us a lot since it's basically our last piece on python 2 :)