Sunset support for Ubuntu 16.04 after PCL 1.11.1

[kunaltyagi]

There's consensus among the maintainers to not support PCL 1.12 on Vanilla 16.04 at least. We might still keep the CI running till the actual EOL date.

Actions to take in preparation of EOL

• [x] Add a 18.04 CI (currently only clang is active, gcc is not)
• [ ] Enable -Werror on all 18.04 CI
• [ ] Bump minimum supported versions of all development dependencies:
  • [ ] cmake (>= 3.10.2) (tracked in #4264)
  • [ ] compilers (gcc >= 8.4, clang >= 10.0) (several available, these are highest we can push to)
  • [ ] Eigen (>= 3.3.4)
  • [ ] FLANN (>= 1.9.1)
  • [ ] Boost (>= 1.65)
  • [x] VTK (>= 7.1.1 , < 9, patch in progress)
  • others
• Remove fixes and hacks for old versions (need to be enumerated)

List of new features available for use/abuse

CMake

• Native support for CUDA language
• googletest support
• OpenMP + Clang support
• FindBoost improvements
• Updates to if command for comparisons
• compile_features instead of flags (eg: C++ 17 polyfill features) (PCL might still remain at C++14)
• Doxygen support
• Clang tidy integration
• cppcheck integration
• and more (<-- That's just 1 release)

Compilers

GCC

• -Wreturn-type
• Stricter template checking
• alignof changes
• null value check

Clang

• new diagnostics
• OpenMP 5 support (Don't know the status in GCC)
• new sanitizers

Eigen

• Fixes for NVCC 9
• looks like bug fixes

Boost

Minor improvements

FLANN

Couldn't find release notes, but here you go

VTK

Not familiar with VTK usage in PCL. Please distil the following:

• VTK 7
• VTK 7.1

List of deprecated features

CMake

• New policies for AUTOMOC and AUTOUIC (Might help with Qt)

Compilers, Eigen, VTK, Boost

(should not affect PCL)

[SunBlack]

16.04 has reached the end of standard support on April 30 (see here), so we can start to remove it, or? So no PCL 1.11.2 is planed, right?

[kunaltyagi]

No 1.11.2 is planned, and we've already removed 16.04 CI

[SunBlack]

• [ ] Bump minimum supported versions of all development dependencies:

  • [ ] compilers (gcc >= 8.4, clang >= 10.0) (several available, these are highest we can push to)

Just to mention: Ubuntu 18.04 (focal) just have GCC 7.4 and Clang 6.0

But we could think about switching to C++17 (most things of C++17 are delivered with GCC 7, Clang 4 and MSVC 2017 (19.1x))

[kunaltyagi]

Switch to C++17 also depends on our downstream users (ROS being a big one, stuck on c++14).

The default use of C++17 in gcc is promising. We might move to that once C++17 is default in oldest STL. Till then, we'd have to keep C++17 usage in cpp files (linking across different standards (and gcc versions with complete support) is safe. See this SO question).

I don't know the situation with MSVC or clang (Linux and MacOS).

Meanwhile, we're adding some polyfill c++17 features bit by bit (no focused development) like recently added if constexpr macro.

[larshg]

Should we require Eigen 3.3.7 as we install that specifically on our CI's? Even though 3.3.4 is still default on 18.04? (however its only for the GPU modules).

[kunaltyagi]

Can we add a find_package again in GPU modules? That could solve the issue of this disparity.

[larshg]

We can surely check the version and disable GPU/CUDA and display a warning, why its disabled? However, the problem about accidently making use of 3.3.7 feature/bugfix which is not in 3.3.4 is possible as we don't have CI's with 3.3.4.

[kunaltyagi]

That is reasonable. Link to release notes for list of bugfixes: https://eigen.tuxfamily.org/index.php?title=ChangeLog#Eigen_3.3.7