Even Visual Studio 2017 is not quite stable yet, so I did not dare try 2019 yet. I had a feeling they will simply declare VS2017 “finished”, publish VS2019, and keep updating it as they had VS2017 so far. This is just my impression, though.
I tried to compile ITK with it and it was failing on some vnl targets. I’ll test it again after the next preview is released 
Hello folks,
I’m digging up the topic to know if any of you has tried VS2019 with ITK5.0 recently?
I’m wondering if I should update !
Tim
Yes, I tried it. With default setting, it fails compiling due to buggy asynchronous writing to debug symbol database. Workaround is to add /FS to CMAKE_CXX_FLAGS so it reads /DWIN32 /D_WINDOWS /W3 /GR /EHsc /FS.
2 Likes
Thanks for the follow-up and reporting to VS team Dženan !
I will give a shot to VS2019, but as always it seems that we have to wait a bit to have a stable VS solution…
1 Like
Are you just building SimpleITK against pre-built ITK, or do you build both?
MSVC 16.1.1 (a very recent stable version) was choking on itkv3p_netlib.pdb and one other library (if I remember correctly). For some reason, not everyone encounters this. Also, version 16.0.0 was failing on some 200-300 libraries out of default about 600 in ITK. Which means they are making progress, and thus probably aware of the problem.
I am doing the SimpleITK super build so it’s building just about everything including ITK from scratch.
The Azure DevOps image seems to indicate that its running VS 16.0.3+28803.352: https://github.com/microsoft/azure-pipelines-image-generation/blob/master/images/win/Vs2019-Server2019-Readme.md
1 Like
Follow-up: I’ve tried with the latest version (16.1.5), and compilation still choke on some libs as described by @dzenanz (netlib, vnl_algo, etc). The /FS flag workaround works however.
2 Likes
See :
for a potential uniform method of addressing this problem from the ITK master branch.
2 Likes
But we do need to be on ITK Master. When is the next release scheduled?
5.1.0 is scheduled for November. 5.0.2 for September. See the milestone list.
@matt.mccormick @blowekamp does it make sense to back-port PR1165 to 5.0.2? I assume that changes in parts of VXL which we use were minimal. @hjmjohnson can you confirm that?
1 Like
The changes to VXL necessary to make VS2019 work should be constrained to the main CMakeLists.txt file, and only a few isolated lines.
2 Likes
Is that going to be back ported to ITK 4.13.3(?)
The major issue I have now is that I have clients trying to compile our source codes with VS 2019 (probably with the default compilers) and ITK is failing to compile with no real way to get them out of the hole that they find themselves in.
The actual changes are super small, and should probably be easy to back-port them even to 4.13.3. But VXL underwent a major refactoring for ITKv5, including the build system, so I am not sure it is trivial.
OK, I will try back-porting this to 5.0.2 and 4.13.3.
2 Likes
I had been building SimpleITK (against ITKv4) in Release mode with VS2019 on Azure Pipelines OK. I believe that release mode was free of the debug symbol database bug. Recently a new compilation error started to occur with the following GDCM::
error C3848: expression having type 'const gdcm::dircos_comp' would lose some const-volatile qualifiers in order to call 'bool gdcm::dircos_comp::operator ()(const gdcm::dircos_key &,const gdcm::dircos_key &)'
I may look into back porting a fix to ITK 4.13 as well.
1 Like
Back-port for 4.13.3:
2 Likes