[Buildroot] [PATCH v2] package/eigen: use cmake-package infra
juju at cotds.org
Mon Jun 15 18:47:18 UTC 2020
On 2020-06-14 23:15, Yann E. MORIN wrote:
> Julien, All,
> On 2020-06-14 19:37 +0200, Julien Olivain spake thusly:
>> The eigen package was introduced as a generic package, but upstream
>> in fact using CMake.
>> The motivation of this change is to fix package detection with CMake.
>> Eigen3 library normally installs a signature file named
>> "signature_of_eigen3_matrix_library" to help library detection:
>> The library also provide a CMake macro that use this file to
>> detect it:
>> Without the signature file installed, packages searching for this
>> library with this method will fail. Other packages usings pkg-config
>> not affected by this issue.
>> By using the cmake-package infrastructure, all the needed files
>> are now installed, fixing this CMake detection issue.
>> Other changes in this patch:
>> - Updated the Eigen git repository to the new url:
>> - Removed all build and install staging commands
>> (now included in upstream cmake)
>> - Package needs EIGEN_SUPPORTS_IN_SOURCE_BUILD = NO
>> - Removed the BR2_PACKAGE_EIGEN_UNSUPPORTED_MODULES option,
>> as this option is not proposed by the upstream CMake
> ... but they are unconditionally installed. A such, no need to
> introduce a legacy entry for BR2_PACKAGE_EIGEN_UNSUPPORTED_MODULES:
> users that had it enabled will still get the files installed, while
> those that did not will get them installed now.
I'll clarify the commit log by including your comment in an updated
>> - Updated hash for source package
> ... because the first component in the stored paths changed from
> eigen-eigen-323c052e1731/ to eigen-3.3.7/ and some mercurial related
> files (.hg_archival.txt, .hgtags) got dropped after the conversion to
I'll also include this comment.
>> - Reformat hash file with two spaces delimiters
>> - Define EIGEN_CONF_OPTS to set pkg-config .pc install path
> This one I am having a hard time with, see below...
>> Signed-off-by: Julien Olivain <juju at cotds.org>
>> +# Default Eigen CMake installs .pc file in
>> +# $(STAGING)/usr/share/pkgconfig
>> +# change it to lib/pkgconfig, to be consistent with other packages.
>> +EIGEN_CONF_OPTS = -DPKGCONFIG_INSTALL_DIR:PATH=lib/pkgconfig
> So this is a syntax that I am not familiar with.
> First, it uses a non-absolute path "lib/pkgconfig". This is strange to
> me. Second, it uses a variable with a colon PKGCONFIG_INSTALL_DIR:PATH,
> and I don't know that either.
> Yes, it works as expected, but I like to understand what's going on.
> you shed a light on this, please?
> I've tested -DPKGCONFIG_INSTALL_DIR=/usr/lib/pkgconfig which is the
> usual way we're used to in Buildroot, and that works too.
> I'll wait for your feedback on the above, but I'd prefer we use the
> traditional form unless there is a good reason not to.
will indeed give the same result.
I'll update the patch to use the traditional notation.
Some explanations how/why the first notation also works:
The -D variable:type=value option has been in cmake for at least a
it just gives a hint of the type of CMake variable. It was already
present in CMake 2.4:
The reason I've set the variable type was to match the type in
But this is not mandatory.
Then, the PKGCONFIG_INSTALL_DIR variable is used as a destination of a
install() cmake command:
A relative path is relative to CMAKE_INSTALL_PREFIX, which is set to
"/usr" by cmake-package infra:
Then, everything gets relocated at "make DESTDIR=... install/fast"
time, to be installed in staging directory (in that case).
Thanks for the review, I'll send the updated patch soon.
More information about the buildroot