Shall we start using C++17 at the master branch?

Engineering
21

As was discussed with the last release candidate, there were a number of outstanding, critical contributions related to DICOM support that had not been integrated. These have now been integrated. 5.4 RC 3 will be the last release candidate.

Yes, changes to build requirements should not be made until after v5.4.0.

3 Likes
22

Another year later, would it now be acceptable to use std::filesystem in ITK?

Looks like it is supported “out of the box” from GCC 9.1 and from LLVM 9.0 (for clang). Older compiler versions would require an extra compiler flag. According to cppreference.com/w/cpp/filesystem:

Notes

Using this library may require additional compiler/linker options. GNU implementation prior to 9.1 requires linking with -lstdc++fs and LLVM implementation prior to LLVM 9.0 requires linking with -lc++fs.

1 Like
23

A blocker is the Python binaries require specific OSX deployment targets for binary compatibility. And to use std::filesystem in particular require OSX 10.15 deployment target, I believe the current deployment targets may be 10.13 at the newest, but I wasn’t able to quickly find an official reference…yet. However, other C++17 features can be used with out the requirement for the newer OSX SDK.

2 Likes
24

Yes, annoyingly, std::filesystem requires macOS 10.15 at runtime. I believe this is because the version of STL shipped with macOS only started supporting std::filesystem as of 10.15. So even if you use newer macOS and clang to build your code, it won’t run on anything older than 10.15.

My oldest bot building ITK nightly is for 10.13.

Personally, I’d be OK with increasing ITK 6’s minimum from 10.13 to 10.15 at this point. (I would certainly much rather that than dropping Intel support for example!)

Sean

1 Like
25

O, these are related. The first OS to support that ARM was 11 Big Sur, so these issues are related :slight_smile: Dropping intel implies 11 as the minimum supported version.

26

We (the NIAID SimpleITK folks) are still on 10.14. 10.15 hasn’t been approved by management. One of us is still using an Intel Mac as his main laptop. :man_facepalming:

1 Like
27

Sure, but (hypothetically) requiring macOS 11 as ITK’s minimum does not imply Intel support should be dropped. There are Intel Macs that run the very newest macOS 15.

Alas, the Mac world is not like the Linux world, where you can update even quite old PCs to run the newest Linux. macOS drops hardware support (too) quickly, and so users often can’t upgrade their macOS even if they wanted to.

28

At the application level of 3D Slicer (which uses ITK) the CMAKE_OSX_DEPLOYMENT_TARGET is set to 13.0 as providing support for OS versions that were no longer receiving security updates is not worth the effort for latest development. macOS 13.0 deployment target sets support for hardware ~8 years old and newer to run the latest application version. This seems appropriate as it relates to supporting a MacBook Pro all the way from 2017.

Similarly with Windows 10 consumer versions going EOL later this year, Windows 11 requires CPUs from about Intel 8th gen and newer which also corresponds to hardware from about 2017 and newer.

29

Why such a long delay? If you don’t know, can you speculate?

30

I believe he meant 15, not 10.15.

31

Oh you’re right. I got confused, since they stop using 10.XX versions.

32

Well then requiring MacOS 10.15 as the minimum should not be so outrageous?

1 Like
33

Well then requiring MacOS 10.15 as the minimum should not be so outrageous?

It’s OK for me at this point. Our current app still supports 10.13, but our next major release is upping that to 10.15.

34

Here some documentation regarding setting the target deployment target when building Python binaries: Modern C++ standards - cibuildwheel

I suppose I am conservative when building binaries, and set the target version to match that of the python.org target version.

35

You could always substitute in “GHC_FileSystem” which I think is what made its way to std::filesystem. The easiest way is to just use a #ifdef to figure out if you are on APPLE and then just alias the namespaces to “fs” so:

#ifdef EbsdLib_USE_GHC_FILESYSTEM
#include <ghc/filesystem.hpp>
namespace fs = ghc::filesystem;
#else
#include <filesystem>
namespace fs = std::filesystem;
#endif

Then in our CMakeLists.txt file we have:

#-------------------------------------------------------------------------------
# Determine if we need the ghcFilesystem library
#-------------------------------------------------------------------------------
set(EbsdLib_USE_GHC_FILESYSTEM OFF)

if(APPLE)
  execute_process(COMMAND uname -v OUTPUT_VARIABLE DARWIN_VERSION)
  string(REGEX MATCH "[0-9]+" DARWIN_VERSION ${DARWIN_VERSION})
  if(DARWIN_VERSION VERSION_LESS 19)
    message(STATUS "The current macOS System is too old to compile and will fail. Please set the EbsdLib_USE_GHC_FILESYSTEM=ON variable to allow Ebsdlib to compile")
  endif()
  message(STATUS "EbsdLib: DARWIN_VERSION ${DARWIN_VERSION}")
  message(STATUS "EbsdLib: CMAKE_OSX_DEPLOYMENT_TARGET: ${CMAKE_OSX_DEPLOYMENT_TARGET}")
  if(NOT "${CMAKE_OSX_DEPLOYMENT_TARGET}" STREQUAL "" )
    if(CMAKE_OSX_DEPLOYMENT_TARGET VERSION_LESS 10.15)
      message(STATUS "EbsdLib: CMAKE_OSX_DEPLOYMENT_TARGET less than 10.15. Enabling EbsdLib_USE_GHC_FILESYSTEM")
      set(EbsdLib_USE_GHC_FILESYSTEM ON)
    endif()
  endif()
endif()
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux" AND ${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS 9.0)
  set(EbsdLib_USE_GHC_FILESYSTEM ON)
endif()


message(STATUS "EbsdLib: EbsdLib_USE_GHC_FILESYSTEM: ${EbsdLib_USE_GHC_FILESYSTEM}")

if(EbsdLib_USE_GHC_FILESYSTEM)
  find_package(ghcFilesystem REQUIRED NAMES ghc_filesystem ghcFilesystem)
endif()

And I remember that working fairly well.

If you just move to a MacOS deployment of MacOS version 11.0 then you don’t need any of this. If we are talking in the context of ITK 6 then I think it is time to leave some of these ancient systems behind.

2 Likes
36

Thanks to you all for your feedback so far. This is very helpful.

I don’t have an urgent need to use std::filesystem right away, within the implementation of ITK. It’s only that we are considering to use it in the implementation of elastix. Specifically for ENH: Add IMPACT Similarity Metric to Elastix by vboussot · Pull Request #1311 · SuperElastix/elastix · GitHub Elastix usually follows ITK, regarding the use of C++ features. (elastix also uses ITK internally.) So in general, we are a bit reluctant to start using C++ features in elastix, that are not yet allowed in ITK. But I think now that it would be OK for elastix to use std::filesystem.

1 Like
37

Related GitHub issue for macOS 15 deployment target: