[Scons-dev] Emulate SVR4/Linux like SONAME for AIX

[Michael Haubenwallner]

On 05/27/14 08:41, anatoly techtonik wrote:
> On Tue, May 20, 2014 at 10:42 AM, Michael Haubenwallner
> <michael.haubenwallner at ssi-schaefer.com> wrote:
>>
>>> Someone else (Gary?) should comment on your introduction of "CCVENDOR", I'm a bit
>>
>> IMO, CCVENDOR is the same level as CCVERSION: Knowing a compiler's version is less
>> useful when not knowing the vendor defining this version. For serf-trunk actually,
>> besides other small ones I'm using this diff to SConstruct - please note the comment:
>>
>> @@ -229,7 +229,7 @@
>>  #  linkflags.append('-Wl,-install_name, at executable_path/%s.dylib' % (LIBNAME,))
>>    env.Append(LINKFLAGS='-Wl,-install_name,%s/%s.dylib' % (thisdir, LIBNAME,))
>>
>> -if sys.platform != 'win32':
>> +if env.get('CCVENDOR') == 'GNU':
>>    ### gcc only. figure out appropriate test / better way to check these
>>    ### flags, and check for gcc.
>>    env.Append(CFLAGS='-std=c89')
> 
> There are many OS vendors who ship GCC. Would 'CCNAME' be better?

Actually I don't really care about the variable's name.
However, "NAME" seems a bit too generic to avoid confusion.

> There is also a concern that SCons should try to hide specific compiler
> details, urging people to write compiler-independent code.

"portable code is better code". Package source maintainers often can't imagine which OS,
arch and compiler their code works and is distributed on, nor do they have access to them.
But they are well advised to accept patches to support more platforms, even if they cannot
test some platforms themselves.

>> FWIW - without knowing how far the new toolchain is designed already - what I do miss
>> from the current Toolchain design (besides CCVENDOR) is:
>> * NM Tool (Vendor+Version)
>> * STRIP Tool (Vendor+Version)
>> * Which ld (Vendor+Version) used by $LINK
>>   (fex. gcc is configured to use either GNU-ld or AIX-ld)
> 
> Why do you miss those?

Native AIX nm/strip/ld cannot be used for cross-compiling, while GNU binutils can do
both native AIX as well as cross-compiling. But AIX and GNU toolchain do support
different commandline arguments. And GNU compiler can work with AIX binutils as well.

> Checking version is an extra call. Are you sure you need these
> versions by default?

What is "by default"?
At least this information is necessary before actually running the commands to build their args.

>> Additionally, I've thought of these ones:
>>
>> * From what I've seen so far, feels like cross-compiling isn't really supported.
> 
> Feeling are hard to patch or see into. Either a code example or more detailed
> blog post is needed.

See above: For cross-compiling, usually GNU compiler is necessary. And I have seen
using sys.platform to refine env['PLATFORM'], usually when env['PLATFORM'] == 'posix'.
Looking at such code, this "feels" like "this cannot work for cross-compiling".
However, must admit that I don't have need for cross-compiling myself.

>> * And please don't kill me for this: Especially for yet unsupported platforms, please
>>   let me suggest to allow (downstream distro maintainers) to still /use/ libtool to
>>   wrap the compiling and linking steps.
> 
> So, SCons can't be hacked deep enough to invoke different tool on
> linking. Is that right?

Nope.
But to just try some package if it can work for another platform, it is ways faster
to use an existing tool already ported than to port SCons too.

>> Subversion and Git knowledge seems to confuse me as a Mercurial newbie... sorry!
> 
> Right. There should be an example. I can try to simplify things for you. Both
> "bookmarks" and "named branches" are just tags. Bookmark tags are unique
> (one per all commits) and moved automatically. Branch tags are attached to
> every commit, so one tag applies to multiple commits and can not be removed.

Hmm... So when one tag (the branch) names multiple commits, how to tell which
commit actually is the one talking about when talking about that branch?

Thank you!
/haubi/