[CMake] Crash in ComputeLinkInformation: cmTarget::GetDirectory returns NULL for UTILITY type

[Eran Guendelman]

Hi, we are trying to track down why cmake 2.4 is crashing when 
generating the VisualStudio 7 build files whereas cmake 2.2 worked fine. 
  I built a debug version of cmake and narrowed it down to the following 
issue:

In cmLocalGenerator::ComputeLinkInformation it goes through the 
libraries and tries to add their information to the linkLibraries 
vector.  It gets to a library called xerces-c_2D.  It checks whether 
this is a cmake target (using FindTarget), and indeed finds that it is. 
  So it then has the line
std::string linkItem = tgt->GetDirectory(0)

This is where the crash occurs, and the cause is as follows.  In our 
build environment, xerces-c_2D is built as a custom target (see below 
for why), so its cmTarget::TargetType is UTILITY, and 
cmTarget::GetDirectory returns 0 in this case.  Hence trying to assign 0 
to an std::string causes the crash.

Looking at cmTarget::GetDirectory, my instinct for "fixing" this is to 
change

default:
return 0;

to

default:
this->Directory = "";

so that the subsequent check of if(this->Directory.empty()) will take 
care of this case.  But then again, I don't really know anything about 
how this code is supposed to work so this was just a guess (that at 
least did fix the crash and succeeded in generating project files -- 
though I haven't tried to build them).

Anyway, as for why we use ADD_CUSTOM_TARGET to build xerces-c_2D, it's 
because this is a third party library we are trying to build as part of 
our build system, and since the library came with a VC7 .sln file but no 
CMakeLists.txt files we basically made its CMakeLists.txt look something 
like:

ADD_CUSTOM_TARGET(xerces-c_2 ALL devenv 
${OpenSim_SOURCE_DIR}/Vendors/xerces-c-src2_4_0/Projects/Win32/VC7/xerces-all/xerces-all.sln 
/build Release)

i.e. we build the library by essentially making a system call to visual 
studio and passing it their supplied .sln.

So basically:
- If you think GetDirectory could be fixed in a way that correctly 
handles the UTILITY target type then hopefully that should resolve 
things and we'll be able to upgrade to cmake 2.4.
- But if you think one should never try to link to a UTILITY target then 
we'll need to come up with a different way to incorporate building this 
third party library as part of our regular build and any pointers to 
doing this nicer would be appreciated.

Thank you very much.

BTW Please CC my email address on replies.  Thanks.