[CMake] RE: CMake 2.4.1/VC71 Why the wierd <project>.dir subdirs?

David Cole david.cole at kitware.com
Wed May 9 10:53:22 EDT 2007


It's not <project>.dir, it's <library>.dir.

Brad's talking about the same source file included in two different
libraries (libA and libB), not two different configurations (Debug and
Release).

Another duplicate name case is when you have files named the same (in
different directories) but then included in the same library. But that's
different... :-)

On 5/9/07, Rob Mathews <Rob.Mathews at varolii.com> wrote:
>
> Nope. That's what the configurations are for, - ie, Debug, Release,
> RelWithDebInfo, for example.
>
> Just adding the string "<project>.dir" to the path doesn't get you
> anything.
>
> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com]
> Sent: Wednesday, May 09, 2007 10:29 AM
> To: Rob Mathews
> Cc: Bill Hoffman; cmake at cmake.org
> Subject: Re: [CMake] RE: CMake 2.4.1/VC71 Why the wierd <project>.dir
> subdirs?
>
> Rob Mathews wrote:
> > If I had fred.cpp in both the foo and bar directories,
> > then
> > foo/Debug/fred.obj
> > and
> > bar/Debug/fred.obj
> > are different files, and so that works fine.
> >
> > Hmm ... you must be talking about support for the case where the
> > intermediate directories are all off somewhere else? That's doesn't
> seem
> > to be the default for CMake.
>
> The <project>.dir directories are so that the same source file compiled
> in different targets in the same directory with different flags work.
>
> -Brad
>
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20070509/24dee2f9/attachment.html


More information about the CMake mailing list