0

Our project contains a lot of c++ sources, up until now we were sing make to build everything, however this takes ages. So I stumbled upon waf, which works quite well and speeds up the build a lot. However everytime I do a full build I end up with a couple of build errors that make no sense. If I do an incremental build now, most of the time some of the sources that could not be build the first time around are build now, some others still fail. On another incremental build I will finally get a successful build.

I have tried building the separate libraries in separate steps, just in case any dependent libraries are attempted to build in parallel, but the errors still appear.

EDIT: The errors I keep getting do not seem to have anything to do with my code, e.g.

Build failed
 -> task failed (exit status -1):
        {task 10777520: c constr_SET.c -> constr_SET.c.1.o}

After another "waf build" I do not get this error anymore.

EDIT2: The build step for my libraries looks like this:

def build(bld):
  bld.shlib(source="foo.cpp bar.cpp foobar.cpp constr_SET.c",
  target="foobar",
  includes= "../ifinc",
  name="foobar",
  use="MAIN RW HEADERS",
  install_path = "lib/")

MAIN, RW, HEADERS are just some flags and external libraries we use.

Has anyone seen similar behaviour on their system? Or even a solution?

pushy
  • 9,535
  • 5
  • 26
  • 45
  • You're apparently not getting the dependencies right (probably the link step). But you're not showing an example, not even the errors, so we can't help. – sehe Oct 07 '11 at 10:10
  • You're right of course, updated with an example. It very well could be a problem with dependencies, however, this errors keep coming during the build of our shared libraries, which do not have any dependencies on each other (we copy our headers to a central directory to avoid dependencies at this point). – pushy Oct 07 '11 at 10:29

1 Answers1

1

I'm suspecting multiple targets are building the same required object in parallel. Try 

export JOBS=1

or 

 waf --jobs 1
sehe
  • 374,641
  • 47
  • 450
  • 633
  • Ok, you're spot on, if I reduce the number of jobs the errors go away. But what am I doing wrong? I put the (hopefully) relevant part of my wscript into the question text. – pushy Oct 07 '11 at 10:40
  • 1
    I think you should show the rule where constr_SET.c is compiled, _and/or_ where constr_SET.o is used. I assume that more than 1 binary is linking to constr_SET.o and is building it on demand - at the same time. In that case, it is better to explicitly depend on constr_SET.o so Waf can know the dependency and serialize the depending rules – sehe Oct 07 '11 at 11:08
  • Basically the constr_SET.c file is one of the source files for our libs. So the config above is where the source is compiled, and as our libs do not depend on each other, the source is not used anywhere during the lib building phase. Later on, when our processes are build we depend on the lib, but I put the building of libs and processes into different build groups, so I would like to think that such side effects should not happen... – pushy Oct 07 '11 at 12:10
  • Just reran a build, and now I realized that the class I'm getting the exception for has already been build. At least now I got a clue in which direction to look. Thanks a lot, you were a big help. – pushy Oct 07 '11 at 12:16