[CMake] Wrong number of "../" elements in target path? 2.4.6 vs. 2.4.7 bug?

David Cole david.cole at kitware.com
Wed Oct 24 14:11:34 EDT 2007


The "." probably comes from using CMAKE_CFG_INTDIR somewhere. It
evaluates to "." in make file based builds, but it will be "Debug" or
"Release" for Visual Studio or Xcode based builds.

The CMAKE_CFG_INTDIR expands to something specific to the generator
used. For VS, it becomes "$(OutDir)" -- for Xcode, it becomes
"$(CONFIGURATION)" -- for make based builds, it becomes "." ....

Having said that, if that's where the "." comes from, be careful not
to break VS or Xcode builds for your project if they are important for
the devs working on it. (Don't just remove CMAKE_CFG_INTDIR and assume
everything's ok because it works with make...)


HTH,
David


On 10/24/07, Christian Convey <christian.convey at gmail.com> wrote:
> On 10/24/07, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> > Christian Convey wrote:
> ...
> > >
> >
> > Can you create a test case that shows this problem?
> >
>
> I'm trying to, but it's very slow going because of the complexity of
> the project.  But I have noticed one thing.  Look at the linkage
> statement:
>
> Linking CXX executable ../../../bin/p1BTracker
> cd /home/cjc/x/trunk/ivp/src/./eickstedt/p1BTracker && /usr/bin/cmake
> -P CMakeFiles/p1BTracker.dir/cmake_clean_target.cmake
>
> Do you have any idea why that "/./" is in the middle of the directory
> path in the "cd" command?
>
> I've got a suspicion that the bug is related to that.  If I can do
> something to prevent that "/./" from being there, maybe I can fix this
> (or at least come up with a test case more efficiently.)
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>


More information about the CMake mailing list