cmake: remove version in directory structure

PATCH In review Maxime Roussin-Bélanger 3 participants 8 messages Nov 29, 2018 – Dec 5, 2018

Share & tools

Maxime Roussin-Bélanger

author

2018-11-29 23:51 UTC #0 lore raw

cover cmake: remove version in directory structure

I removed the version on the directory because it doesn't seems to be the philosophy the support multiple version of the same package in an embedded system.

The following changes since commit 41d89552620bfbc94031d314e6b3d0324f7a330e:

bitbake: fetch2: Avoid warning about incorrect character escaping in regex (2018-11-27 22:15:34 +0000)

are available in the Git repository at:

git://git.yoctoproject.org/poky-contrib mroussin/remove_cmake_version
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mroussin/remove_cmake_version

Maxime Roussin-Bélanger (1):
cmake: remove version in directory structure

 meta/recipes-devtools/cmake/cmake-native_3.12.2.bb | 2 ++
 meta/recipes-devtools/cmake/cmake_3.12.2.bb        | 7 ++++---
 2 files changed, 6 insertions(+), 3 deletions(-)

Signature · 1 line

2.19.2

Maxime Roussin-Bélanger

author

2018-11-29 23:52 UTC #1 lore raw

Remove the number because I don't think it's worth supporting multiple version of cmake inside an embedded product.

When using an SDK, using 2 different CMake is probably not a use case.

Signed-off-by Maxime Roussin-Bélanger <[email protected]>

---
 meta/recipes-devtools/cmake/cmake-native_3.12.2.bb | 2 ++
 meta/recipes-devtools/cmake/cmake_3.12.2.bb        | 7 ++++---
 2 files changed, 6 insertions(+), 3 deletions(-)

meta/recipes-devtools/cmake/cmake-native_3.12.2.bb +2 -0

index 9a1390f96d..3e59012b48 100644
@@ -16,6 +16,8 @@ do_configure[cleandirs] = "${B}"
 # Disable ccmake since we don't depend on ncurses
 CMAKE_EXTRACONF = "\
     -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \
+    -DCMAKE_DOC_DIR=doc/cmake \
+    -DCMAKE_DATA_DIR=share/cmake \
     -DBUILD_CursesDialog=0 \
     -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
     -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \

meta/recipes-devtools/cmake/cmake_3.12.2.bb +4 -3

index e0457677e8..0a3963b525 100644
@@ -26,7 +26,8 @@ python () {
 }
 
 EXTRA_OECMAKE=" \
-    -DCMAKE_DOC_DIR=${docdir_stripped}/cmake-${CMAKE_MAJOR_VERSION} \
+    -DCMAKE_DOC_DIR=${docdir_stripped}/cmake \
+    -DCMAKE_DATA_DIR=share/cmake \
     -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
     -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
     -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0 \

