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

[Brandon Van Every]

 On 5/9/07, Brad King <brad.king at kitware.com> wrote:

> Rob Mathews wrote:
> > 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.
>
> It is interpreted relative to the directory containing project.vcproj.
> What if there is more than one .vcproj file in the same directory?



Anyone get the feeling that this debate would go away if the burden of proof
was raised to the level of demonstrating safety under a gigantic test suite
covering all weird options?  If such a suite existed, then Rob could tweak
CMake as he likes and then run the tests, rather than speculating on what's
"pointless."  As much as I'd like the cleanest, most standard output
directories possible, this whole conversation invokes a real sinking feeling
of "if it ain't broke, don't fix it."  What I'd personally like is some
standard ways to get at *.obj locations so that I can fake convenience
libraries.  I have working code in the Chicken Scheme build that's doing it,
for a few months now.  But, it's dependent on magic knowledge about where
the *.obj files will end up, not a standard interface.  To take a step
back...

...what was the original problem that motivated this diagnosis of
"pointlessness" anyways?


Cheers,
Brandon Van Every
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20070509/e032a666/attachment.htm