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

Brandon Van Every bvanevery at gmail.com
Wed May 9 17:11:42 EDT 2007


On 5/9/07, Rob Mathews <Rob.Mathews at varolii.com> wrote:
>
> I understand your point, but the Visual Studio itself doesn't really
> support more than one project in one directory. Ok, you can force it via
> tricks like this, but that's not the beaten path for most VC developers.



Whether most people do it or not is unimportant.  What's important, is it is
correctly handled when someone does do it.  I've seen open source projects
that do it.  Especially, it happens when Unix developers port things to MSVC
and just do the 1st project structure that comes to mind, or is driven by
legacy concerns, rather than what the mainstream from scratch MSVC
developers are doing.  Accepting variance in development cultures is part of
the drill of a truly cross-platform tool.


For example, the wizard always makes a new directory.
>
> Rather, they are used to the current directory structure that VC
> generates.
> True, that directory structure has a bug that this fix addresses, but
> from my POV I'd rather have a switch - call it
> "USE_BROKEN_VC7_DIRECTORY_STRUCTURE" if you want - that causes Cmake to
> extrude the traditional directory layout.



Why?  What job are you trying to get done that really requires this?  Any
switch like this introduces a new maintenance burden, yet another test case
that someone has to consider, yet another gratuitous incompatibility, yet
another thing that can break because of someone's lack of RTFM, etc.  Do you
desire a standard API for getting some specific piece of information that
you actually want?  That's what I desire, for "faked" convenience libraries.

If what you're really saying, is you like using scripting languages outside
of CMake on directory structures that are always named the way mainstream
MSVC users expect, I think you're asking too much.  A personal preference
for nomenclature is not a sufficient reason for a feature request.  It
should be a standard that everybody benefits from and actually works for
everybody.  Even the corner cases that you don't personally put much weight
on.


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


More information about the CMake mailing list