[Scons-users] SCons is only installing .lib part of SharedLibrary on Windows when target is specified

[Dan Pidcock]

On 6 February 2013 16:59, Dan Pidcock <dan.pidcock at googlemail.com> wrote:

> On 1 February 2013 17:58, Gary Oberbrunner <garyo at oberbrunner.com> wrote:

>> On Fri, Feb 1, 2013 at 11:28 AM, Dan Pidcock <dan.pidcock at googlemail.com>

>> wrote:

>>> On 1 February 2013 15:33, Gary Oberbrunner <garyo at oberbrunner.com> wrote:

>>> > On Fri, Feb 1, 2013 at 10:24 AM, Dan Pidcock

>>> > <dan.pidcock at googlemail.com>

>>> > wrote:

>>> >>

>>> >> However, looking through the --taskmastertrace output did show that

>>> >> the DLL wasn't even being considered when just the application was

>>> >> being built, but the .lib was being considered.

>>> >

>>> >

>>> > This is correct behavior -- you don't need the .dll to link the .exe.

>>> > Your

>>> > Install should pick up both, however, and I think it is.

>>> > You're using Default(), which tells SCons what to build if you don't

>>> > specify

>>> > any targets on the cmd line.  In your run 1, though, you do specify a

>>> > target

>>> > (your exe) -- so it builds only what's needed to build that target.

>>> >

>>> > Maybe what you want is Alias('all', ...) instead of Default(), and then

>>> > say

>>> > Default(Alias('all')) to build all by default?

>>>

>>> I think I understand: Currently what I have tells SCons to install the

>>> library when no target is specified, but when I specify a target I

>>> still need to tell it to install the library?

>>

>>

>> Correct.  SCons will only build what it's told to.  Default() is only used

>> when no command-line targets are specified.  And further, if there's no

>> Default(), everything under the current dir is built.

>>>

>>>

>>> How do I do the latter?

>>>

>>> I tried:

>>> Alias('all', sampleApplicationEnv.Install(binDir, sampleApplication))

>>> Default(Alias('all'))

>>> in the application SConscript

>>> and:

>>> Alias('all', sampleLibraryEnv.Install(binDir, sampleLibrary))

>>> Default(Alias('all'))

>>> in the library SConscript

>>> but that also only installed the .lib and not the .dll

>>

>>

>> That should have worked.  Print out sampleLibraryEnv.Install(binDir,

>> sampleLibrary)) and see if it's a list containing your dll.

>> Do the printing like this:

>>  stuff=sampleLibraryEnv.Install(binDir, sampleLibrary))

>>  print [str(x) for x in stuff]

>> because the elements of the list are Nodes, and you need to print their

>> string representations.  If your DLL is in that list, then it should get

>> into the alias, and thence into the default (which of course is only used if

>> you don't specify a target).

>

> Gary,

>

> Thanks for the input. The DLL is in the list but it doesn't get into

> the list of targets.

>

> When I run SCons with default target, the list of targets passed to

> the taskmaster includes the dll and the lib, in both the build and the

> bin areas. When I run with the application as a target, that is the

> only target (as expected), the taskmaster foes down the targets and

> resolves:

> build/app/app.exe is a child of the app target

> bin/lib.lib is a child of build/app/app.exe

> (bin/lib.lib is therefore built in build and installed in bin)

> build/lib/lib.lib is a child of bin/lib.lib

> build/lib/lib.dll is a child of build/lib/lib.lib

> (build/lib.lib and build/lib.dll are therfore built)

> However, nowhere does it decide that bin/lib.dll is a child of

> anything so it never installs it.

>

> I am now wondering if we are trying to push scons in a direction it

> was never intended to be used. We have a build directory and a binary

> directory.

> Applications are set up with a LIBPATH pointing at the binary

> directory (because the build directory includes the library name so

> cannot be used for this).

> Each library/application installs itself from the build directory to

> the binary directory so there need only be one directory on the path.

> (one concern that strikes me with this approach is controlling build

> order may be problematic as it is critical to install libraries before

> building anything that depends on those libraries)

>

> I think we need to use some of the approaches in

> http://stackoverflow.com/questions/11571577/scons-libraries-and-sub-libraries

> instead of the above to allow SCons to find the libraries that it

> needs to build from so will give that a try...


Worth emphasising is that our variant_directory is different for each
library/app to avoid name clashes. It seems that is not the mindset
behind SCons.