Hi,
Am 6. Dezember 2016 07:19:46 schrieb Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx>:
On Tue, Dec 06, 2016 at 12:22:02AM +0100, David Given wrote:
On 05/12/16 23:21, kallisti5 wrote:
[...]
> Then simply run the 32-bit gcc2h that has gcc5 as a secondary architecture.
>
> Not sure what the pain point is here... we're already catering to 32-bit
> machines with these R1 release plans :-)
I'm worried that 32-bit is going to become a second-class platform,
given that any new development is going to happen on gcc5, and that (for
reasons stated elsewhere) I believe that 32-bit hardware is going to be
the largest potential userbase.
gcc2h + x86_64 is the "don't change anything" plan. It is mostly what we
are doing, except we make x86_64 a *second* officially supported
platform.
While supporting 32bit machines apparently makes some sense for a few
people, not supporting 64bit makes no sense at all. We don't want to be
like MorphOS where you have to buy a 10 year old machine to run the OS.
Is there any technical reason why this couldn't be gcc5 with gcc2 as the
secondary architecture? That way all the gcc5 stuff can be used in core,
with the gcc2 stuff retained as a compatibility layer on top of it for
legacy BeOS apps.
There is no technical reason, but all the effort for the last 15 years
has been on gcc2hybrid and we are very close to a release. Switching now
would require more efforts in rebuilding packages, testing that
everything works as expected, etc. All this for no clear gain for users
("gcc5 can be used in core" is not a gain for users).
Hence the proposal to release beta1 as gcc2h + x86_64, and maybe switch
to gcc5 as the main compiler in R2. This way, gcc5 can be used in core,
but in the *next* release, which avoids delaying beta1 further to cram
in yet another structural change. We have had enough of that with the
package management system.
