[Scons-users] Defining build dependencies between a program and a shared library

Philippe Macaire philippe.macaire at gmail.com
Mon Jan 27 10:38:13 EST 2014


Hello all, I apologize in advance for this long email. I did my best to
make as short as possible (but no shorter...) and it is (I hope!) easy to
follow and quick to read.

Let's say we have a shared library libfoo.so built from some source file.
In the sconstruct we would have something like:
env = Environment()
foolib = env.SharedLibrary('foo', ['source.cpp'])

Let's say we want to build an executable linked to this library:
env.Program('bar', ['main.cpp'], LIBS=[foolib])

So far so good. SCons 101.

Now let's assume the project is getting bigger so all libraries are built
in a dedicated directory "lib" with its own sconscript file, containing
basically the same information as before. The target is now lib/libfoo.so.

The generated link command for program 'bar' is now something like
g++ -o bar main.o lib/libfoo.so

This is OK, but if I inspect 'bar' with ldd for instance, I can see that
libfoo.so is known as an explicit (relative) path "lib/libfoo.so". This
implies that whenever I want to run 'bar', I need to find, from my current
working directory, exactly such a path. And there is no way to set the
LD_LIBRARY_PATH to point to the library from a different place. The only
trick I've found is to have, in my current working directory, a symbolic
link called "lib" pointing to the actual lib directory. Not handy.

To avoid this the solution could be to link to my library with a command
like
g++ -o bar main.o -Llib -lfoo
e.g. specifying
env.Program('bar', ['main.cpp'], LIBPATH=['lib'], LIB=['foo'])

While this looks like a decent solution, I think it is weaker because now
SCons is unaware of the *dependency* which exists between library foo and
program bar: in other words if library foo has to be re-built, SCons is
unable to automatically trigger the subsequent re-link of executable bar.

It is my understanding that the Program builder defines with one parameter
(LIBS) two different things:
- "the current target depends on the following libraries/targets"
- "the libraries which should appear on the link command are the following"

Apparently the use of SCons variables to define LIBS as dependencies
implies to link the libraries with their complete path in the executable,
which is in many cases not what you want because it binds to a particular
directory tree organization and (especially) to a specific directory from
which to launch the program.

I've tried to work around this by separating these two concepts into two
SCons commands:
barpgm = env.Program('bar', ['main.cpp'], LIBPATH=['lib'], LIB=['foo'])
env.Depends(barpgm, foolib) # dependency made explicit

This seems to work as I would expect but is redundant because you have to
specify the same information twice. A bit clumsy when you have twenty
shared libraries with on average ten dependencies for each.

Any cleaner way to deal with this? Anything wrong with our approach?

Note that exactly the same issue exists when specifying the libraries a
SharedLibrary depends on.


Thank you. If it can be of help I can send a tar with the example.
Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20140127/d132f368/attachment.html


More information about the Scons-users mailing list