Re: [cmake-developers] Documented property IMPORTED_LOCATION does not exist
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@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@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
[cmake-developers] [CMake 0012912]: FindLAPACK does not work when trying static linking
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12912 == Reported By:tgallagher Assigned To: == Project:CMake Issue ID: 12912 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-01-24 21:23 EST Last Modified: 2012-01-24 21:23 EST == Summary:FindLAPACK does not work when trying static linking Description: The FindLAPACK module does not work when trying to use static linking. When trying to compile the test file to check if the library works, it gives: /usr/bin/gfortran CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.o -o cmTryCompileExec -rdynamic -Wl,--start-group /usr/lib/liblapack.a /usr/lib/libblas.a -Wl,--end-group /usr/lib/libblas.a(xerbla.o): In function `xerbla_': (.text+0x0): multiple definition of `xerbla_' /usr/lib/liblapack.a(xerbla.o):(.text+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [cmTryCompileExec] Error 1 make[2]: Leaving directory `/data/lagrangianBuild/CMakeFiles/CMakeTmp' make[1]: *** [CMakeFiles/cmTryCompileExec.dir/all] Error 2 make[1]: Leaving directory `/data/lagrangianBuild/CMakeFiles/CMakeTmp' make: *** [all] Error 2 The double-definition is because the static liblapack already has all the code it needs from libblas in it, but the FindLAPACK module calls FindBLAS and links against both liblapack and libblas. The solution is to check if BLA_STATIC is set, do not call find_package(BLAS) because the lapack library will already have all the functions it needs in it. Steps to Reproduce: Compile something using the find_package(LAPACK REQUIRED) signature with BLA_STATIC defined. Additional Information: I have many other fixes related to FindBLAS and FindLAPACK as well as a new module request. If approved for the new module and given access, I can fix this bug as well. == Issue History Date ModifiedUsername FieldChange == 2012-01-24 21:23 tgallagher New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] New module introduction
Hi, I've been on the users mailing list a few different times to submit patches for the FindBLAS and FindLAPACK modules and we found some more bugs with them. It was known awhile ago that they don't work for the new Intel MKL naming conventions (http://www.mail-archive.com/cmake@cmake.org/msg38606.html). We finally hit the point where we had to fix it. So, in order to do this correctly, there is an additional module that interfaces with a tool provided by Intel to generate the information needed to link. We've written this module and are polishing it now. We've also modified FindBLAS and FindLAPACK to use the new module and also fixed a few smaller bugs during this process. I would like to sign up as a module maintainer for this new module (and get push access to put it in the repository). I've done all the steps on the wiki for doing this except introducing the module (which is what I'm doing now!) and applying for git access (which I will do when I find out this email was what 'introduce the module' meant). If I need to send out the new module first for review or something, let me know and we'll do it as soon as it's finished. Thanks, Tim -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Documented property IMPORTED_LOCATION does not exist
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@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@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 PLplo
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
2012/1/24 Brad King : > On 1/22/2012 7:58 AM, Eric Noulard wrote: >> >> 2012/1/3 Eric Noulard: >>> >>> back to cleaner way of work. >> >> >> I did update and clean-up my previous attempt to ease documentation for >> CPack. >> http://public.kitware.com/Bug/view.php?id=10067 > > Thanks for working on this. I don't like writing doc but sometimes I'd like reading some so may be the second needs the first... :-] >> the new up-to-date branch is "stage/ImproveCPackDoc-reloaded" >> [...] > I glanced through the changes and built the branch. It looks okay > to me. > > One nitpick I have is that the generated documentation adds extra > blank lines between paragraphs: Agreed...but... > The markup parser needs to avoid adding the extra newline which tells > the output formatter to start a new paragraph. after 1 hour + reading & testing I'm now pretty sure that the parser is not the cuprit... (In fact I did avoid 1 extra line after the brief) The cmDocumentationFormatterText should be in fact if you look at the output of: cmake --help-module CPackComponent or any other (untouched module) cmake --help-module FindQt4 you'll see that the extra space are there as well. So yes there is too much space, but this is not due to my current proposal, it was there before. We can handle that separately. I won't be doing this now I'd rather agree on the new markup feature first. > Also I got an unused variable warning (-Wunused-variable) in > cmDocumentation::addCTestStandardDocSections > > during the build. This one is fixed. I pushed the branch forward. I fixed some prog. style and avoid an extra newline just after the brief. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
On 1/22/2012 7:58 AM, Eric Noulard wrote: 2012/1/3 Eric Noulard: back to cleaner way of work. I did update and clean-up my previous attempt to ease documentation for CPack. http://public.kitware.com/Bug/view.php?id=10067 Thanks for working on this. the new up-to-date branch is "stage/ImproveCPackDoc-reloaded" I'd rather wait for feedback before merging this to next. Fast try is: cpack --help-variable-list cpack --help-command-list then chose whatever var / command you like. The documentation is extracted from files (CPack.cmake, CPackComponent.cmake, CPackRPM.cmake, CPackDeb.cmake) using new markup. I glanced through the changes and built the branch. It looks okay to me. One nitpick I have is that the generated documentation adds extra blank lines between paragraphs: - The cmake_add_component command describes an installation component, which the user can opt to install or remove as part of the graphical installation process. compname is the name of the component, as provided to the COMPONENT argument of one or more CMake INSTALL commands. DISPLAY_NAME is the displayed name of the component, used in graphical installers to display the component name. This value can be any string. DESCRIPTION is an extended description of the component, used in graphical installers to give the user additional information about the component. Descriptions can span multiple lines using "\n" as the line separator. Typically, these descriptions should be no more than a few lines long. - The markup parser needs to avoid adding the extra newline which tells the output formatter to start a new paragraph. Also I got an unused variable warning (-Wunused-variable) in cmDocumentation::addCTestStandardDocSections during the build. Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012911]: SDL_INCLUDE_DIRS, SDL_LIBRARIES
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12911 == Reported By:signupname Assigned To: == Project:CMake Issue ID: 12911 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-01-24 07:48 EST Last Modified: 2012-01-24 07:48 EST == Summary:SDL_INCLUDE_DIRS, SDL_LIBRARIES Description: SDL_INCLUDE_DIRS and SDL_LIBRARIES are not set, but instead only the singular formas are available. == Issue History Date ModifiedUsername FieldChange == 2012-01-24 07:48 signupname New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
