[oi-dev] Release engineering // planing

[Jim Klimov]

On 2013-07-12 18:09, Alexander Pyhalov wrote:
> Hello.
>
> It's almost unreal.

Well, it was worth trying to offer the idea, good or bad :)

 > 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?

I, personally, don't. There are others in the community with more
practical preference toward the Studio, at least for some of their
software.

I can not vouch whether, for example, compiler difference would
provide for faster and/or more stable code on the same machines.
I am also unsure if the GCC stack provides for such features like
library versioning (recent PNG example could in theory be avoided
by having one binary file with several defined versions, and the
programs would state which one they need during dynamic linking).
Similarly, I don't know if the GCC stack allows for different
binary builds to be imported from a single file (i.e. generic
that is capable of working anywhere, and optimized for specific
opteron/xeon CPU features that may fail to execute on older
processors which lack specific commands or registers).

All I can say on this matter is that so far it has served us
well, and work with GCC is trodding new ground - you know the
problems first-hand ;)

On the opposite side, this is a proprietary compiler of a fixed
version with limited availability and aging every day, unlike
open GCC which can evolve and become better, even if something
is lacking today.

On the third side, this is somewhat reminiscent of arguments on
why we need SPARC support in illumos-gate - it is not only for
practical needs of those who own and want to run old SPARC boxes
with new OSes (as OpenSXCE now allows them to), but it is also
about "honestly keeping a promise" about the code's portability
by having at least two platforms that it works on. This may be
somewhat moot for compiler stacks, however. Linux is happily
limited by GCC-only (at least was, when I dealt with it, with
the recommended kernel-compiler being gcc-2.95 while other
components could use gcc-3.x.x long present at that time).
Also, such "promise" (if at all desired, and anyone decides
to do it) can be fulfilled by other compilers - intelcc,
clang, whatever - especially if they are more open and available.

I did already provide an argument that having the code compiled
by another toolchain can also serve to verify that it is good
and clean - if there are some things one chain checks for and
others don't. Maybe this is a benefit (except when making stupid
workarounds to fight the uncooperative compiler which IS wrong) :)

//Jim