[cmake-developers] Documented property IMPORTED_LOCATION does not exist

[Michael Wild]

On 01/25/2012 12:25 AM, Alan W. Irwin wrote:
> On 2012-01-24 06:28+0100 Michael Wild wrote:
> 
>> On 01/24/2012 05:50 AM, Alan W. Irwin wrote:
>>> The documentation you get from
>>>
>>> cmake --help-full
>>>
>>> refers to the IMPORTED_LOCATION property as one of the more important
>>> ones set for imported targets.  I have to agree that location is the
>>> most important property for imported targets, but the name appears to
>>> be wrong for the documentation of this property!
>>>
>>> After screwing around for a while trying to use the above
>>> property for my imported targets, I discovered (by guessing) that the
>>> name of a property that actually does give the location information is
>>> IMPORT_LOCATION, not IMPORTED_LOCATION.  For what it is worth,
>>> IMPORT_LOCATION works for an imported library, and I haven't tried
>>> this on imported executables. (By the way, LOCATION works as well, but
>>> that appears from the documentation to be a left-over from CMake 2.4
>>> which is why I tried to get IMPORTED_LOCATION to work and when that
>>> failed, switched to the currently undocumentated IMPORT_LOCATION.)
>>>
>>> I find IMPORTED_LOCATION is mentioned in the following
>>> places in the cmake-2.8.6 source tree:
>>>
>>> software at raven> find cmake-2.8.6 -print0 -type f \
>>> |xargs -0 grep -l IMPORTED_LOCATION
>>> cmake-2.8.6/ChangeLog.txt
>>> cmake-2.8.6/Modules/FindQt4.cmake
>>> cmake-2.8.6/Tests/ExportImport/Import/A/CMakeLists.txt
>>> cmake-2.8.6/Tests/SimpleInstall/CMakeLists.txt
>>> cmake-2.8.6/Tests/SimpleInstallS2/CMakeLists.txt
>>> cmake-2.8.6/Source/cmTarget.cxx
>>> cmake-2.8.6/Source/cmAddExecutableCommand.h
>>> cmake-2.8.6/Source/cmAddLibraryCommand.h
>>> cmake-2.8.6/Source/cmExportBuildFileGenerator.cxx
>>> cmake-2.8.6/Source/cmExportInstallFileGenerator.cxx
>>>
>>> A similar search for IMPORT_LOCATION found nothing at all!
>>>
>>> However, I spot-checked cmake-2.8.6/Source/cmTarget.cxx, and all those
>>> mentions of IMPORTED_LOCATION appear to be documentation strings
>>> rather than executable code, and I was unable to find why
>>> IMPORTED_LOCATION does not work for me while IMPORT_LOCATION does. So
>>> this needs someone who is familiar with the CMake code to figure out
>>> what the actual problem is here, and to decide whether a fix to the
>>> documentation strings is all that is required or whether some deeper
>>> change needs to be made.
>>>
>>> Alan
>>
>> IMPORTED_LOCATION works just fine for me. Also IMPORT_LOCATION, as you
>> call it, is not referenced once in the whole CMake source, while
>> IMPORTED_LOCATION is, and not only as a documentation string as you
>> claim.
> 
> Hi Michael:
> 
> Thanks for your response.
> 
> Since you cannot verify the issue, then the most likely reason is
> there is some difference between your and my CMake version, minimum
> CMake version (which affects policy decisions), and hardware/software
> platform. Could you be more specific about those constraints in your
> case?
> 
> Just to be sure I was reporting a clean result, I started with a
> fresh bootstrap build and install of CMake-2.8.7 that I did on my Debian
> Squeeze platform. I then built and installed PLplot (which
> specifies cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR) from
> scratch using that version of cmake.
> 
> I have attached the resulting export module files that are installed
> as a result of that PLplot install.
> 
> I then checked imported target properties with the following CMake test
> script
> (which is also attached for convenience).
> 
> project(test_export NONE)
> cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR)
> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR} )
> include(export_plplot OPTIONAL RESULT_VARIABLE IF_PLOT)
> if(IF_PLOT)
>   get_target_property(test_loc1 _plplotcmodule IMPORT_LOCATION)
>   message(STATUS "IMPORT_LOCATION = ${test_loc1}")
>   get_target_property(test_loc2 _plplotcmodule IMPORTED_LOCATION)
>   message(STATUS "IMPORTED_LOCATION = ${test_loc2}")
> else(IF_PLOT)
>   message(WARNING "IF_PLOT = ${IF_PLOT}")
> endif(IF_PLOT)
> 
> And here was the result when cmake was invoked from a sub-directory
> of the one containing the above CMakeLists.txt and the export files.
> 
> software at raven> cmake ..
> -- IMPORT_LOCATION =
> /home/software/plplot_svn/installcmake/lib/python2.6/site-packages/_plplotcmodule.so
> 
> -- IMPORTED_LOCATION = test_loc2-NOTFOUND
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /tmp/cmake_test/build_dir
> 
> Note, _plplotcmodule is one of the shared objects generated by PLplot
> for our python bindings, but if you look at the export files, there
> doesn't seem to be anything done differently for _plplotcmodule compared
> to other PLplot library targets, and also I assure you
> the result for IMPORT_LOCATION is correct.
> 
> So the above simple script cleanly shows the issue for 2.8.7.
> IMPORT_LOCATION is an imported target property with the correct value
> while IMPORTED_LOCATION is not found.
> 
> If you try the same test script with the same exported files, do you
> get a different result? If you still have trouble verifying the above
> result, then please also try CMake-2.8.7 to see whether that version
> is the source of the issue.
> 
> One obvious possibility is there is something wrong with the attached
> PLplot export files.
> 
> They are generated by the PLplot build system with, e.g.,
> 
> install(
>   TARGETS plplot_widgetmodule _plplotcmodule
>   EXPORT export_plplot
>   LIBRARY
>   DESTINATION ${PYTHON_INSTDIR}
>   )
> 
> which I think is pretty standard so if there is something wrong, it is
> probably due to CMake-2.8.7 as well.  However, those export files have
> worked fine for years in another context (the build and test of the
> PLplot installed examples).  That build and test system does not
> explicitly try to obtain IMPORTED_LOCATION (or IMPORT_LOCATION)
> properties.  So I only discovered this issue yesterday, when I
> actually needed the PLplot python shared object for a completely
> different project.  That project as well as the above script clearly
> demonstrates the issue.
> 
> Alan

Hi Alan

If you look at the export file you will see that indeed it doesn't set
IMPORTED_LOCATION. Instead, it always uses the configuration specific
properties, i.e. IMPORTED_LOCATION_<CONFIG> where the last part is
either NOCONFIG, DEBUG, RELEASE, RELWITHDEBINFO, MINSIZEREL or any of
the custom configurations defined by your project. So, little wonder you
don't get any result for the IMPORTED_LOCATION property ;-)

As to why you do get a result for IMPORT_LOCATION, I think you've
accidentally hit some backward compatibility code, see
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=refs/tags/v2.8.7#l2685.
That nugget tries to handle <CONFIG>_LOCATION, and in your case <CONFIG>
is "IMPORT". AFAICS there must be something wrong in the
cmTarget::ComputeImportInfo(...) function, since for every non-existing
configuration it returns the data from the first existing configuration
it finds...

I also tried FOO_LOCATION and BAR_LOCATION, always with the same result
as IMPORT_LOCATION returned ;-)

So, to fix your code, use IMPORTED_LOCATION_NOCONFIG.

HTH

Michael