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

[Gary Oberbrunner]

On Tue, Aug 21, 2012 at 11:30 AM, Chris BeHanna <chris at behanna.org> wrote:

> On Aug 21, 2012, at 07:44 , Gary Oberbrunner <garyo at oberbrunner.com> wrote:

>

>> 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.

>

>         In the OP's case, it's simpler--he's building a shared library and not linking it against anything.  There is no need to set LIBPATH or LIBS at all for that (although it is harmless to have LIBPATH set), unless the .so is getting linked against its dependency shared libraries (a practice I HIGHLY recommend).  This will do just fine (the bit with the '#' character is significant--it means "anchor this path to the top of the build instead of computing it relative to the SConscript file in which it appears"):

>

>         # Assume a prior setting of LIBPATH

>         env.Append(LIBPATH = [os.path.join('#', Dir('.').path])

>

>         env.Append(CPPPATH = [os.path.join('#', Dir('.').path])

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

>

> This will generate

>

>         g++ -o foodir/libfoo.so -I/path/to/foodir foodir/foo.cpp \

>         -L/path/to/foodir


Yes, that sounds just right.  (BTW, why do you do os.path.join('#',
Dir('.').path?  Isn't that equivalent to just '.'?)

-- 
Gary