[vtk-developers] New VTK directory structure and build process (bug fix).

[Bill Hoffman]

This is a limitation of microsoft project files.   The .dsp file has a magic hex
number in it, that tells it if it is a dll, static lib, executable or utiltity.
You can not mix them.   So, we have templates for all three types.   The missing
ReleaseMinSize, just needs to be copied into the dll dsp template.


>>> Then I remembered how stupid I was and set BUILD_SHARED_LIBS to "On" =>
>>> when I started MSVC again, it complained because the default target was
>>> still "ALL_BUILD - Win32 Release MinSize" but there was *no* "Win32 Release
>>> MinSize" setting anymore for the subtargets :(. Thus, I had to switch to
>>> "Release"... and rebuild everything again :(
>>
>>It seems that MSVC keeps some sort of option file that remembers your last
>>target and switching between Static and DLL causes those warnings. You must
>>rebuild everything when switching because the object files are different
>>between Static and DLL (I believe the subdirectories are actually Debug,
>>Release, ReleaseMinSize, DebugDLL, ReleaseDLL
>
>Sure, but do yo know why the "Release MinSize" settings are not available for the subtargets when BUILD_SHARED_LIBS is ON ? I checked the workspace files, and there are just not there (they were previously, when the flag was OFF).
>
>>> Problem : at the end of the build, there was no single directory were the
>>> DLLs could be found : each DLL file was stored in a different directory
>>> (e.g., $BUILD_DIR/Common/Release, $BUILD_DIR/Filtering/Release,
>>> $BUILD_DIR/Graphics/Release). This is a bit problematic as it implies that
>>> each directory should be added to the PATH environment variable in order
>>> the DLL to be found by the system. Nevertheless, I noticed that there is an
>>> empty $BUILD_DIR/Release directory : I guess it would be good if all DLL
>>> files were moved to this directory. This step might just be missing from
>>> the correct Cmake configuration. I moved the DLLs manually, and added
>>> $BUILD_DIR/Release to the PATH.
>>
>>This is an open issue. I haven't thought about how to do this yet. Maybe
>>have a target that copies the DLLs to a common directory.
>
>Yes, that would be cool. I have not found the corresponding Cmake command at the moment. That's one of the drawback of Cmake : it's interpreted, but as it's a new interpreted set of commands, I guess it does not allow us to call system commands like 'copy' or something like that for the moment. Autoconf, Perl or Python would have been OK for that.

This can not be done by cmake, as cmake does not actually do the build.  cmake
only generates build files for the native system(dsp, makefile, etc).   So the
answer is to add an option for a central directory in the build tree that will
store the output of link commands.     The goal of cmake was to use no more
tools than is required to build a C++ program with the native tools supplied by
the vendor.   So, on windows we don't want people to have to install cygwin to
get autoconf, or to have to install perl, python, tcl or anything other than the
compiler and is build tools.




>>Tcl :
>>________
>
>I guess Bill Hoffman might give me an answer regarding the FindTcl.cmake rule later.


We have talked about this and will modify the FIND_LIBRARY command to return a full
path, and to suggest to the GUI that it should be a FILEPATH to get the file dialog.

As for the file dialogs starting in the correct directories, I am fixing that now.

-Bill