SCons / scons

SCons - a software construction tool
http://scons.org
MIT License
2.01k stars 310 forks source link

STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME not in man page #2427

Open bdbaddog opened 6 years ago

bdbaddog commented 6 years ago

This issue was originally created at: 2009-05-30 16:57:32. This issue was reported by: bdbaddog. bdbaddog said at 2009-05-30 16:57:32

Greetings,

STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME is not documented.

-Bill

gregnoel said at 2009-11-10 17:17:35

Bug party triage.

haubi said at 2014-05-19 03:48:29

As this property currently is set within SCons.Tool.*, feels like this property's design is broken: While implementing the AIX SONAME thing, I've discovered that any active SCons.Tool actually uses the same SCons.Environment() instance, and any Tool's generate() overwriting previously generated Tool's value for STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME.

So either this should become an SCons.Platform property, or be a specific Tool's property, thinking of something like CCSTATIC_AND_SHARED_OBJECTS_ARE_THE_SAME, CXXSTATIC_AND_SHARED_OBJECT_ARE_THE_SAME, etc.

mwichmann commented 4 years ago

This is flagged as a doc issue, but seems to be an issue about the usability as well. And where would this be documented? Is this a user doc (aka manpage) issue? Or is this more internal API? Where does stuff for Tool writers that wouldn't go in a project sconscript get documented?

bdbaddog commented 4 years ago

@mwichmann - in general the compiler/tool/platform decides whether this is possible. That said it should be documented. So I'd say an entry in the manpage should be specific. note the caveat that not all platforms and/or compilers allow using static compiled objects in shared libraries or vice versa.

mwichmann commented 4 years ago

Okay, just took a look, this var appears to be quite intentionally excluded from docs: it appears in 11 tool doc files (xml files), each time in the <sets> section, each time commented out. For example, here's the section in the cc tool doc file:

<sets>
<item><!--_CCCOMCOM--></item>
<item>FRAMEWORKS</item>
<item>FRAMEWORKPATH</item>
<item>CC</item>
<item>CFLAGS</item>
<item>CCFLAGS</item>
<item>CCCOM</item>
<item>SHCC</item>
<item>SHCFLAGS</item>
<item>SHCCFLAGS</item>
<item>SHCCCOM</item>
<item>CPPDEFPREFIX</item>
<item>CPPDEFSUFFIX</item>
<item>INCPREFIX</item>
<item>INCSUFFIX</item>
<item>SHOBJSUFFIX</item>
<item><!--STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME--></item>
<item>CFILESUFFIX</item>
</sets>

This leaves me wondering if there is some reason why this value should be effectively hidden?

bdbaddog commented 4 years ago

Do the tools actually set it?

mwichmann commented 4 years ago

They do. The following tools flip it to 1: clangxx, gxx. masm, mingw, msvc, sgicc, sgicxx. While bcc32, cc, cxx set it to zero; not clear what happens otherwise.

mwichmann commented 4 years ago

So this is actually in the manpage, the documentation is picked up from link.xml, added in commit 054709f5a. However, the comment about the design of the flag seems pretty on-target. Do we want to close, or reword the report to indicate that one global property might be a little dodgy for this.

bdbaddog commented 4 years ago

Reword and leave it open I guess. I can see the wisdom of TOOL_STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME (thought that quite a long variable name)

mwichmann commented 3 years ago

Got lost after I couldn't figure out how to attack this - so assigning to self to remember