No subject


Tue Nov 1 15:57:14 EDT 2011


as small as possible.
This would waste some place but make the Config file totally standalone.

>> >> (2) The content of a relocatable BarConfig.cmake should not depend on
>> >> where it happened to be installed when the package was built.
>> >
>> > I don't see a real problem with this.
>> > Actually it is a good thing if the Config.cmake file can detect whethe=
r
>> > it is in the location where it should be according to
>> > CMAKE_INSTALL_PREFIX, e.g. to ensure that the libraries are installed =
in
>> > the right location (so the builtin RPATHs point to the right location)=
.
>>
>> Leaving remnants of the original build/install location is a no-no for
>> packagers.
>
> I don't know, we could ask them.
> Actually I don't think it would be a problem for a Linux distro packager,
> since in this case the original install destination will be also the fina=
l
> actual install location.
> I mean, they build the package for a place where it should be installed, =
and
> if you install the package via the normal package managers, this is where=
 they
> will end up.

Yes must be true, but you are right you need to ask to some packager.
On the other hand assuming that CMAKE_INSTALL_PREFIX should contain
the final location is ignoring the CPack use case totally....

First CPack use "CPACK_PACKAGING_INSTALL_PREFIX" and not "CMAKE_INSTALL_PRE=
FIX".
Second what would you do if relocate the package using for example
rpm --prefix or --relocate  (or dpkg -i --instdir ...) ?

Remember that "install time" may not be the same as "package install time".



More information about the cmake-developers mailing list