[CMake] Visual Studio problem with many/long additional library paths

[Karr, David A (Titan) at TITAN]

> > It would be helpful (at least in my case) to be able to turn off the
> > production of the "OutDir" directories in this list, I just haven't
> > gotten around to figuring out how.  Is there a simple way to control
> > this?
> 
> Both directories are always added.  This is hard-coded in the VS7
> generator.  The reason is that it is not known when the user specifies
a
> link directory in CMake code whether that directory points directly at
a
> library or points to another CMake build tree in which there are
> per-configuration subdirectories.  With the information about link
> libraries and directories currently available from CMakeLists.txt
files
> it is not possible to compute which path is needed.

Actually, in my special case it IS possible to know which path is
needed,
because the person who originally set up our Visual Studio workspace 
decided that all the .lib files should be deposited in one directory 
named "lib", and all the .dll files should be deposited in one directory
named "bin".  I suppose he was influenced by Unix conventions.  
This arrangement means that we lose the ability to keep debug and 
release configurations side by side under one root directory, but
one of the wonderful things about CMake is you can do out-of-source
builds so that your debug and release configurations are built under
different root directories, which seems to work just as well (or 
better than) the OutDir convention.

So the answer is that we simply never use the "OutDir" path for any
Library used by this particular workspace, no matter what.

It seems to me that in most cases, before the user creates the 
various CMakeLists.txt files he or she can determine for any given 
library whether that library will be obtained from a per-configuration
"OutDir" directory, or whether that library always comes from the same
directory no matter which configuration CMake is told to create.
And then the user could flag a library named in TARGET_LINK_LIBRARIES
to indicate whether it uses OutDir or not; or perhaps the user could 
pass these libraries to some other commands that are variants of 
TARGET_LINK_LIBRARIES.  So there's really no burden on CMake to figure 
out anything about the directory structure; it's merely a matter of 
providing control to the user through the interface.

On the other hand, the main effect of the lack of user control is
that a string that you don't often look at anyway is longer than needed.
This is something that I hardly ever even notice, not a major drawback.

-- David Karr