Again - the Windows command line length limit

Development
1

The ParaView derived custom application builds nicely, but during the “superbuild” appears a bug that is somehow not understandable…

After many other reasons were excluded, it looks like I am hitting once more that stupid command line length limit of Windows: The failing command line has 8802 characters.

I know several ways to work around this problem. First of all, all my paths are already reduced to very short folder names. However, the most powerful workaround is to use temporary files for the commands and “feed” them to cl.exe instead of very long command lines.

Problem: In the middle of a complex “superbuild”, I do not see how I could “convince” the build system to do it. Ideally, this should be some options built into CMake or Ninja, but so far I could not find any such thing.

How is this handled at Kitware? Just same as my current “trick” so far: minimize path lengths?

(I have not tried a ParaView superbuild lately, but my own should “contain” such a superbuild, and with another custom software it works well, so it is still possible that I would have to fiddle somehow with my setup to shorten and shorten and shorten… the paths…)

2

The analysis looked very obvious - and was still wrong! The reason for the failure is very different - and looking at it from the current point of view, it could have been visible also before…

Symptoms: Compilation of a cxx source file failed due to unknown class during the “superbuild”, after all was perfect and running during a “normal build”.

Finding: The error message was showing a command line that was 8802 characters, and when I copied it and tried to run it directly, it failed again - although with different error messages. (HERE I should have taken this more seriously!) This problem looked so familiar to me that I was pretty much convinced that it must have been the reason: Superbuild and Build are not working in the same folders, paths tend to be longer in the first, so “somehow” this looked like it made sense.

Trial: Changing the target path for the superbuild to a minimum of C:\agb would have brought the affected command line to clearly below 8000 characters, so it should have solved the issue. I wrote the above message, it was also evening and building Paraview takes still about an hour on my system, so I started the “solution” and left.

Result: Still exactly the same error message! No explanation any more at hand.

Question: Why is the class once “known” and once “unknown”, with exactly the same source code? The actual class is vtkCompositeDataToUnstructuredGridFilter, and I found out that even during the “superbuild”, the header file was correctly included.

New track and solution: Having a closer look into that header file finally clarified the situation: #if !defined(VTK_LEGACY_REMOVE)!! It turned out that for the “superbuild” this flag was defined TRUE, while in the “normal build” it was not. But the only effect of this definition was the “unexplainable” error message about an unknown class!

Normally this would have triggered my attention towards the header file immediately, but after I had seen that it compiles and builds just fine within my development environment, I was looking not for any syntax or code problems, but at possible differences that are related to the project setup.

CONCLUSION: Wouldn’t it be a good idea to add some #else branch to the #if, containing an explicit #error output that points the developer to the right direction?

Of course I learned now the lesson, and another time I will hopefully consider such a possibility a bit earlier, and a possibly smarter guy than myself would have seen it immediately, but my above proposal would not cost much and avoid tedious misunderstandings.