[haiku-development] Re: [haiku] Re: Future releases? Recommend nightlies? gcc2?
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 2 Dec 2016 17:48:50 +0100
Am 01.12.2016 um 17:08 schrieb Adrien Destugues:
R1a4 was 32bit only, but I think we can make beta1 the first release
to officially support 64bit. This kind of solves the gcc2 problem by
itself.
Have you really thought this through yet?
Anyway, I guess I cannot just miss out on such a discussion :-)
I think we need to clearly plan our ABI future and changes, before doing
anything different from what we're doing now (slooowly working towards
R1, that is).
We have the general options (Compatibility is maintained between
releases unless otherwise mentioned):
1) Use gcc2 as stable ABI, anything else is experimental (and that would
therefore also include the x86_64 ABI). gcc2h is the default release.
2) Like 1, but the default release would be gcc5h -- IOW the
replicants/screensaver/etc. ABI would not be stable.
3) Declare current gcc5 as our stable ABI, but keep gcc2 around for
compatibility, ie. gcc5h, too.
4) Declare current gcc5 as our stable ABI, and ditch gcc2 completely,
ie. gcc5.
5) Declare both gcc2, and gcc5 stable. This would require us to maintain
another compatibility layer in the future. gcc2h.
6) Like 5, but with gcc5h instead.
7) Like 5 or 6, but only maintain binary compatibility between major
releases. This is pretty much how the Linux world works.
Each option has its own set of advantages and disadvantages.
1) was our answer to this question so far; personally I wouldn't mind
much between 1) and 2). I find having a current ffmpeg and libraw quite
tempting, at least.
I'm still doing my taxes with Gobe Productive, so I'm very interested in
keeping gcc2 alive as long as possible :-) Perhaps until a valid
successor becomes available on Haiku, though.
But no matter how we decide, some options require more work than others.
Also, I would like to examine our options to make our packages more ABI
agnostic so that you can use the same package no matter if you're using
gcc2h or gcc5h. That would make us a lot more flexible with regards to
that stuff.
Bye,
Axel.
Other related posts:
