LongTerm3 branch created

33 views
Skip to first unread message

Neil Hodgson

unread,
May 29, 2017, 9:50:48 PM5/29/17
to Scintilla mailing list
The repository now contains a LongTerm3 branch to allow maintenance changes targeting projects that must use older compilers. Commits to this branch should only use C++11 features and be compatible with GCC 4.8 and MSVC 2015.
https://sourceforge.net/p/scintilla/code/ci/4c1084a571ff10060a1eedcbcbe0b0b35cc7a0b9/

Group members can request privileges to the repository to commit changes to this branch. Its up to the people that require these older compilers to determine what changes can go in the branch. I may commit some important fixes but others may desire minor fixes and features to be backported from the 4.x branch.

Alternately, a separate repository could be created for this work if that is what the users prefer.

If anyone wants to support even older compilers then more branches could be made.

The 4.x (default) branch may start using C++14 and C++17 features targeting GCC 7.1, Clang 4.0 and MSVC 2017.1.

Neil

KHMan

unread,
May 30, 2017, 3:18:51 AM5/30/17
to scintilla...@googlegroups.com
Hmmm, is there any gcc 7 for Windows? I have MinGW/MSYS, TDM gcc
and MSYS2 installed. Of the three, MSYS2 is up to gcc 6.30...

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia

David Macek

unread,
May 30, 2017, 3:32:34 AM5/30/17
to scintilla...@googlegroups.com, kein...@gmail.com
On 30. 5. 2017 9:18, KHMan wrote:
> Hmmm, is there any gcc 7 for Windows? I have MinGW/MSYS, TDM gcc and MSYS2 installed. Of the three, MSYS2 is up to gcc 6.30...

I believe some people have been building it since before release so I guess the release version shouldn't be a big problem. For example mingw-builds seems to be at v7.1.

The MSYS2 maintainer currently doesn't have time to upgrade to v7.1 and properly test it, but you're free to build your own toolchain by modifying our build scripts. I suggest popping into the #mingw-w64 and #msys2 channels on OFTC to learn more.

--
David Macek

Mike Lischke

unread,
May 30, 2017, 3:40:15 AM5/30/17
to scintilla...@googlegroups.com
Hi Neil,
As much as I value the new features in C++14 and 17, but unfortunately Linux distros are not that fast (except Fedora) and the best I can hope for is C++11 for quite some time. So I certainly need a C++14/17 free Scintilla version for another year or 2 :-/. Will you release a C++11 only version of Scintilla along with the standard release? Also bug fixes should be merged to the longterm branch as long as possible.

Mike
--
www.soft-gems.net

KHMan

unread,
May 30, 2017, 5:28:21 AM5/30/17
to scintilla...@googlegroups.com
Thanks for pointing me to mingw-builds.
Looking at the distribution list at:
https://mingw-w64.org/doku.php/download
I guess the info is not all up to date, but at least I am now
better informed of the available platform options.

I see that mingw-builds is up to 7.1.0.

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
I'll try the binaries sometime, thanks.

Neil Hodgson

unread,
May 30, 2017, 7:39:37 PM5/30/17
to scintilla...@googlegroups.com
Mike Lischke:

> As much as I value the new features in C++14 and 17, but unfortunately Linux distros are not that fast (except Fedora) and the best I can hope for is C++11 for quite some time.

Ubuntu already has Clang 4 but missed GCC 7.1. Fedora 26 has GCC 7.1 and should be released early July.

> So I certainly need a C++14/17 free Scintilla version for another year or 2 :-/. Will you release a C++11 only version of Scintilla along with the standard release?

I’d like to have someone else start making 3.x releases although I may make a few in the near term. If no one wants to take over 3.x releases then we could move to a non-release model where people use the current repository state which I expect will become quite stable.

> Also bug fixes should be merged to the longterm branch as long as possible.

Merging non-fatal bug fixes is going to depend on volunteers. I am trying to decrease the work I perform to support old systems as it has become quite a burden.

Neil

Reply all
Reply to author
Forward
0 new messages