[Scons-users] Questions about tool selection

[William Deegan]

Andrew,


You have a lot of questions densely listed below.
I'll try to address each.

On Jun 11, 2013, at 4:19 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com> wrote:


> 

> On Solaris, you can build g++ to use the Solaris assembler and linker, or you can build g++ to use the binutils assembler or linker. If you were so inclined, you could even build it setup to use the GNU assembler and the Solaris linker.

> 

> However, the default SCons link tool selection order seems to be based on the platform, so when you use SCons on Solaris, you get sunlink, rather than gnulink. This is a problem when building a shared library, as sunlink passes -G instead of  -shared, which g++ will silently ignore. You get a broken shared library.

> 

> Is there some way to ask the tool selection to base its linker selection based on its observation of the currently selected compiler?


Yes. :)
You can code it up yourself and build your environment as: env=Environment(tools=[])



> Is there some way to blacklist sunlink if I know that I will only be using GCC configured with the binutils linker? How is this supposed to work?


If you exclude sunlink from the list of tools provided to Environment at it's initialization, then it will should be chosen.


> For C++ you almost always need to drive the link with the compiler, so it should be the compilers job to know how to map its 'build a shared library' flag to the 'build a shared library flag' of the linker it was configured to use. 


The "almost always" is the issue.


> 

> Similarly, on many systems 'cc' and 'c++' are symlinks to the most recent compiler version. This is nice, for situations like when Apple updated its default compiler from GCC to clang. But the tool mechanism doesn't honor this: it prefers GCC always, and will select it by name before testing 'cc' or 'cxx'. This seems backwards to me: 'cc' and 'c++' should be tried first, and, if determined to be present, inspected, then dispatched to the appropriate specialized tool for further configuration. Otherwise, there is no way to ensure that the default selected compiler matches the default system compiler.


You can specify the compiler name in the Environment() initialization. Note that you will probably want to specify CXX and SHCXX (and CC and SHCC). Take a look at the manpage for a full list of variables: http://scons.org/doc/production/HTML/scons-man.html
Also you can set the order of the tool initialization via tools=[] in this case tools=['cc','c++','gcc','g++'] might work for you.


> 

> It is also unclear to me how this is supposed to work with a user selected compiler. If the user specifies CC=/path/to/a/c/compiler and CXX=/path/to/a/cxx/compiler and I populate the Environment with these values, how do the 'cc' and 'gcc' tools respond?


Once again I'd suggest a more explicit configuration of your Environment(). 
You can  use Variables() (see manpage) to capture command line specifications and propagate those into your environment and/or tools' initialization.


> Are they evaluated? I don't see that they even look at what CC and CXX are set to in the Environment.


They do not by default.


> Should I not allow those tools to run if the user has specified CC and CXX via variables or command line flags? Or am I supposed to overwrite their values after tool selection has run?


Again.. explicit initialization of Environment can help you here.


> In that case, if the auto selected tool is gcc, but the user selects a different compiler via CC/CXX, then might it not be the case that the environment modifications made by the gcc tool may be incorrect? It seems, again, that what the tool should be doing is inspecting the compiler currently selected by CC and CXX, if preset, and then determining which tool to invoke, not the other way around.


The issue there is then that SCons must understand how to interrogate each tool and do "the right thing".

A common pattern you'll see if you look at some of the open source projects is to have logic for each platform they want to support compiling on and set flags and other items for they way their tool must be built.



> 

> I'm sorry for this long email, but I'm quite puzzled by how this all is intended to work. Any insights would be appreciated.


No worries.
That's what we're here for.

Hope the above helps to clarify (at least a little) your questions.
=-Bill
Co-Manager SCons Project

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20130611/3e7c3d25/attachment-0001.html