@@ -46,8 +47,8 @@ do_install_append_class-nativesdk() {
 
 FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
 
-FILES_${PN} += "${datadir}/cmake-${CMAKE_MAJOR_VERSION} ${datadir}/cmake ${datadir}/aclocal"
-FILES_${PN}-doc += "${docdir}/cmake-${CMAKE_MAJOR_VERSION}"
+FILES_${PN} += "${datadir}/cmake ${datadir}/aclocal"
+FILES_${PN}-doc += "${docdir}/cmake"
 FILES_${PN}-dev = ""
 
 BBCLASSEXTEND = "nativesdk"

Signature · 1 line

2.19.2

Burton, Ross

2018-11-29 23:55 UTC #2 lore raw

Quoted 6 lines · Maxime Roussin-Bélanger

Remove the number because I don't think it's worth supporting multiple version of cmake inside an embedded product.
When using an SDK, using 2 different CMake is probably not a use case.

Whilst that's a hard point to argue with, what's the problem that's being solved here?

Quoted 8 lines

EXTRA_OECMAKE=" \

meta/recipes-devtools/cmake/cmake_3.12.2.bb +2 -1

-    -DCMAKE_DOC_DIR=${docdir_stripped}/cmake-${CMAKE_MAJOR_VERSION} \
+    -DCMAKE_DOC_DIR=${docdir_stripped}/cmake \
+    -DCMAKE_DATA_DIR=share/cmake \
     -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
     -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
     -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0 \

meta/recipes-devtools/cmake/cmake_3.12.2.bb do_install_append_class-nativesdk() { · line 52

Quoted 8 lines

meta/recipes-devtools/cmake/cmake_3.12.2.bb +2 -2

@@ -46,8 +47,8 @@ do_install_append_class-nativesdk() {
 
 FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
 
-FILES_${PN} += "${datadir}/cmake-${CMAKE_MAJOR_VERSION} ${datadir}/cmake ${datadir}/aclocal"
-FILES_${PN}-doc += "${docdir}/cmake-${CMAKE_MAJOR_VERSION}"
+FILES_${PN} += "${datadir}/cmake ${datadir}/aclocal"
+FILES_${PN}-doc += "${docdir}/cmake"
 FILES_${PN}-dev = ""

If the distro has set $datadir to something other than the default then -DCMAKE_DATA_DIR=share/cmake won't match FILES_${PN} += ${datadir}/cmake, you need to do the same calculation that docdir_stripped already does.

Ross

Maxime Roussin-Bélanger

author

2018-11-30 01:30 UTC #3 lore raw

Quoted 7 lines · Ross

Quoted 4 lines · Maxime Roussin-Bélanger
Remove the number because I don't think it's worth supporting multiple version of cmake inside an embedded product.

Quoted 5 lines

Quoted 2 lines
When using an SDK, using 2 different CMake is probably not a use case.
Whilst that's a hard point to argue with, what's the problem that's being solved here?

If CMake is in the cmake-x.xx directory and then there is libeigen that adds their own cmake modules to the cmake/modules.

So now you have the cmake modules inside cmake-x.xx/Modules and some in cmake/modules. Your project will have to update the CMAKE_MODULE_PATH, if they wanna use libeigen.

Well, I think that's how it works. All of the recipes that want to add their own
module they have to use cmake/Modules, because they can't possibly know which cmake version we are using.

So I thought maybe put them all in the same directory so no one has to deal with the fact that 2 directories are used for the same thing.

Less confusing?

Quoted 10 lines

EXTRA_OECMAKE=" \

meta/recipes-devtools/cmake/cmake_3.12.2.bb +2 -1

-    -DCMAKE_DOC_DIR=${docdir_stripped}/cmake-${CMAKE_MAJOR_VERSION} \
+    -DCMAKE_DOC_DIR=${docdir_stripped}/cmake \
+    -DCMAKE_DATA_DIR=share/cmake \
     -DCMAKE_USE_SYSTEM_LIBRARIES=1 \
     -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \
     -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0 \

@@ -46,8 +47,8 @@ do_install_append_class-nativesdk() {

Quoted 3 lines

meta/recipes-devtools/cmake/cmake_3.12.2.bb do_install_append_class-nativesdk() {
Quoted 3 lines
meta/recipes-devtools/cmake/cmake_3.12.2.bb +0 -1
 FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
 
-FILES_${PN} += "${datadir}/cmake-${CMAKE_MAJOR_VERSION}

${datadir}/cmake ${datadir}/aclocal"

Quoted 9 lines

meta/recipes-devtools/cmake/cmake_3.12.2.bb do_install_append_class-nativesdk() { · line 52
Quoted 4 lines
meta/recipes-devtools/cmake/cmake_3.12.2.bb +2 -1
-FILES_${PN}-doc += "${docdir}/cmake-${CMAKE_MAJOR_VERSION}"
+FILES_${PN} += "${datadir}/cmake ${datadir}/aclocal"
+FILES_${PN}-doc += "${docdir}/cmake"
 FILES_${PN}-dev = ""
If the distro has set $datadir to something other than the default then -DCMAKE_DATA_DIR=share/cmake won't match FILES_${PN} += ${datadir}/cmake, you need to do the same calculation that docdir_stripped already does.

Thanks didn't know about that.

Quoted 3 lines

Ross

Max

Burton, Ross

2018-11-30 10:29 UTC #4 lore raw

Quoted 11 lines · Maxime Roussin-Bélanger

Quoted 2 lines
Whilst that's a hard point to argue with, what's the problem that's being solved here?
If CMake is in the cmake-x.xx directory and then there is libeigen that adds their own cmake modules to the cmake/modules.
So now you have the cmake modules inside cmake-x.xx/Modules and some in cmake/modules. Your project will have to update the CMAKE_MODULE_PATH, if they wanna use libeigen.

Quoted 8 lines

Well, I think that's how it works. All of the recipes that want to add their own module they have to use cmake/Modules, because they can't possibly know which cmake version we are using.
So I thought maybe put them all in the same directory so no one has to deal with the fact that 2 directories are used for the same thing.
Less confusing?

The context is useful, thanks. Note that Debian does exactly the
same: cmake installs to /usr/lib/cmake-[version] and eigen installs to /usr/lib/cmake/, and that works. Is this a problem in general builds or just the SDK? Possibly our toolchain file is breaking the usual lookup.

Ross

Maxime Roussin-Bélanger

author

2018-11-30 15:48 UTC #5 lore raw

Quoted 9 lines · Ross

On Fri, 30 Nov 2018 at 01:30, Maxime Roussin-Bélanger <[email protected]> wrote:
The context is useful, thanks. Note that Debian does exactly the
same: cmake installs to /usr/lib/cmake-[version] and eigen installs to /usr/lib/cmake/, and that works. Is this a problem in general builds or just the SDK? Possibly our toolchain file is breaking the usual lookup.

Yes it works (in general builds) because inside cmake.bbclass there is that line

list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")

But when you are using the SDK that path is not added. That means that all library that
are installed inside that directory can't be found.

Quoted 2 lines

Ross

Scott Rifenbark

2018-11-30 15:56 UTC #6 lore raw

Ross,

Do these changes impact
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12760 at all? I was looking into that bug regarding potential doc changes.

Scott

Quoted 31 lines · Maxime Roussin-Bélanger

Quoted 9 lines · Ross
On Fri, 30 Nov 2018 at 01:30, Maxime Roussin-Bélanger <[email protected]> wrote:
The context is useful, thanks. Note that Debian does exactly the
same: cmake installs to /usr/lib/cmake-[version] and eigen installs to /usr/lib/cmake/, and that works. Is this a problem in general builds or just the SDK? Possibly our toolchain file is breaking the usual lookup.
Yes it works (in general builds) because inside cmake.bbclass there is that line
list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")
But when you are using the SDK that path is not added. That means that all library that
are installed inside that directory can't be found.
Quoted 2 lines
Ross
--
_______________________________________________
poky mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/poky

Maxime Roussin-Bélanger

author

2018-12-05 14:20 UTC #7 lore raw

Quoted 4 lines · Scott Rifenbark

Ross,
Do these changes impact

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12760 at all? I was looking into that bug regarding potential doc changes.

Quoted 3 lines

Scott

Should I send a v2 with a better commit description? Or you want to verify that Bugzilla ticket with Scott first?

I have an additional change to add.