Right, sorry, technically it is <library>.dir. Visual Studio just
confuses things by calling a library a project.

 

But my point still stands - the intermediate files in VisualStudio are
already qualified by the library name, so adding another level is
pointless in that case. The only case where I see it makes sense is if
the intermediate files aren't under the library, but are placed
somewhere else where you need the library name to help qualify the
directory name and make it unique. 

 

Read the code that adds the ".dir" here: 

 

            std::string dir;

  dir += target.GetName();

  dir += ".dir";

  return dir;

 

It's not paying any attention to configuration, flags, or anything. It's
just tacking "<library>.dir" onto the result.

 

 

________________________________

From: David Cole [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 09, 2007 10:53 AM
To: Rob Mathews
Cc: Brad King; [email protected]; Bill Hoffman
Subject: Re: [CMake] RE: CMake 2.4.1/VC71 Why the wierd <project>.dir
subdirs?

 

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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 10:29 AM
To: Rob Mathews
Cc: Bill Hoffman; [email protected] 
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
[email protected]
http://www.cmake.org/mailman/listinfo/cmake 

 

_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to