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.