The Vagrantfile was created initially to be a copy of what jenkins had and mirrored our system test env. My goal with the Dockerfiles has been to create just that, a set env that is guaranteed to build and test from. The Ubuntu Dockerfile is what will be used on jenkins soon for the main system and should be considered the reference platform. I'm working on fixing the couple issues raised in THRIFT-3042 for the containers now
-Jake On Thu, Mar 19, 2015 at 12:00 PM, Randy Abernethy <[email protected] > wrote: > I think Jens makes a good point +1. We need to clearly communicate this > stuff, this should be front page news on the web site with a plan and > milestones when a consensus develops. > > I also think we should deal with Cpp for users (lib/cpp and generator > output) separate from the compiler source (compiler/cpp/src). They are not > really linked. The compiler just happens to be written in Cpp. It could > just as easily (and might have been better) written in C. There are many > people who use Apache Thrift who don't care at all about C++, using thrift > to build systems with Java, Node, Python, etc. I would be ok with changing > the compiler source language to Cpp11 if there was a benefit. Is there? > Perhaps pulling from fbthrift is motivation. Would like to hear what others > think. All of the compiler patches I have reverted to Cpp98 in the last > year have been fairly trivial and easily changed to C++98 (again > communications either way cpp98 or cpp11 needs to be clear). > > I also think this would be a good juncture to clearly communicate a > reference platform. We would like to build everywhere but we need to start > by building somewhere. We need a repeatable way all Committers/Users can > build/test the platform such that when it doesn't build on that platform > everyone agrees there is a problem to address as a blocker. This will make > Jenkins and other CI actually meaningful. This is the #1 productivity > change in practice we could make in my view. > > > On Thu, Mar 19, 2015 at 1:13 AM, Jens Geyer <[email protected]> wrote: > > > Our company policy is to follow Microsoft with regard to supported > Windows > > versions, and we made good experiences with that approach. > > > > That means to deprecate and mentally prepare to drop WinXP in near > future. > > It does not imply taking any action immediately, but as soon as WinXP > > compatibility hinders us in any way it's time to drop it. > > > > Have fun, > > JensG > > > > > > ----- Ursprüngliche Nachricht ----- > > Von: Ben Craig > > Gesendet: 18.03.2015 21:22 > > An: [email protected] > > Betreff: Re: AW: [DISCUSS] let's switch to C++11 (was Re: [jira] > > [Commented] (THRIFT-3043) go compiler generator uses non C++98 code) > > > > I am interested in seeing a more complete proposal. I think that this > > could lead to a more useful declaration of platform support. > > > > Here are some of the questions that need to be answered: > > > > What compilers will be supported for the thrift compiler? > > Mostly unanswered so far, but hints at supporting anything > > reasonably C++98 / C++03 compliant. > > What compilers will be supported for the C++ library? > > GCC answer seems to be 4.7+, with the --std=c++11. > > No current answer for Clang / XCode or MSVC. > > What OSes will be supported for the C++ library? This is closely related > > to the compiler support, as it isn't very nice to claim support for an OS > > where you can't get a supported compiler. > > Linux OSes with gcc 4.7 support... > > CentOS / RHEL 7 > > Debian 7.0+ (Wheezy) + > > Suse 12.2 + > > Ubuntu 12.10+ (quantal) > > Ubuntu 14.04+ LTS (trusty) > > Implicitly NOT SUPPORTED > > CentOS / RHEL 6 (gcc 4.4) > > Ubuntu 12.04 LTS (precise) (gcc 4.6) > > Which OSX, iOS and Android versions? > > Which Windows versions? Is Thrift going to drop WinXP? > > What will be done about the boost dependency? > > Are we going to have a migration path away from boost, or is > there > > going to be a clean break? > > > > > > > > > > From: Roger Meier <[email protected]> > > To: [email protected], > > Date: 03/18/2015 05:28 AM > > Subject: Re: AW: [DISCUSS] let's switch to C++11 (was Re: [jira] > > [Commented] (THRIFT-3043) go compiler generator uses non C++98 code) > > > > > > > > I just installed latest mingw for Windows from > > http://sourceforge.net/projects/mingw-w64/ > > > > gcc.exe --version > > gcc.exe (i686-posix-dwarf-rev1, Built by MinGW-W64 project) 4.9.2 > > Copyright (C) 2014 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is > NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > > > and on Debian Jessie we have gcc 4.9.1 > > see https://packages.debian.org/jessie/g++-mingw-w64-x86-64 > > > > > > Quoting Jens Geyer <[email protected]>: > > > > > What about mingw? > > > ________________________________ > > > Von: Roger Meier > > > Gesendet: 18.03.2015 00:44 > > > An: Randy Abernethy (JIRA); [email protected] > > > Betreff: [DISCUSS] let's switch to C++11 (was Re: [jira] [Commented] > > > (THRIFT-3043) go compiler generator uses non C++98 code) > > > > > > > > > Hi all > > > > > > We had lot of discussions and issues about C++11 support and I think > > > it is time to move the master branch development towards C++11 and set > > > this as a dependency starting wit 0.9.3 of Apache Thrift. > > > > > > reasons to move forward: > > > - no feature show stopper due to C++98 dependency > > > - no backport of patches, it's a nightmare > > > - master branch should focus towards future > > > - evolution of compiler and cpp library > > > - many developers already use C++11 capable compilers > > > - > > > > > > > > http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ > > > > > - gcc support -std=c++11 since version 4.7 > > > see https://gcc.gnu.org/projects/cxx0x.html > > > - clang 3.5 > > > - all recent Linux distros support C++11 > > > - centos 7 uses gcc 4.8.2 > > > - Debian Jessie uses gcc 4.9.2 > > > - Debian Wheezy uses gcc 4.7.2 > > > - RHEL-7.0 uses gcc 4.8.2 > > > - Suse 13.2 uses gcc 4.8.3 > > > - Suse 13.1 uses gcc 4.8.1 > > > - Ubuntu utopic 14.10 uses gcc 4.9.1 > > > - Ubuntu trusty 14.04 LTS uses gcc 4.8.2 > > > - Ubuntu saucy 13.10 uses gcc 4.8.1 > > > - it is 2015 and C++11 is ready to use in the wild > > > - C++11 compilers can easy be installed on older distros > > > - no fork of a C++11 library > > > > > > solution for older environments: > > > - C++98 can be handled on the 0.9.x branch if required > > > - install a more recent compiler > > > - http://www.necessaryandsufficient.net/2014/07/c11-on-centos/ > > > > > > What do you think? > > > > > > all the best! > > > -roger > > > > > > > > > On 17.03.2015 03:49, Randy Abernethy (JIRA) wrote: > > >> > > >> [ > > >> > > > > > https://issues.apache.org/jira/browse/THRIFT-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364464#comment-14364464 > > > > >> ] > > >> > > >> Randy Abernethy commented on THRIFT-3043: > > >> ----------------------------------------- > > >> > > >> Hey Jens: looks good, many thanks! > > >> > > >> Hey Roger: I agree, we definitely need a Cpp11 generator and lib > > >> ASAP. The only thing I am suggesting is that we keep the IDL > > >> compiler source Cpp98 until Cpp11 is ubiquitous. My hope is that we > > >> can fork the Cpp98 lib to create a Cpp11 lib and fork the Cpp98 > > >> generator to create a Cpp11 generator (which would be written in > > >> Cpp98). This way folks can use Cpp11 or Cpp98 in their user code. I > > >> think this was the plan arrived at on some other threads. The > > >> THeader pull from DJW > > >> (https://github.com/apache/thrift/pull/357.patch) is all lib so > > >> should apply fine to a Cpp11 lib fork. > > >> > > >> The IDL compiler is pretty simple and has no bearing on user code. > > >> The path of least resistance there seems to be to keep the source > > >> for the IDL compiler in Cpp98. That way it will compile under Cpp11 > > >> or Cpp98. Win win. Rewriting the compiler in Cpp11 (or Java or Go) > > >> does not seem like a good use of our time and we have precious > > >> little of it (as you pointed out on the THeader issue). Most of the > > >> Cpp98 breaking patches are due to unsupported variable > > >> initialization and the like, seems silly to cut off a large chunk of > > >> compatibility we already have in place for trivial stuff like that. > > >> > > >>> go compiler generator uses non C++98 code > > >>> ----------------------------------------- > > >>> > > >>> Key: THRIFT-3043 > > >>> URL: > https://issues.apache.org/jira/browse/THRIFT-3043 > > >>> Project: Thrift > > >>> Issue Type: Bug > > >>> Components: Go - Compiler > > >>> Affects Versions: 0.9.3 > > >>> Reporter: Randy Abernethy > > >>> Assignee: Jens Geyer > > >>> Priority: Blocker > > >>> Fix For: 0.9.3 > > >>> > > >>> Attachments: > > >>> THRIFT-3043-go-compiler-generator-uses-non-C-98-code.patch > > >>> > > >>> > > >>> go compiler generator uses non C++98 code causing builds to fail in > > >>> Centos 6 and other environments. > > >>> ==> default: src/generate/t_go_generator.cc:415: error: in C++98 > > >>> ���commonInitialisms��� must be initialized by constructor, not > > by > > >>> ���{...}��� > > >>> ==> default: src/generate/t_go_generator.cc:415: error: deducing > > >>> from brace-enclosed initializer list requires #include > > >>> <initializer_list> > > >>> ==> default: src/generate/t_go_generator.cc:415: error: deducing > > >>> from brace-enclosed initializer list requires #include > > >>> <initializer_list> > > >>> ==> default: src/generate/t_go_generator.cc:415: warning: extended > > >>> initializer lists only available with -std=c++0x or -std=gnu++0x > > >>> ==> default: src/generate/t_go_generator.cc:415: error: no matching > > >>> function for call to ���std::set<std::basic_string<char, > > >>> std::char_traits<char>, s > > >>> td::allocator<char> >, std::less<std::basic_string<char, > > >>> std::char_traits<char>, std::allocator<char> > >, > > >>> std::allocator<std::basic_string<char, std: > > >>> :char_traits<char>, std::allocator<char> > > >::set(<brace-enclosed > > >>> initializer list>)��� > > >>> ==> default: > > >>> > > > > > /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_set.h:188: > > note: candidates are: std::set<_Key, > > >>> _Compare, > > >>> _ > > >>> Alloc>::set(const std::set<_Key, _Compare, _Alloc>&) [with _Key = > > >>> std::basic_string<char, std::char_traits<char>, > > >>> std::allocator<char> >, _Compare = s > > >>> td::less<std::basic_string<char, std::char_traits<char>, > > >>> std::allocator<char> > >, _Alloc = > > >>> std::allocator<std::basic_string<char, std::char_traits<ch > > >>> ar>, std::allocator<char> > >] > > >>> ==> default: > > >>> > > > > > /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_set.h:136: > > note: std::set<_Key, > > >>> _Compare, > > >>> _ > > >>> Alloc>::set() [with _Key = std::basic_string<char, > > >>> std::char_traits<char>, std::allocator<char> >, _Compare = > > >>> std::less<std::basic_string<char, std::c > > >>> har_traits<char>, std::allocator<char> > >, _Alloc = > > >>> std::allocator<std::basic_string<char, std::char_traits<char>, > > >>> std::allocator<char> > >] > > >>> ==> default: make[3]: *** [thrift-t_go_generator.o] Error 1 > > >>> ==> default: make[3]: Leaving directory `/thrift/compiler/cpp' > > >>> ==> default: make[2]: *** [all] Error 2 > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.4#6332) > > >> > > > > > > > > > > >
