Christian Verbeek wrote:
This had been discussed in
http://public.kitware.com/pipermail/cmake/2004-January/004644.html
Now more than two years have passed by and the problem still remains.
That's because changing it represents a fundamental change in the design
of the generator.
> In
visual studio the generated files go into a Release/Debug subdir
depending on the build type choosen in the IDE. If your application
depends on relative pathes to find other stuff (like plugins) this is a
problem. I really would like to skip these subdirs to make the directory
structure of the build output identitcal to what you get with nmake or make.
There are other solutions to your problem.
1.) If you INSTALL the project the per-configuration subdirs are not used.
2.) If you want the project to work from the build tree look at the
definition of CMAKE_INTDIR in the preprocessor:
#ifdef CMAKE_INTDIR
/* Account for the per-config subdirectory in computing paths
The value of CMAKE_INTDIR is a string containing the
per-configuration subdirectory. */
const char* mypath = "some/path" CMAKE_INTDIR;
#else
/* Use normal relative paths. */
const char* mypath = "some/path";
#endif
This preprocessor symbol is defined on a per-configuration basis for the
multi-configuration generators. This file contains an example of
exactly what you want to do:
http://www.vtk.org/cgi-bin/viewcvs.cgi/Wrapping/Tcl/vtkTkAppInit.cxx?view=markup
Just look at the relative path computation contained inside a
CMAKE_INTDIR preprocessor test.
-Brad
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
