See also for googletest on travis-ci: https://github.com/google/googletest/blob/master/.travis.yml
And there is libgtest-dev on ubuntu, but the project stopped doing point releases a long time ago (~2005). https://github.com/easylogging/easyloggingpp/blob/master/.travis.yml https://amodernstory.com/2015/07/27/upgrading-travisci-build-scripts/ On Mon, May 9, 2016 at 11:38 AM, Kurt Schwehr <schw...@gmail.com> wrote: > Agreed on the 11 v 14 issues. > > On Mon, May 9, 2016 at 11:17 AM, Even Rouault <even.roua...@spatialys.com> > wrote: > >> Le lundi 09 mai 2016 19:28:48, vous avez écrit : >> > Here is my current take on language standards >> > >> > - I am working on a C++11/14 C99/11 proposal. I despirately want to be >> > able to use C++11 to make GDAL more robust >> >> C++11 is probably OK, but C++14 support is really "new". For Linux >> distros, we >> should try to make GDAL compilable on the current LTS and probably in the >> case >> of Ubuntu last-1 LTS with their default compiler. >> >> For example RHEL 7 ships with gcc 4.8.X, Ubuntu 14.04 too. >> I've checked that gcc 4.8 refuses -std=c++14. It accepts -std=c++1y >> though, so >> some features of C++14 might be available. >> >> At least for the sake of our CI environements : Travis has no immediate >> plans >> for now to ship with with Ubuntu 16.04 ( >> https://github.com/travis-ci/travis- >> ci/issues/5821 <https://github.com/travis-ci/travis-ci/issues/5821> ) >> >> > - As it stands I will vote >>>against<<< my proposal any time soon - >> until >> > with have a bunch of proposals for changes to GDAL that require new >> > language versions or someone rewrites my proposal to be much more >> > compelling - > > Which proposal exactly ? AFAICS in this thread, it was more about polling >> opinions. >> > > I have not sent out the doc yet. > > > >> >> > We have lots of work that we can do to make GDAL maintenance >> > / debugging easier that does not require newer language versions >> > - We have successfully ( at least in my opinion ) stuck a toe in the >> C++11 >> > world with CPL_FINAL, CPL_DISALLOW_COPY_ASSIGN, NULL_AS_NULLPTR, and >> > my std::lock_guard<std::mutex> experiments. We can probably do a bit >> more >> > if we are careful. >> > - I think having an experimental autotest2 C++11/14 only testing tree >> might >> > be the way to start. Those who want to can try it out or look through >> what >> > is possible and it won't impact the main tree or the existing C++ tests. >> > >> > >> > I would be happy to start contributing to >> > https://trac.osgeo.org/gdal/browser/trunk/autotest2, especially if we >> call >> > it experimental and I can get help with adding a build system. I have >> > >> > >5000 lines of C++ in 32 test files that mostly cover the port directory >> > >> > right now. I got hung up on trying to create a working initial version >> in >> > a separate github tree. Adding it to the existing svn tree would get me >> > around that issue (it's an internal work thing). Here is >> > cpl_string_test.cc... it's super boring. >> > >> > https://gist.github.com/schwehr/02128959ee78d56b553defa0a527bdf2 >> > >> > It's written using the Google C++ style guide and is based on gunit, >> gmock >> > and glog. >> > >> > - https://google.github.io/styleguide/cppguide.html >> > - https://github.com/google/googletest >> > - https://github.com/google/glog >> >> Are those available as ready to be installable packages ? (thinking about >> integration with CI) >> >> > The people who maintain gunit/gmock prefer that projects package the gunit > code inside their repos. > > git clone g...@github.com:google/googletest.git > cd googletest > find . -type f | wc -l > 340 > > du -hs > 8.9M . > > e.g. for libais, I just made third_party and put them in side that... > > https://github.com/schwehr/libais/tree/master/third_party > > >> > >> > On Mon, May 9, 2016 at 2:33 AM, Mateusz Loskot <mate...@loskot.net> >> wrote: >> > > On 7 May 2016 at 19:10, Kurt Schwehr <schw...@gmail.com> wrote: >> > > >> If we move to a later C++ standard, or even use features of C++98 >> we >> > > >> currently >> > > >> don't use, I'd advocate for using things that are obviously making >> the >> > > >> code >> > > >> better / more readable. Honestly who finds that >> > > >> "std::unique_ptr<int *, std::function<void(char *)>> >> > > >> Vals(CPLCalloc(256, 0), >> > > >> CPLFree);" is obviously more readable, efficient and less error >> prone >> > > >> > > than >> > > >> > > >> "std::vector Vals(256,0)" ? >> > > > >> > > > This is cart before the horse but... as fast as I can so expect >> typos. >> > > >> > > Now >> > > >> > > > just think of a ~1K long function or method with tons of instances >> and >> > > >> > > lots >> > > >> > > > of places to bailout successfully or as failures. We have > 9K >> > > > free/CPLFree/CPLdelete/CPLDestroys that could be < ~100. >> > > > [...] >> > > >> > > ...the very long story short, your desire is to introduce the RAII >> idiom >> > > across GDAL codebase. Awesome! >> > > I'm sure 99% of GDAL committers will welcome this idea. >> > > Then, **next** question is how we want to implement it: >> > > using C++11+ features, home-brewed smart pointer class(es), etc. >> > > >> > > Upgrading to C++11+ just for the sake of upgrade, makes little sense >> to >> > > me. Especially if folks are not certain about it, don't use those >> > > features daily, >> > > don't feel comfortable...it may cause more harm. >> > > >> > > Best regards, >> > > -- >> > > Mateusz Loskot, http://mateusz.loskot.net >> >> -- >> > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
