On 01/01/2012 07:47 AM, Gary Kramlich wrote:
On 12/31/2011 05:03 PM, Robert Dailey wrote:
Storing the source directory will require the exact idea you had
mentioned. Use an internal cache variable or, even better, a target
property. This is how I have done it. Each target that I create
specifies a list of its include directories (where other targets that
depend on it can find its header files, and will append this directory
to its list of searchable include directories).
I learned the hard way, that the target property can't be named
SOURCE_LOCATION, since it just spit out the value for the LOCATION
property, which seems like a bug, unless SOURCE_LOCATION was left around
for compatibility, but I couldn't find it documented anywhere.
A target's sources may reside in arbitrary directories; there is no
guarantee that they're located next to the CMakeLists.txt file which
defines the target. Furthermore, source files with relative path are
searched w.r.t. CMAKE_CURRENT_SOURCE_DIR and - if not found - w.r.t.
CMAKE_CURRENT_BINARY_DIR, so the notion of a source directory
associated with a target is not reliable, IMO.
Apart from this, I can confirm that a target property ending in
_LOCATION does always yield the same result as the LOCATION
target property:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LOCATION C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES XYZ_LOCATION xyz)
GET_TARGET_PROPERTY(p main XYZ_LOCATION)
MESSAGE(XYZ_LOCATION: ${p})
yields
XYZ_LOCATION: .../main
instead of xyz, and without the SET_TARGET_PROPERTIES() command, it
still yields the same instead of p-NOTFOUND. Indeed, this seems to
be strange behavior which is possibly worth a bug report, but maybe,
a CMake developer can provide some enlightenment.
For defines, and I think cflags, you can use get_target_property().
Coming up empty for the target and the directory. Tried DEFINITIONS,
COMPILE_DEFINITIONS, and COMPILE_FLAGS. When used on the target, i get
a -NOTFOUND, and I get an empty string when used on the source directory.
Each of these properties usually contains only a part of the flags/
definitions used to compile a target's source files, and even their
entirety does not necessarily contain all flags/definitions. AFAIK,
there's no single instance - variable, property or the like - that
one might query in order to retrieve the complete set of flags/
definitions that will be in effect for the compilations.
Moreover, note that these flags/definitions are configuration-specific,
and with multi-config generators, the configuration is chosen at build
time. Thus, gathering such information for a target at configuration
time is generally also not reliable, unless one takes the different
configurations into account.
For libraries, I've also maintained a list in a target property. This is
how you build recursive dependencies. CMake will automatically set up
build order based on your dependencies, however you cannot query these
libraries without maintaining them yourself. Also, another benefit to
maintaining dependencies in target properties is that you can throw an
error message if a target depends on another target that does not yet
exist (used to ensure that targets are defined in the proper order in
the cmake scripts).
It looks like I'll have to be setting these up manually too, since even
though cmake has knowledge about it, it won't give the information out
to scripts.
The libraries a target's binary will be linked against may also depend
on the configuration - possibly chosen at build time - so predicting
them at configuration time is generally unreliable, too.
Regards,
Michael
Maybe I'll be better off requiring that this module be included in the
CMakeLists.txt for the target it's going to work on... But that's
really annoying that cmake is dictating how a module can work, even
though all I'm trying to do is query a target...
Hope that helps.
It helps in the sense that I'm not chasing something that can't be done
anymore ;)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
