Hi again,
first of all, thanks for the quick answer.
Actually all of the requests were merely taste related. I admit that
this is not really important but from time to time I am looking at the
libraries and includes I am using and then I like it, if they are
nicely formatted or as short as possible.
Philip Lowman wrote:
Hi
there,
I've stumbled over three little questions which I could not answer from
the FAQs nor the CMake documentation or the Wiki. Maybe one of the
specialists can help me out...
The first question is whether it is possible to prevent environment
variables from being expanded by CMake when it comes to setting include
or link directories (INCLUDE_DIRECTORIES and LINK_DIRECTORIES).
Not sure what you mean here. You might be able to do this (don't know,
never tried), but I wouldn't recommend it:
INCLUDE_DIRECTORIES($ENV{FOO})
Actually colleagues and me are oftentimes using environment variables.
Until now we used to work solely with Visual Studio Project files being
distributed along different machines and it turned out to be very
convenient to have a base directory of your third party libraries and
your core library defined in environment variables. Nobody needed to
change any configuration files and thus we could put them to the SVN.
With CMake it is working fine as well though I usually use
FILE(TO_CMAKE_PATH $ENV{FOO} CMAKE_FOO).
The
second question is whether I can prevent the MSVC generator to append
$(OutDir) to LINK_DIRECTORIES. For each call to LINK_DIRECTORIES I get
two directories (e.g. LINK_DIRECTORIES(c:/foo/bar) creates
c:/foo/bar/$(OutDir) and c:/foo/bar).
I didn't even realize that it did that. I think that's probably meant
as a convenience for MSVC developers who sometimes like to share the
same filename across different release configurations (in different
directories obviously). Not sure if it's disableable or not, is it
causing you problems?
Does not cause any problems, but since we usually differentiate via
postfix and not via directory we just don't need it. Again... it's just
taste.
And
the last question is, if it is possible to tell the FindQt.cmake script
to give me the plain libraries without the full path of them being
prepended (I am talking about the content of the QT_LIBRARIES
variable). I would rather like to use LINK_DIRECTORIES and
TARGET_LINK_LIBRARIES separately, i.e. I would prefer QtGuid4.lib over
C:\Qt\lib\QtGuid4.lib.
It should be possible to do this with STRING(REGEX REPLACE... ) if
there is no better way. I'm curious why you would need to do this
though. The use of TARGET_LINK_LIBRARIES() with full paths is highly
desired over LINK_LIBRARIES() and TARGET_LINK_LIBRARIES() with a
relative library filename.
Ok, I see what you mean though I am wondering why in general not all
CMake Find modules follow this paradigm. For instance all of my ITK
libraries seem to be set via TARGET_LINK_LIBRARIES() without the path
and the path (here luckily including the $(OutDir), which I just
realized) seems to be set via LINK_DIRECTORIES(). Maybe it is done that
way to support the multi-target MSVC generator because
LINK_DIRECTORIES() does not (yet?) support the CONFIGURATIONS option.
Cheers,
Hauke
--
Tim Hauke Heibel
Computer Aided Medical Procedures (CAMP)
fon: +49 89 289 19427
fax: +49 89 289 17059
|
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
