I dunno. It seems pretty clear to me that this is the wa std::string cmLocalVisualStudio7Generator::GetTargetDirectory(cmTarget& target)
is called from here: (line 472 or so of VisualStudio7Generator, the method cmLocalVisualStudio7Generator::WriteConfiguration) // The intermediate directory name consists of a directory for the // target and a subdirectory for the configuration name. std::string intermediateDir = this->GetTargetDirectory(target); intermediateDir += "/"; intermediateDir += configName; fout << "\t\t\tIntermediateDirectory=\"" << this->ConvertToXMLOutputPath(intermediateDir.c_str()) << "\"\n" << "\t\t\tConfigurationType=\"" << configType << "\"\n" << "\t\t\tUseOfMFC=\"" << mfcFlag << "\"\n" << "\t\t\tATLMinimizesCRunTimeLibraryUsage=\"FALSE\"\n"; Seems pretty clear that it returns "<project>.dir" and sets IntermediateDirectory to it. Thus you would get IntermediateDirectory=<project>.dir and since Visual Studio interpretes that relative path as relative to the project dir, you get <project>/<project>.dir/Debug <project>/<project>.dir/Release etc on your disk. Which I continue to maintain is pointless. -----Original Message----- From: Brad King [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 11:32 AM To: Rob Mathews Cc: David Cole; cmake@cmake.org; Bill Hoffman Subject: Re: [CMake] RE: CMake 2.4.1/VC71 Why the wierd <project>.dir subdirs? Rob Mathews wrote: > 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. By building each target's object files into a different directory any flag differences are automatically handled. It is also needed for parallel builds in VS8 of the same source file in different targets. What do you mean by "this replaces the old structure of <project>/Debug with <project>/<project>.dir/Debug"? Where did the <project> part come from before? There is no per-target qualification in VS. -Brad _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake