Why not drop gcc2 and BeOS r5 compatibility, de need more user and
developer and de can this do, lets do. All arguments with gcc2 are out of
time.
Am 01.12.2016 22:22 schrieb "kallisti5" <kallisti5@xxxxxxxxxxx>:
On 2016-12-01 15:02, Adrien Destugues wrote:
On Thu, Dec 01, 2016 at 09:44:27PM +0100, Ingo Weinhold wrote:
On 12/01/2016 04:55 PM, kallisti5 wrote:
Through all of these conversations, i've never once said to "get rid32-bit
of gcc2 (at least until R2 and beyond ;-)) In my eyes having
x86_64 + gcc2 would be ideal for R2 (but we need to work on running
code on 64-bit systems)
Just for sake of completeness, since that argument hasn't been mentioned
in
this iteration of the discussion yet: Keeping gcc 2 support at all --
even
just as a secondary architecture -- means that the code that needs to be
compilable with gcc 2 (i.e. most of the libraries) cannot use modern C++
features. This hurts more and more with each new C++ standard and is
definitely not helpful for attracting new developers.
The only reasonable option for going forward I see at this point is to
add
missing FBC goodies to the gcc 4+ API and fork off the gcc 2 support,
either
in-tree or even outsource it.
I plan to maintain the gcc2 support in the branch created for beta1,
with releases from that branch from time to time until it reaches R1.
That would leave the trunk free for a gcc5-only version, first steps
towards R2.
So wait, we're saying...
* Branch R1 *soon* and make a R1B1 beta release gcc2h
* PulkoMandy (and others) will cherry-pick bug fixes to R1 branch.
* Master is now targets R2
My only worry is R1 will get really outdated, we won't get a release out,
and we'll have to fold the R1 branch back into master (or toss it)
I guess that makes sense, we can then use the "stable R1" branch in future
hybrid concoctions of R2 with gcc2 secondary.
