I'm noticing that if CMake macros detect a library in your
environment, they store
it in a variable, for example:
Xerces_c_LIBRARY:FILEPATH=/usr/lib/libxerces-c.so
The 'manual' checks we did until now would have resulted in something like:
Xerces_c_LIBRARY:STRING=-L/usr/lib -lxerces-c
-> This is gcc specific BTW
Could anyone on any platform think why the first option is always better
and more portable than the second (or not) ?
This would also be the form in which it ends up in the .pc file.
Peter
CMake musings about library paths
On Wed, Jun 3, 2009 at 4:37 PM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
> I'm noticing that if CMake macros detect a library in your
> environment, they store
> it in a variable, for example:
>
> Xerces_c_LIBRARY:FILEPATH=/usr/lib/libxerces-c.so
If I understand correctly, by "your environment" you are referring to the
current cmake variable space, and not your shell's environment, right?
>
>
> The 'manual' checks we did until now would have resulted in something like:
>
> Xerces_c_LIBRARY:STRING=-L/usr/lib -lxerces-c
> -> This is gcc specific BTW
>
> Could anyone on any platform think why the first option is always better
> and more portable than the second (or not) ?
I guess it depends on what you intend to do with the Xerces_c_LIBRARY
variable. I have the feeling that cmake- and pc- specific concerns are being
mixed here.
>From a cmake perspective, the recommended practice is that <package>_LIBRARY
variables contain a full path to a library. The typical use of such
variables is inside find_<package> modules, and the target_link_libraries
command. Linker paths are usually stored in <package>_LIBRARY_DIRS variables
and used in the include_directories command.
So, I would leave Xerces_c_LIBRARY with the usual cmake meaning.
The documentation of the cmake CMP0003 policy [1] may be a good reference to
why full paths are better (you cannot pick the wrong lib inadvertedly).
I would create a different (pc-specific) variable with a name that does not
clash with the cmake convention. And as Stephen points out in a post that he
submitted while I'm writing, "the second is easier to construct from the
first, than the other way around."
As a sidenote, although there is no stiff standard, it has been recently
recommended in the cmake ML that package names should be in all caps, so
maybe we should adapt to it and use XERCES_C, or something similar (IIRC
this was Peter's preferred style ;) ). Furthermore, this would allow us to
use the (very useful) FindPackageHandleStandardArgs module [2] that adopts
this convention.
If you're interested, I could upgrade the FindXerces script I submitted some
months ago to use this module.
[1] http://www.cmake.org/cmake/help/cmake2.6docs.html#policy:CMP0003
[2]
http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPackageHand...
Cheers,
Adolfo.
>
>
> This would also be the form in which it ends up in the .pc file.
>
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
CMake musings about library paths
2009/6/3 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
> As a sidenote, although there is no stiff standard, it has been recently
> recommended in the cmake ML that package names should be in all caps, so
> maybe we should adapt to it and use XERCES_C, or something similar (IIRC
> this was Peter's preferred style ;) ). Furthermore, this would allow us to
> use the (very useful) FindPackageHandleStandardArgs module [2] that adopts
> this convention.
This is actually quite disastrous, if you look at the installed CMake
Find* Modules, most are written like 'Package_FOUND' instead of
'PACKAGE_FOUND'. Since variable names are case sensitive, switching
100 macros to a new naming convention is not a nice prospect. Did they
propose how to solve this ? Do you have the link to that ML discussion
?
Peter
CMake musings about library paths
2009/6/4 Peter Soetens <peter [dot] soetens [..] ...>
> 2009/6/3 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>:
> > As a sidenote, although there is no stiff standard, it has been recently
> > recommended in the cmake ML that package names should be in all caps, so
> > maybe we should adapt to it and use XERCES_C, or something similar (IIRC
> > this was Peter's preferred style ;) ). Furthermore, this would allow us
> to
> > use the (very useful) FindPackageHandleStandardArgs module [2] that
> adopts
> > this convention.
>
> This is actually quite disastrous, if you look at the installed CMake
> Find* Modules, most are written like 'Package_FOUND' instead of
> 'PACKAGE_FOUND'. Since variable names are case sensitive, switching
> 100 macros to a new naming convention is not a nice prospect. Did they
> propose how to solve this ? Do you have the link to that ML discussion
> ?
It's true, find module writers have not adhered to a uniform naming
convention (maybe because one didn't exist at the time?) and what we now
have is highly irregular (e.g., OPENGL vs. Boost).
This is the link that I remembered [1]. Furthermore,
FindPackageHandleStandardArgs enforces the all caps behavior, so if you end
up using it, you'll have to stick to it.
[1] http://www.cmake.org/pipermail/cmake/2009-April/028659.html
Adolfo
>
>
> Peter
>
CMake musings about library paths
2009/6/4 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
>
>
>
> 2009/6/4 Peter Soetens <peter [dot] soetens [..] ...>
>
> 2009/6/3 Adolfo Rodríguez Tsouroukdissian <
>> adolfo [dot] rodriguez [..] ...>:
>> > As a sidenote, although there is no stiff standard, it has been recently
>> > recommended in the cmake ML that package names should be in all caps, so
>> > maybe we should adapt to it and use XERCES_C, or something similar (IIRC
>> > this was Peter's preferred style ;) ). Furthermore, this would allow us
>> to
>> > use the (very useful) FindPackageHandleStandardArgs module [2] that
>> adopts
>> > this convention.
>>
>> This is actually quite disastrous, if you look at the installed CMake
>> Find* Modules, most are written like 'Package_FOUND' instead of
>> 'PACKAGE_FOUND'. Since variable names are case sensitive, switching
>> 100 macros to a new naming convention is not a nice prospect. Did they
>> propose how to solve this ? Do you have the link to that ML discussion
>> ?
>
>
> It's true, find module writers have not adhered to a uniform naming
> convention (maybe because one didn't exist at the time?) and what we now
> have is highly irregular (e.g., OPENGL vs. Boost).
> This is the link that I remembered [1]. Furthermore,
> FindPackageHandleStandardArgs enforces the all caps behavior, so if you end
> up using it, you'll have to stick to it.
>
More on cmake find scripts:
If you want to test a find module that uses FindPackageHandleStandardArgs,
you can give a quick look at the attached FindACE.cmake file. It adheres to
the all-caps naming and its implementation is somewhat cleaner than the
FindXerces script I submitted some weeks ago (it avoids a couple of lines of
duplicated code).
I'm also attaching a FindAce.cmake script that uses camel case notation but
does not rely on FindPackageHandleStandardArgs, but rather on the
nonstandard LibFindMacros script.
Finally, and to overwhelm you with attachments ;) I'm including a
FindTAO.cmake script that I thought might be useful for you to browse
(written and kindly shared by Greg Poole). I haven't had a chance to study
it, though.
Best,
Adolfo.
>
>
> [1] http://www.cmake.org/pipermail/cmake/2009-April/028659.html
>
> Adolfo
>
>>
>>
>> Peter
>>
>
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
CMake musings about library paths
2009/6/3 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> On Wed, Jun 3, 2009 at 4:37 PM, Peter Soetens <peter [dot] soetens [..] ...>
> wrote:
>>
>> I'm noticing that if CMake macros detect a library in your
>> environment, they store
>> it in a variable, for example:
>>
>> Xerces_c_LIBRARY:FILEPATH=/usr/lib/libxerces-c.so
>
> If I understand correctly, by "your environment" you are referring to the
> current cmake variable space, and not your shell's environment, right?
I just meant 'finding a library in your build environment, ie
directory structure'.
>
>>
>> The 'manual' checks we did until now would have resulted in something
>> like:
>>
>> Xerces_c_LIBRARY:STRING=-L/usr/lib -lxerces-c
>> -> This is gcc specific BTW
>>
>> Could anyone on any platform think why the first option is always better
>> and more portable than the second (or not) ?
>
>
> I guess it depends on what you intend to do with the Xerces_c_LIBRARY
> variable. I have the feeling that cmake- and pc- specific concerns are being
> mixed here.
>
> From a cmake perspective, the recommended practice is that <package>_LIBRARY
> variables contain a full path to a library. The typical use of such
> variables is inside find_<package> modules, and the target_link_libraries
> command. Linker paths are usually stored in <package>_LIBRARY_DIRS variables
> and used in the include_directories command.
> So, I would leave Xerces_c_LIBRARY with the usual cmake meaning.
> The documentation of the cmake CMP0003 policy [1] may be a good reference to
> why full paths are better (you cannot pick the wrong lib inadvertedly).
I start getting the logic. It's sound.
>
> I would create a different (pc-specific) variable with a name that does not
> clash with the cmake convention. And as Stephen points out in a post that he
> submitted while I'm writing, "the second is easier to construct from the
> first, than the other way around."
Good, so we can generate the .pc file 'as good as possible'.
>
> As a sidenote, although there is no stiff standard, it has been recently
> recommended in the cmake ML that package names should be in all caps, so
> maybe we should adapt to it and use XERCES_C, or something similar (IIRC
> this was Peter's preferred style ;) ). Furthermore, this would allow us to
> use the (very useful) FindPackageHandleStandardArgs module [2] that adopts
> this convention.
> If you're interested, I could upgrade the FindXerces script I submitted some
> months ago to use this module.
I'm already working on your patch, which proved to be a very good
starting point!
I'll rename them to all CAPS and check out [2]. I added find_package macros
for RTAI, Xenomai and Ecos and am cleaning up big time. It broke the CORBA
build along the way and the .pc files now need to be fixed again, but
I'm getting
there. I'll push something to github tomorrow.
I'm really starting to like CMake, it used to be different :]
Peter
>
> [1] http://www.cmake.org/cmake/help/cmake2.6docs.html#policy:CMP0003
> [2]
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPackageHand...
>
> Cheers,
>
> Adolfo.
>
>>
>> This would also be the form in which it ends up in the .pc file.
>>
>> Peter
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
CMake musings about library paths
On Wednesday 03 June 2009 16:37:01 Peter Soetens wrote:
> I'm noticing that if CMake macros detect a library in your
> environment, they store it in a variable, for example:
>
> Xerces_c_LIBRARY:FILEPATH=/usr/lib/libxerces-c.so
>
> The 'manual' checks we did until now would have resulted in something like:
>
> Xerces_c_LIBRARY:STRING=-L/usr/lib -lxerces-c
> -> This is gcc specific BTW
>
> Could anyone on any platform think why the first option is always better
> and more portable than the second (or not) ?
There are IMO two big differences:
- the second one is sensible to -L ordering, so you may actually use a
library that is different than the one you expected.
- you can derive an rpath from the first and not from the second.
In a very annoying way, pkg-config expects you to use the second form. And
cmake will complain if both forms are used to link to the same target.
Maybe you should ask to the cmake MLs what is the right thing to do.
CMake musings about library paths
On Wednesday, June 03, 2009, at 10:37AM, "Peter Soetens" <peter [dot] soetens [..] ...> wrote:
>I'm noticing that if CMake macros detect a library in your
>environment, they store
>it in a variable, for example:
>
>Xerces_c_LIBRARY:FILEPATH=/usr/lib/libxerces-c.so
>
>The 'manual' checks we did until now would have resulted in something like:
>
>Xerces_c_LIBRARY:STRING=-L/usr/lib -lxerces-c
>-> This is gcc specific BTW
>
>Could anyone on any platform think why the first option is always better
>and more portable than the second (or not) ?
I would point out that
- the first version is more amenable to pulling part the dir/file pieces via CMake's GET_FILENAME_COMPONENT().
- the first is also better to provide to CMake's TARGET_LINK_LIBRARIES().
- the second is easier to construct from the first, than the other way around.
>This would also be the form in which it ends up in the .pc file.
Yes, second version is the .pc type we want IMHO.
Stephen