In previous versions of VTK, we were able to set the build output directories for the various files, which we rely on in order to be able to launch our project from within the development environment. It seems that VTK now overrides these values regardless of any values set by us.
Is this intended behaviour? Could the ability to set these values be restored to?
Thanks,
Adam
Edit: for searchability CMAKE_BINARY_OUTPUT_DIRECTORY CMAKE_LIBRARY_OUTPUT_DIRECTORY CMAKE_ARCHIVE_OUTPUT_DIRECTORY
VTK makes its build tree laid out the same as the install tree, so the CMAKE_INSTALL_*DIR variables control the build tree locations as well. So if you need the build tree laid out some way, the install directory controls are what is offered.
Adding a way to make these mismatched again will not be added because it means that what is installed needs to be generated separately from the build tree copies (for more than the few files it applies to today).
Are they matched for a certain feature of VTK?
Changing the cmake to allow setting them allows our build environment to work as expected.
Would it be reasonable to restore the CMake to something akin to
# Set up our directory structure for output libraries and binaries
if(NOT CMAKE_RUNTIME_OUTPUT_DIRECTORY)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${VTK_BINARY_DIR}/${CMAKE_INSTALL_BINDIR}")
endif()
if(NOT CMAKE_LIBRARY_OUTPUT_DIRECTORY)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${VTK_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")
endif()
if(NOT CMAKE_ARCHIVE_OUTPUT_DIRECTORY)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${VTK_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}")
endif()
Yes, this is so that find_package(VTK) works the same for a build tree as for an install tree. It’s complicated enough as it is without having to support skewed directory layouts.
Not easily. Various parts set these variables as needed. Linux and macOS also do it so that relative rpath information is the same between the build and install trees. For example, the Python and Java wrappers modify the variables to place things where they need to be for how they expect things to work. The module system also places other things relative to the libraries (e.g., CMake package information and wrapper hierarchy data).
If you need VTK to place its libraries somewhere specific, I would recommend skipping the top-level CMakeLists.txt, including whatever support stuff you need from CMake/ and performing the scan and build yourself. Here is how ParaView builds its embedded VTK while bridging its settings over to what names VTK uses internally for various ones. You can either pass whatever you want to the various _DESTINATION arguments to vtk_module_build or let it set it up based on the CMAKE_INSTALL_*DIR variables as needed. But the install and build trees are going to have the same layout just so that some sanity is preserved 
.
If location of DLLs were the same in the install and build tree then we were good, but unfortunately they are different:
<build>/bin/Release (or Debug, …)<install>/binWe decided to install VTK in the build tree because having hundreds of include folders caused lots of issues (exceeding all kinds of maximum path and environment size limits). However, in the install tree we don’t have the Release/Debug/RelWithDebInfo/MinSizeRel subfolders.
If we are not allowed to set folders to a custom location then how can we make the build and install tree folder structure to be truly the same?
That is multi-config generators getting in the way. Ideally, we’d have different library names per configuration and just drop the subdirectory. However, Python and friends throw a wrench into this: they want the subdirectory above the site-packages because vtkmodules.Debug.vtkCommonCore isn’t really suitable (and neither is vtkmodules.vtkCommonCore_RelWithDebInfo). My suggestion for day-to-day use is to use Ninja rather than Visual Studio as a generator (Visual Studio can now load Ninja builds too, so if you’re using it as a debugging tool, you are no longer hostage to their slow builds).
If you absolutely must use multi-config generators, I’m afraid you’re stuck with just the install tree; the details of getting a build tree layout that makes any kind of sense just isn’t worth the effort it would require IMO.