[Scons-users] Problem with DLL dependencies on Windows

[Dmitry Mikhin]

Hello everyone,

I discovered an apparent issue with building shared libraries under
MinGW toolchain. Want to check if it's my own error or a general
problem. The behavior is the same under SCons versions 2.2 and 2.3. A
small test project demonstrating the problem is attached. All works
without issues on Linux.

Background: we have a project organized into a set of components
(libraries), one per directory. Each component comes with its own unit
tests (programs to be run at build time). Higher level components link
against the libraries of lower level components. Now, the intent is to
make each component to install its own headers and built libraries
into a common location under the build directory (in this case
"build/includes" and "#build/libs"). Other component would just use
"-Ibuild/includes" and "-Lbuild/libs" without the need to specify the
particular component locations, as it was before (e.g., like
"-Lbuild/lib/foo -Lbuild/lib/bar" if you would use foo and bar). SCons
install is lazy and would put into build/libs, build/includes only the
files that would indeed be used by someone, thus, each build, even a
partial build shall involve only the desired minimum of compiles and
installs, and a minimum of -I and -L flags.

It almost works, apart from the problem of DLL on Windows. We build
all libraries as shared, resulting in *.a and *.dll files. Only the
*.a half makes it into build/libs on demand. If one of the later
components builds a test executable and runs it, the run fails because
the DLL is not found ('#build/libs" is added to PATH as well). If I
manually copy the *.dll files into '#build/libs', all works.

Inspection of "scons --tree=all" (the second attached file) suggests
that executable files produced in other components lack a dependency
on *.dll, have only *.a files listed.

Adding a catch-all dependency of test programs on '#build/libs' does
not work in general: it is OK for this simple case (uncomment a line
in src/prog/SConscript), but in the larger project some of the built
routines are run-time tests and their output is used to build the
respective components, thus, we cannot build all libraries prior to
running the tests.

So, do I have any errors in the SCons files?
Is the observed effect the intended behavior or a bug?
Any workarounds suggested?

Cheers,
Dmitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bug02.tar.gz
Type: application/x-gzip
Size: 1275 bytes
Desc: not available
Url : <http://four.pairlist.net/pipermail/scons-users/attachments/20130524/cbfe29bb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tree-all.log
Type: application/octet-stream
Size: 1029 bytes
Desc: not available
Url : <http://four.pairlist.net/pipermail/scons-users/attachments/20130524/cbfe29bb/attachment-0001.obj>