[Buildroot] [PATCH v2] package/eigen: use cmake-package infra

Julien Olivain juju at cotds.org
Mon Jun 15 18:47:18 UTC 2020

Yann, All,

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 
>> was
>> 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:
>> https://gitlab.com/libeigen/eigen/-/blob/3.3.7/CMakeLists.txt#L423
>> The library also provide a CMake macro that use this file to
>> detect it:
>> https://gitlab.com/libeigen/eigen/-/blob/3.3.7/cmake/FindEigen3.cmake#L76
>> Without the signature file installed, packages searching for this
>> library with this method will fail. Other packages usings pkg-config 
>> are
>> 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:
>>   https://gitlab.com/libeigen/eigen
>> - Removed all build and install staging commands
>>   (now included in upstream cmake)
>>   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
> git.

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>
> [--SNIP--]
>> +# Default Eigen CMake installs .pc file in
>> +# $(STAGING)/usr/share/pkgconfig
>> +# change it to lib/pkgconfig, to be consistent with other packages.
> 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. 
> Can
> 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 
> more
> traditional form unless there is a good reason not to.

The notations:
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 mailing list