[Scons-users] Question about paths and shared libraries with SCons

Gary Oberbrunner garyo at oberbrunner.com
Tue Aug 21 08:44:32 EDT 2012


On Tue, Aug 21, 2012 at 4:50 AM, Ted Middleton <tmiddleton at teradici.com> wrote:
...

> I'm wondering - when I do this, that is I add the dylib name directly to the construction environment's LIBS variable like this:

>

> Import( 'env' )

> env.Append( CPPPATH=[Dir('.')] )

> env.SharedLibrary( 'foo', 'foo.cpp' )

> env.Append( LIBPATH=[Dir('.')] )

> env.Append( LIBS=['foo'] )

>

> then when I try to build foo, scons puts together a command line like this one:

>

> g++ -o foodir/libfoo.so foodir/foo.cpp -Lfoodir -lfoo

>

> which of course is never going to work. It's easy enough to understand why scons would do this, but is there no magic in the builder to prevent this? Is the recommended solution to just do something like the following?

>

> Import( 'env' )

> env.Append( CPPPATH=[Dir('.')] )

> env.Clone().SharedLibrary( 'foo', 'foo.cpp' )

> env.Append( LIBPATH=[Dir('.')] )

> env.Append( LIBS=['foo'] )


There's no magic, that's correct. You can either use two different
envs (as you do above), or use overrides:
env.SharedLibrary('foo', 'foo.cpp', LIBS=[], LIBPATH=[])

Some people create a TOOL_FOO which can be applied to environments
which *use* libfoo (commonly setting/appending to CPPPATH, LIBS,
LIBPATH). But you wouldn't apply that tool to the env that *builds*
libfoo.

--
Gary


More information about the Scons-users mailing list