I am seeing some new build errors on CDash this morning.
Here is a new link error that looks like “-lm” may not be added? Any one have any ideas on a change yesterday or why?
../../lib/libITKNrrdIO-5.0.so.1: error: undefined reference to 'sqrt'
../../lib/libitkpng-5.0.so.1: error: undefined reference to 'floor'
../../lib/libitkpng-5.0.so.1: error: undefined reference to 'pow'
collect2: error: ld returned 1 exit status
c:\d\itk-vs11-32rs\itk\modules\core\common\include\itkMathDetail.h(34): fatal error C1083: Cannot open include file: 'cfenv': No such file or directory (C:\d\itk-vs11-32rs\ITK\Modules\Core\Common\src\itkMemoryProbesCollectorBase.cxx) [C:\d\itk-vs11-32rs\ITK-build\Modules\Core\Common\src\ITKCommon.vcxproj]
Now is a chance to drop compiler support without too much fuss. Not having constexpr support is certainly going to bother us, and limit how much improvements we could use during this rewrite opportunity.
It would be very frustrating I think to say that ITK is C++11 compatible, but not have access to a feature like const expr, so even though that might be painful at first to drop VS2013 (VS12), I think it is a good thing to do it now.
Please note even with VS14 20015 (MSVC 19.0), some C++11 features are still listed as partial or “buggy”. This include constexpr being listed as “partial”.
Thanks for the new feature table. If VS2015 (VS14) ends up being too limited, we could see what we can do, but if it only has a few limitations, we can cross our fingers and hope that it is sufficient for the usage we will have of that functionality. My guess is that it would fail in some corner cases, and hopefully it won’t be a problem for ITK. We can always drop VS2015 support in the future if it is too limiting, but as long as it is not an issue, we should still use it.
We should not drop VS2015 for 5.0. VS2017 is still essentially under development, which means that VS2015 is the last stable version of the Microsoft’s compiler.
If we run into limitations imposed by VS2015’s incompleteness of support for C++11, we should probably be able to work around it. If that requires too much effort, we could simply postpone it for later, adding it to the wish list.
FYI For me as ITK user, it’s not so easy to drop VS2013, because I use ITK in combination with a version of MeVisLab (2.7.1) that only supports VS2010 to VS2013 (See https://www.mevislab.de/download)
According to the Nightly Build Instructions, 3D Slicer’s tested and recommended build environment on Windows is Visual Studio 2013. There is no mention of Visual Studio 2015. @jcfr@lassoan What version of Visual Studio are the Slicer Nightlies built with? Is requiring Visual Studio 2015 going to be an issue?
As a Windows user, I guess the pain is mitigated since the advent of Community Editions of Visual Studio.
From the medical imaging software industry point of view, I’d say that this might be more of a concern for companies that may be selling software based on ITK and who used VS12 or earlier to clear (FDA or CE) their product.
But as said earlier on another thread of the discussion forum, we cannot have a modern toolkit using not-so-modern tools
The Gearing up to ITK5 announcement already forecasted the support drop for VS12 (2013) as a likely one.
So I’m fine with dealing with the trouble this can cause now to produce a better ITK.
Now, if VS14 (2015) support is patchy and buggy, and if our buildbots are reporting errors, then I’d postpone the use of constexpr. However, it looks like we have only one VS 14 build at dash4win7.kitware.com, which is not reporting issues.
Dropping support for a 2/3 yr-old compiler does not seem desirable to me. So may be further testing is needed?
As a complement of information: MeVisLab supports VS2015 as of version 2.8.1 and VS2017 as of version 3.0.1. @Niels_Dekker: Looks like you are stuck one version too old
Slicer will switch to VS2015 within a couple of weeks.
In general, an application can only switch to a more recent compiler if all the libraries it relies on support the new compiler. Requiring a 2-year-old compiler may be problematic.
I would suggest to have a look at compiler support of other libraries that are used by ITK community members (VTK, Qt, Python, etc), and try not to drop compiler support much earlier than others.
VS2015 is now almost 3 years old, and VS2013 more than 4 years old. And the reason Microsoft was releasing compilers almost every year recently was because they were lagging far behind in implementation of C++11. With VS2017 they switched to releasing a lot of minor versions which slowly improve standards compliance and incrementally implement features.
And since ITKv5 will not immediately introduce new algorithms, end-user applications which can’t use C++11 can keep using ITK 4.13.
VTK did the switch to C++11 earlier than us, and probably doesn’t need constexpr as much as ITK does, because VTK is not fully templated library like ITK is.
The good thing for ITK is that transition is happening now, so we can take feedback from the community. Thanks everyone for chiming in. So far, it sounds like Slicer and MeVisLab both require or will require very soon VS2015. From that point of view, ITK seems to be on par with these libraries. Same thing for Python, since ITK is only supporting Python 3.5 and above on Windows. It also look like Orfeo Toolbox, another library that uses ITK needs VS2015. So from the point of view of the ITK ecosystem, it doesn’t seem unreasonable to require VS2015.
The downside of this is that some users are currently using, and may be stuck with, Visual Studio 2013.
Until this patch, there was a suboptimal solution implemented in ITK to support constexpr. One option would be to reinstate the code removed in this patch for VS2013. We could have this to keep things working until they break for real in VS2013 when some code that requires constexpr is actually added. However, this is not great either because people using VS2013 will think that ITK works with that compiler, and new problems will arise when ITK takes full advantage of constexpr.
Personally, I think that the best solution for ITKv5 is to require VS2015. Hopefully, by the time the transition to ITKv5 is over, in a couple months, people will have time to move to VS2015 or VS2017.
Let’s not forget: Those who have legacy products that are integrated with other legacy products that require VS2013 CAN USE ITK 4.13 for all eternity!
The point of ITK5 is NOT to ensure that all old programs that depend on legacy development environments continue to build, but rather to ensure that future improvements can be made.
I also second @fbudin 's analysis. Visual Studio 2015 seems reasonable given the state of the ITK ecosystem.
At the same time, as @lassoan suggested, we should be sensitive to the situation of projects that depend on ITK. We should not, for example, require Visual Studio 2017 before these projects have adopted it. We value existing projects in the community, and we make a best effort to serve their needs. We want them to continue to use and contribute to the latest version of ITK.
This is not true – we are not committing to support for ITK 4.13 for all eternity
Qt’s latest version (5.10) still has not dropped VS2013 support yet, so ITK dropping VS2013 support now would be a bit early. However, if there is an ITK LTS version with VS2013 support for 3 years; and long-term ITK platform strategy and dates are clearly communicated, then ITK would not put too much stress on application developers.
