[oi-dev] Release engineering // planing

[Udo Grabowski (IMK)]

On 12/07/2013 18:09, Alexander Pyhalov wrote:
> On 07/12/2013 19:52, Jim Klimov wrote:
>>>...
>> Then when code is promoted to /dev and ultimately /release
>> it can be recompiled with SS. On one hand it would give
>> another tool's verification opinion about the code quality,
>> and on another (if SS-built code so far is assumed more
>> stable) - the less adventurous users would have more peace
>> of mind with their non-experimental machines running /dev
>> or /release.
> It's almost unreal. We now struggle with two different compilers in
> base, and the only logic way in my opinion is to just go on with GCC.
> Code can't be "just recompiled", every Makefile needs its tweaks to
> support one or another compiler. If it is not tested with Sun Studio in
> /hipster, it will not work with Sun Studio in /dev and so it will
> require inadequate amount of energy to be ported.
>
> Why do you need Sun Studio?
>
Because of legal reasons, Sun Studio has to vanish finally,
gcc is the ultimate target for OI. But since this switch is
nontrivial, we will live a while with a mixed system, which
is not a big problem except for C++ (where compilers cannot
be mixed by Standards © requirement), where we have the
/usr/g++/ tree for the new libraries. Switching to gcc will
be transparent for users in kernel space, but must be done
package by package in userland, since there will be
dependences and a couple of heads up for users which use
system/distro libraries (just think of all the python and
perl packages, I get a headache when I only think about it...).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2050 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20130712/c53d75a7/attachment-0005.bin>