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

[Sebastien BARRE]

Hi Bill,

At 08/05/2001 11:43, Bill Hoffman wrote:

>This is a limitation of microsoft project files.   The .dsp file has a 
>magic hex
>number in it,

I guess the line like :

# TARGTYPE "Win32 (x86) Generic Project" 0x010a

>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.

Good.

BTW, one of my problem with CMake at the moment is that it requires it use 
the MSVC++ GUI to open the workspace and launch the build. I guess in the 
future we might adapt the Unix Makefile generator to a Microsoft Makefile 
generator ?

> >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).

Yes, I know. I was not very clear, sorry. You are right, one could add a 
MOVE command that will add a 'mv' in the Unix Makefile or a "move" 
post-build step in the dsp (although I guess it might be problematic for 
the dependency checkings).

>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.

Yes, we've talked about that already in the lists. I guess you had good 
reasons. To my opinion, providing/downloading/installing Perl or Python is 
really a *small* step compared to the power that comes with these languages 
(and their modules or related apps). The old "reinventing the wheel" issue 
:) But the fact is that CMake might probably become a tool with no other 
cross-platform "competitor".

> >>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.

Good.

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

Thanks.