All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
@ 2017-02-28 18:07 ` Yann E. MORIN
  2017-02-28 18:26   ` Baruch Siach
                     ` (3 more replies)
  2017-02-28 18:07 ` [Buildroot] [PATCH 2/5] cmake: bump version to 3.7.0 Yann E. MORIN
                   ` (5 subsequent siblings)
  6 siblings, 4 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 18:07 UTC (permalink / raw)
  To: buildroot

The handling of RPATH in cmake-3.7 has changed drastically, causing a
slew of build failures dues to libraries from the host being pulled in:

  - domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7abf973691b39a0ca1bb4e07d749593a/
  - freerdp  : http://autobuild.buildroot.org/results/5d4/5d429d0e288754a541ee5d8be515454c5fccd28b/
  - libcec   : http://autobuild.buildroot.org/results/3f3/3f3593bab7734dd274faf5b5690895e9424cbb89/
  - and so on...

The bug was reported upstream [0], which dismissed it altogether [1] as
being expected behaviour, quoting:

    I don't think there is anything wrong with that change on its own.
    It merely exposed some existing behavior in a new case.

Instead, upstream suggested in that same message that a platform
definition be used instead, quoting:

    If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
    `Platform/MySystem.cmake` file is loaded then the latter can set
    them as needed for the target platform.

So here we are doing so:

  - we add a new platfom definitions that inherits from the Linux one,
    then overrides the problematic settings;

  - we change our toolchain file to use that platform instead;

  - we tell cmake where to find additional modules, so that it can find
    our custom platform file.

This has been tested to work in the following conditions:

 - pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
   (manually built)

  - internal cmake, versions 3.6.3 (the current version as of this
    patch) and 3.7.2 (with the followup patches).

Thanks to J?rg, Ben and Baruch for the help investigating the issue.
Special thanks to J?rg for handling the discussion with upstream and
pointing to the relevant messages! :-)

[0] http://public.kitware.com/pipermail/cmake/2017-February/064970.html
[1] http://public.kitware.com/pipermail/cmake/2017-February/065063.html

To be noted: Thomas suggested we set these directly in the toolchain
file. Unfortunately, wherever we put those settings in the toolchain
file, this does not work.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: J?rg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
---
 package/pkg-cmake.mk                | 4 ++++
 support/misc/Buildroot.cmake        | 3 +++
 support/misc/toolchainfile.cmake.in | 2 +-
 toolchain/toolchain/toolchain.mk    | 1 +
 4 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 support/misc/Buildroot.cmake

diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
index a7c8dc3..77fa1dc 100644
--- a/package/pkg-cmake.mk
+++ b/package/pkg-cmake.mk
@@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
 	PATH=$$(BR_PATH) \
 	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
 		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
+		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \
 		-DCMAKE_INSTALL_PREFIX="/usr" \
 		-DCMAKE_COLOR_MAKEFILE=OFF \
 		-DBUILD_DOC=OFF \
@@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
 		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
 		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
 		> $@
+
+$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
+	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)
diff --git a/support/misc/Buildroot.cmake b/support/misc/Buildroot.cmake
new file mode 100644
index 0000000..b0046b3
--- /dev/null
+++ b/support/misc/Buildroot.cmake
@@ -0,0 +1,3 @@
+include(Platform/Linux)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
+set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
diff --git a/support/misc/toolchainfile.cmake.in b/support/misc/toolchainfile.cmake.in
index d4252dd..5a42644 100644
--- a/support/misc/toolchainfile.cmake.in
+++ b/support/misc/toolchainfile.cmake.in
@@ -10,7 +10,7 @@
 # RELOCATED_HOST_DIR variable.
 string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
 
-set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_NAME Buildroot)
 set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
 
 # Set the {C,CXX}FLAGS appended by CMake depending on the build type
diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
index b16db01..e298373 100644
--- a/toolchain/toolchain/toolchain.mk
+++ b/toolchain/toolchain/toolchain.mk
@@ -38,3 +38,4 @@ endif
 $(eval $(virtual-package))
 
 toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
+toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7
@ 2017-02-28 18:07 Yann E. MORIN
  2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
                   ` (6 more replies)
  0 siblings, 7 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 18:07 UTC (permalink / raw)
  To: buildroot

Hello All!

This series re-introduces cmake-3.7, along with a way to fix the RPATH
issue in this release, and slated to stay upstream as-is.

We define a new platform that gets rid of the offending settings. See
the first commit log for the nitty-gritty details. This works for all
versions of cmake, so is safe to do before re-introducing cmake-3.7.

Once we have this support, we can bump cmake again. We reuse the four
original patches, to keep authoorship (although they could well all be
squashed into one).


Regards,
Yann E. MORIN.


The following changes since commit 1c186c6ca1689111fb2a4a164f57b3b96ebd21c8

  qt5quickcontrols: fix installation of PrivateWidgets (2017-02-28 15:55:29 +0100)


are available in the git repository at:

  git://git.buildroot.org/~ymorin/git/buildroot.git

for you to fetch changes up to a97614e367871d75a4e109b7d45a6dd48fb9fe19

  cmake: bump version to 3.7.2 (2017-02-28 19:00:20 +0100)


----------------------------------------------------------------
Thomas Petazzoni (1):
      cmake: adjust dependencies added for libuv

Vicente Olivert Riera (3):
      cmake: bump version to 3.7.0
      cmake: bump version to 3.7.1
      cmake: bump version to 3.7.2

Yann E. MORIN (1):
      core/pkg-cmake: provide our own platform description

 package/cmake/Config.in             | 9 +++++++--
 package/cmake/cmake.hash            | 4 ++--
 package/cmake/cmake.mk              | 6 +++---
 package/pkg-cmake.mk                | 4 ++++
 support/misc/Buildroot.cmake        | 3 +++
 support/misc/toolchainfile.cmake.in | 2 +-
 toolchain/toolchain/toolchain.mk    | 1 +
 7 files changed, 21 insertions(+), 8 deletions(-)
 create mode 100644 support/misc/Buildroot.cmake

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 2/5] cmake: bump version to 3.7.0
  2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
  2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
@ 2017-02-28 18:07 ` Yann E. MORIN
  2017-02-28 18:07 ` [Buildroot] [PATCH 3/5] cmake: bump version to 3.7.1 Yann E. MORIN
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 18:07 UTC (permalink / raw)
  To: buildroot

From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

libuv is now a required dependency.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/cmake/Config.in  | 9 +++++++--
 package/cmake/cmake.hash | 4 ++--
 package/cmake/cmake.mk   | 6 +++---
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/package/cmake/Config.in b/package/cmake/Config.in
index 6f04a4a..716d80e 100644
--- a/package/cmake/Config.in
+++ b/package/cmake/Config.in
@@ -20,11 +20,14 @@ config BR2_PACKAGE_CMAKE_CTEST
 	select BR2_PACKAGE_EXPAT
 	select BR2_PACKAGE_BZIP2
 	select BR2_PACKAGE_XZ
+	select BR2_PACKAGE_LIBUV
 	depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 # from jsoncpp
 	depends on BR2_USE_WCHAR # libarchive
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on !BR2_STATIC_LIBS
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libuv
+	depends on BR2_USE_MMU # libuv
 	help
 	  CTest is a testing tool distributed as a part of CMake. It
 	  can be used to automate updating (using CVS for example),
@@ -34,7 +37,9 @@ config BR2_PACKAGE_CMAKE_CTEST
 
 	  http://www.cmake.org/
 
-comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7"
+comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7, threads"
 	depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
+	depends on BR2_USE_MMU
 	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
-		BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
+		BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 || \
+		!BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash
index f846dc9..687e5a4 100644
--- a/package/cmake/cmake.hash
+++ b/package/cmake/cmake.hash
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.6/cmake-3.6.3-SHA-256.txt
-sha256 7d73ee4fae572eb2d7cd3feb48971aea903bb30a20ea5ae8b4da826d8ccad5fe  cmake-3.6.3.tar.gz
+# From http://www.cmake.org/files/v3.7/cmake-3.7.0-SHA-256.txt
+sha256 ed63e05c41aeb6c036e503114ab15847f29c312f9f21f5f1a7060a4b4ec2fb31  cmake-3.7.0.tar.gz
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index bc55509..e4904fc 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -4,8 +4,8 @@
 #
 ################################################################################
 
-CMAKE_VERSION_MAJOR = 3.6
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3
+CMAKE_VERSION_MAJOR = 3.7
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).0
 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
 CMAKE_LICENSE = BSD-3c
 CMAKE_LICENSE_FILES = Copyright.txt
@@ -22,7 +22,7 @@ CMAKE_LICENSE_FILES = Copyright.txt
 #   the system-wide libraries instead of rebuilding and statically
 #   linking with the ones bundled into the CMake sources.
 
-CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz
+CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz libuv
 
 CMAKE_CONF_OPTS = \
 	-DKWSYS_LFS_WORKS=TRUE \
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 3/5] cmake: bump version to 3.7.1
  2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
  2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
  2017-02-28 18:07 ` [Buildroot] [PATCH 2/5] cmake: bump version to 3.7.0 Yann E. MORIN
@ 2017-02-28 18:07 ` Yann E. MORIN
  2017-02-28 18:07 ` [Buildroot] [PATCH 4/5] cmake: adjust dependencies added for libuv Yann E. MORIN
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 18:07 UTC (permalink / raw)
  To: buildroot

From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 package/cmake/cmake.hash | 4 ++--
 package/cmake/cmake.mk   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash
index 687e5a4..7a22f21 100644
--- a/package/cmake/cmake.hash
+++ b/package/cmake/cmake.hash
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.7/cmake-3.7.0-SHA-256.txt
-sha256 ed63e05c41aeb6c036e503114ab15847f29c312f9f21f5f1a7060a4b4ec2fb31  cmake-3.7.0.tar.gz
+# From http://www.cmake.org/files/v3.7/cmake-3.7.1-SHA-256.txt
+sha256 449a5bce64dbd4d5b9517ebd1a1248ed197add6ad27934478976fd5f1f9330e1  cmake-3.7.1.tar.gz
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index e4904fc..107715c 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -5,7 +5,7 @@
 ################################################################################
 
 CMAKE_VERSION_MAJOR = 3.7
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).0
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).1
 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
 CMAKE_LICENSE = BSD-3c
 CMAKE_LICENSE_FILES = Copyright.txt
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 4/5] cmake: adjust dependencies added for libuv
  2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
                   ` (2 preceding siblings ...)
  2017-02-28 18:07 ` [Buildroot] [PATCH 3/5] cmake: bump version to 3.7.1 Yann E. MORIN
@ 2017-02-28 18:07 ` Yann E. MORIN
  2017-02-28 18:07 ` [Buildroot] [PATCH 5/5] cmake: bump version to 3.7.2 Yann E. MORIN
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 18:07 UTC (permalink / raw)
  To: buildroot

From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Commit 1ffcf364b6e9894a876dc581a090f87685945412 updated cmake to 3.7.0,
which requires selecting the libuv package. At the time, the libuv
package only depended on BR2_TOOLCHAIN_HAS_THREADS. However, later on,
it was changed in master to depend on BR2_TOOLCHAIN_HAS_THREADS_NPTL, a
change which was not taken into account in the cmake 3.7.0 bump that was
merged in the next branch.

Due to this, builds of cmake is attempted on architectures that don't
provide NPTL thread support, causing a build failure. This commit fixes
that by adjusting the dependency.

Fixes:

  http://autobuild.buildroot.net/results/16a5e1cbb57c0124537c4f3dc0807ba1eaa975ec/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/cmake/Config.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/cmake/Config.in b/package/cmake/Config.in
index 716d80e..2706db5 100644
--- a/package/cmake/Config.in
+++ b/package/cmake/Config.in
@@ -26,7 +26,7 @@ config BR2_PACKAGE_CMAKE_CTEST
 	depends on BR2_USE_WCHAR # libarchive
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on !BR2_STATIC_LIBS
-	depends on BR2_TOOLCHAIN_HAS_THREADS # libuv
+	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # libuv
 	depends on BR2_USE_MMU # libuv
 	help
 	  CTest is a testing tool distributed as a part of CMake. It
@@ -37,9 +37,9 @@ config BR2_PACKAGE_CMAKE_CTEST
 
 	  http://www.cmake.org/
 
-comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7, threads"
+comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7, NPTL"
 	depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
 	depends on BR2_USE_MMU
 	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
 		BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 || \
-		!BR2_TOOLCHAIN_HAS_THREADS
+		!BR2_TOOLCHAIN_HAS_THREADS_NPTL
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 5/5] cmake: bump version to 3.7.2
  2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
                   ` (3 preceding siblings ...)
  2017-02-28 18:07 ` [Buildroot] [PATCH 4/5] cmake: adjust dependencies added for libuv Yann E. MORIN
@ 2017-02-28 18:07 ` Yann E. MORIN
  2017-03-01  7:49 ` [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Arnout Vandecappelle
  2017-03-01 21:14 ` Thomas Petazzoni
  6 siblings, 0 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 18:07 UTC (permalink / raw)
  To: buildroot

From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 package/cmake/cmake.hash | 4 ++--
 package/cmake/cmake.mk   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash
index 7a22f21..13c0237 100644
--- a/package/cmake/cmake.hash
+++ b/package/cmake/cmake.hash
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.7/cmake-3.7.1-SHA-256.txt
-sha256 449a5bce64dbd4d5b9517ebd1a1248ed197add6ad27934478976fd5f1f9330e1  cmake-3.7.1.tar.gz
+# From http://www.cmake.org/files/v3.7/cmake-3.7.2-SHA-256.txt
+sha256 dc1246c4e6d168ea4d6e042cfba577c1acd65feea27e56f5ff37df920c30cae0  cmake-3.7.2.tar.gz
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index 107715c..0fd7139 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -5,7 +5,7 @@
 ################################################################################
 
 CMAKE_VERSION_MAJOR = 3.7
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).1
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).2
 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
 CMAKE_LICENSE = BSD-3c
 CMAKE_LICENSE_FILES = Copyright.txt
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
@ 2017-02-28 18:26   ` Baruch Siach
  2017-02-28 20:03     ` Yann E. MORIN
  2017-02-28 20:41   ` Jörg Krause
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 26+ messages in thread
From: Baruch Siach @ 2017-02-28 18:26 UTC (permalink / raw)
  To: buildroot

Hi Yann,

On Tue, Feb 28, 2017 at 07:07:22PM +0100, Yann E. MORIN wrote:
> diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
> index a7c8dc3..77fa1dc 100644
> --- a/package/pkg-cmake.mk
> +++ b/package/pkg-cmake.mk
> @@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
>  	PATH=$$(BR_PATH) \
>  	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
>  		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
> +		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \
>  		-DCMAKE_INSTALL_PREFIX="/usr" \
>  		-DCMAKE_COLOR_MAKEFILE=OFF \
>  		-DBUILD_DOC=OFF \
> @@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
>  		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
>  		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
>  		> $@
> +
> +$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
> +	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)
> diff --git a/support/misc/Buildroot.cmake b/support/misc/Buildroot.cmake
> new file mode 100644
> index 0000000..b0046b3
> --- /dev/null
> +++ b/support/misc/Buildroot.cmake
> @@ -0,0 +1,3 @@
> +include(Platform/Linux)

So this goes to the host directory in case of host installed cmake? What 
happens when the host installed cmake is older than 3.1? Does the Buildroot 
built module path override the host installed one?

baruch

> +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
> +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
> diff --git a/support/misc/toolchainfile.cmake.in b/support/misc/toolchainfile.cmake.in
> index d4252dd..5a42644 100644
> --- a/support/misc/toolchainfile.cmake.in
> +++ b/support/misc/toolchainfile.cmake.in
> @@ -10,7 +10,7 @@
>  # RELOCATED_HOST_DIR variable.
>  string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
>  
> -set(CMAKE_SYSTEM_NAME Linux)
> +set(CMAKE_SYSTEM_NAME Buildroot)
>  set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
>  
>  # Set the {C,CXX}FLAGS appended by CMake depending on the build type
> diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> index b16db01..e298373 100644
> --- a/toolchain/toolchain/toolchain.mk
> +++ b/toolchain/toolchain/toolchain.mk
> @@ -38,3 +38,4 @@ endif
>  $(eval $(virtual-package))
>  
>  toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
> +toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 18:26   ` Baruch Siach
@ 2017-02-28 20:03     ` Yann E. MORIN
  0 siblings, 0 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 20:03 UTC (permalink / raw)
  To: buildroot

Baruch, All,

On 2017-02-28 20:26 +0200, Baruch Siach spake thusly:
> On Tue, Feb 28, 2017 at 07:07:22PM +0100, Yann E. MORIN wrote:
> > diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
> > index a7c8dc3..77fa1dc 100644
> > --- a/package/pkg-cmake.mk
> > +++ b/package/pkg-cmake.mk
> > @@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
> >  	PATH=$$(BR_PATH) \
> >  	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
> >  		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
> > +		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \
> >  		-DCMAKE_INSTALL_PREFIX="/usr" \
> >  		-DCMAKE_COLOR_MAKEFILE=OFF \
> >  		-DBUILD_DOC=OFF \
> > @@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
> >  		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
> >  		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
> >  		> $@
> > +
> > +$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
> > +	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)
> > diff --git a/support/misc/Buildroot.cmake b/support/misc/Buildroot.cmake
> > new file mode 100644
> > index 0000000..b0046b3
> > --- /dev/null
> > +++ b/support/misc/Buildroot.cmake
> > @@ -0,0 +1,3 @@
> > +include(Platform/Linux)
> 
> So this goes to the host directory in case of host installed cmake? What 
> happens when the host installed cmake is older than 3.1? Does the Buildroot 
> built module path override the host installed one?

When the host cmake is older than 3.1, we build and use our own cmake.

And the modules path we provide is looked for first, then cmake uses the
builtin one:
    https://cmake.org/cmake/help/v3.0/variable/CMAKE_MODULE_PATH.html

I should have written that in the commit log, indeed.

Regards,
Yann E. MORIN.

> baruch
> 
> > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
> > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
> > diff --git a/support/misc/toolchainfile.cmake.in b/support/misc/toolchainfile.cmake.in
> > index d4252dd..5a42644 100644
> > --- a/support/misc/toolchainfile.cmake.in
> > +++ b/support/misc/toolchainfile.cmake.in
> > @@ -10,7 +10,7 @@
> >  # RELOCATED_HOST_DIR variable.
> >  string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
> >  
> > -set(CMAKE_SYSTEM_NAME Linux)
> > +set(CMAKE_SYSTEM_NAME Buildroot)
> >  set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
> >  
> >  # Set the {C,CXX}FLAGS appended by CMake depending on the build type
> > diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> > index b16db01..e298373 100644
> > --- a/toolchain/toolchain/toolchain.mk
> > +++ b/toolchain/toolchain/toolchain.mk
> > @@ -38,3 +38,4 @@ endif
> >  $(eval $(virtual-package))
> >  
> >  toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
> > +toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake
> 
> -- 
>      http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
  2017-02-28 18:26   ` Baruch Siach
@ 2017-02-28 20:41   ` Jörg Krause
  2017-02-28 20:58     ` Yann E. MORIN
  2017-03-01  7:58   ` Arnout Vandecappelle
  2017-03-02 12:29   ` Baruch Siach
  3 siblings, 1 reply; 26+ messages in thread
From: Jörg Krause @ 2017-02-28 20:41 UTC (permalink / raw)
  To: buildroot

Hi Yann,

On Tue, 2017-02-28 at 19:07 +0100, Yann E. MORIN wrote:
> The handling of RPATH in cmake-3.7 has changed drastically, causing a
> slew of build failures dues to libraries from the host being pulled
> in:
> 
> ? - domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7ab
> f973691b39a0ca1bb4e07d749593a/
> ? - freerdp??: http://autobuild.buildroot.org/results/5d4/5d429d0e288
> 754a541ee5d8be515454c5fccd28b/
> ? - libcec???: http://autobuild.buildroot.org/results/3f3/3f3593bab77
> 34dd274faf5b5690895e9424cbb89/
> ? - and so on...
> 
> The bug was reported upstream [0], which dismissed it altogether [1]
> as
> being expected behaviour, quoting:
> 
> ????I don't think there is anything wrong with that change on its
> own.
> ????It merely exposed some existing behavior in a new case.
> 
> Instead, upstream suggested in that same message that a platform
> definition be used instead, quoting:
> 
> ????If a toolchain file specifies CMAKE_SYSTEM_NAME such that a
> custom
> ????`Platform/MySystem.cmake` file is loaded then the latter can set
> ????them as needed for the target platform.

Upstream has opened an issue [1] about this and is already working on a
fix [2] for version 3.7 and 3.8. It fixes the behavior of how
FIND_LIBRARY_USE_LIB32_PATHS handle symlinks.?As 'lib32' is just just a
symlink to 'lib' in Buildroot, 'find_library()' will skip 'lib32' as a
runtime search path and as a consequence 'lib32' will not be used as
rpath anymore.

> So here we are doing so:
> 
> ? - we add a new platfom definitions that inherits from the Linux
> one,
> ????then overrides the problematic settings;
> 
> ? - we change our toolchain file to use that platform instead;
> 
> ? - we tell cmake where to find additional modules, so that it can
> find
> ????our custom platform file.

As the issue might be fixed at some point, do we want to keep the
custom platform file?

> This has been tested to work in the following conditions:
> 
> ?- pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
> ???(manually built)
> 
> ? - internal cmake, versions 3.6.3 (the current version as of this
> ????patch) and 3.7.2 (with the followup patches).
> 
> Thanks to J?rg, Ben and Baruch for the help investigating the issue.
> Special thanks to J?rg for handling the discussion with upstream and
> pointing to the relevant messages! :-)

You are welcome!

[1] https://gitlab.kitware.com/cmake/cmake/issues/16682
[2] https://gitlab.kitware.com/cmake/cmake/merge_requests/534

J?rg

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 20:41   ` Jörg Krause
@ 2017-02-28 20:58     ` Yann E. MORIN
  2017-02-28 22:15       ` Jörg Krause
  2017-03-01  8:01       ` Arnout Vandecappelle
  0 siblings, 2 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-02-28 20:58 UTC (permalink / raw)
  To: buildroot

J?rg, All,

On 2017-02-28 21:41 +0100, J?rg Krause spake thusly:
> On Tue, 2017-02-28 at 19:07 +0100, Yann E. MORIN wrote:
> > The handling of RPATH in cmake-3.7 has changed drastically, causing a
> > slew of build failures dues to libraries from the host being pulled
> > in:
> > 
> > ? - domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7ab
> > f973691b39a0ca1bb4e07d749593a/
> > ? - freerdp??: http://autobuild.buildroot.org/results/5d4/5d429d0e288
> > 754a541ee5d8be515454c5fccd28b/
> > ? - libcec???: http://autobuild.buildroot.org/results/3f3/3f3593bab77
> > 34dd274faf5b5690895e9424cbb89/
> > ? - and so on...
> > 
> > The bug was reported upstream [0], which dismissed it altogether [1]
> > as
> > being expected behaviour, quoting:
> > 
> > ????I don't think there is anything wrong with that change on its
> > own.
> > ????It merely exposed some existing behavior in a new case.
> > 
> > Instead, upstream suggested in that same message that a platform
> > definition be used instead, quoting:
> > 
> > ????If a toolchain file specifies CMAKE_SYSTEM_NAME such that a
> > custom
> > ????`Platform/MySystem.cmake` file is loaded then the latter can set
> > ????them as needed for the target platform.
> 
> Upstream has opened an issue [1] about this and is already working on a
> fix [2] for version 3.7 and 3.8. It fixes the behavior of how
> FIND_LIBRARY_USE_LIB32_PATHS handle symlinks.?As 'lib32' is just just a
> symlink to 'lib' in Buildroot, 'find_library()' will skip 'lib32' as a
> runtime search path and as a consequence 'lib32' will not be used as
> rpath anymore.
> 
> > So here we are doing so:
> > 
> > ? - we add a new platfom definitions that inherits from the Linux
> > one,
> > ????then overrides the problematic settings;
> > 
> > ? - we change our toolchain file to use that platform instead;
> > 
> > ? - we tell cmake where to find additional modules, so that it can
> > find
> > ????our custom platform file.
> 
> As the issue might be fixed at some point, do we want to keep the
> custom platform file?

Well, what bad would it do to have our own platform file? We could even
use it for yet more options if need be.

And in the meantime, there is no release of cmake with a fix. I'll
believe they've fixed it when I see it! ;-)

Regards,
Yann E. MORIN.

> > This has been tested to work in the following conditions:
> > 
> > ?- pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
> > ???(manually built)
> > 
> > ? - internal cmake, versions 3.6.3 (the current version as of this
> > ????patch) and 3.7.2 (with the followup patches).
> > 
> > Thanks to J?rg, Ben and Baruch for the help investigating the issue.
> > Special thanks to J?rg for handling the discussion with upstream and
> > pointing to the relevant messages! :-)
> 
> You are welcome!
> 
> [1] https://gitlab.kitware.com/cmake/cmake/issues/16682
> [2] https://gitlab.kitware.com/cmake/cmake/merge_requests/534
> 
> J?rg

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 20:58     ` Yann E. MORIN
@ 2017-02-28 22:15       ` Jörg Krause
  2017-03-01  8:01       ` Arnout Vandecappelle
  1 sibling, 0 replies; 26+ messages in thread
From: Jörg Krause @ 2017-02-28 22:15 UTC (permalink / raw)
  To: buildroot

Hi Yann,

On Tue, 2017-02-28 at 21:58 +0100, Yann E. MORIN wrote:
> J?rg, All,
> 
> On 2017-02-28 21:41 +0100, J?rg Krause spake thusly:
> > On Tue, 2017-02-28 at 19:07 +0100, Yann E. MORIN wrote:
> > > The handling of RPATH in cmake-3.7 has changed drastically,
> > > causing a
> > > slew of build failures dues to libraries from the host being
> > > pulled
> > > in:
> > > 
> > > ? - domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54
> > > c7ab
> > > f973691b39a0ca1bb4e07d749593a/
> > > ? - freerdp??: http://autobuild.buildroot.org/results/5d4/5d429d0
> > > e288
> > > 754a541ee5d8be515454c5fccd28b/
> > > ? - libcec???: http://autobuild.buildroot.org/results/3f3/3f3593b
> > > ab77
> > > 34dd274faf5b5690895e9424cbb89/
> > > ? - and so on...
> > > 
> > > The bug was reported upstream [0], which dismissed it altogether
> > > [1]
> > > as
> > > being expected behaviour, quoting:
> > > 
> > > ????I don't think there is anything wrong with that change on its
> > > own.
> > > ????It merely exposed some existing behavior in a new case.
> > > 
> > > Instead, upstream suggested in that same message that a platform
> > > definition be used instead, quoting:
> > > 
> > > ????If a toolchain file specifies CMAKE_SYSTEM_NAME such that a
> > > custom
> > > ????`Platform/MySystem.cmake` file is loaded then the latter can
> > > set
> > > ????them as needed for the target platform.
> > 
> > Upstream has opened an issue [1] about this and is already working
> > on a
> > fix [2] for version 3.7 and 3.8. It fixes the behavior of how
> > FIND_LIBRARY_USE_LIB32_PATHS handle symlinks.?As 'lib32' is just
> > just a
> > symlink to 'lib' in Buildroot, 'find_library()' will skip 'lib32'
> > as a
> > runtime search path and as a consequence 'lib32' will not be used
> > as
> > rpath anymore.
> > 
> > > So here we are doing so:
> > > 
> > > ? - we add a new platfom definitions that inherits from the Linux
> > > one,
> > > ????then overrides the problematic settings;
> > > 
> > > ? - we change our toolchain file to use that platform instead;
> > > 
> > > ? - we tell cmake where to find additional modules, so that it
> > > can
> > > find
> > > ????our custom platform file.
> > 
> > As the issue might be fixed at some point, do we want to keep the
> > custom platform file?
> 
> Well, what bad would it do to have our own platform file? We could
> even
> use it for yet more options if need be.

No offense. There is nothing wrong about having a custom buildroot
platform file.

> And in the meantime, there is no release of cmake with a fix. I'll
> believe they've fixed it when I see it! ;-)

:-)

J?rg

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7
  2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
                   ` (4 preceding siblings ...)
  2017-02-28 18:07 ` [Buildroot] [PATCH 5/5] cmake: bump version to 3.7.2 Yann E. MORIN
@ 2017-03-01  7:49 ` Arnout Vandecappelle
  2017-03-01  7:59   ` Thomas Petazzoni
  2017-03-01 21:14 ` Thomas Petazzoni
  6 siblings, 1 reply; 26+ messages in thread
From: Arnout Vandecappelle @ 2017-03-01  7:49 UTC (permalink / raw)
  To: buildroot



On 28-02-17 19:07, Yann E. MORIN wrote:
> Once we have this support, we can bump cmake again. We reuse the four
> original patches, to keep authoorship (although they could well all be
> squashed into one).

 I don't think it makes much sense to keep the 4 separate patches. The history
shows the authorship of the original bump. Having the 4 separate patches just
adds noise to the history. Also, Thomas reported that the libuv dependency
introduced by the bump is probably incorrect, so we'd have to revert patch 4/5
and part of patch 2/5 again later on... And if the dependency on libuv *is*
needed, then you re-introduce a non-bisectable commit between patch 2/5 and 4/5.

 Regards,
 Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
  2017-02-28 18:26   ` Baruch Siach
  2017-02-28 20:41   ` Jörg Krause
@ 2017-03-01  7:58   ` Arnout Vandecappelle
  2017-03-01  8:17     ` Thomas Petazzoni
  2017-03-02 12:29   ` Baruch Siach
  3 siblings, 1 reply; 26+ messages in thread
From: Arnout Vandecappelle @ 2017-03-01  7:58 UTC (permalink / raw)
  To: buildroot



On 28-02-17 19:07, Yann E. MORIN wrote:
> The handling of RPATH in cmake-3.7 has changed drastically, causing a
> slew of build failures dues to libraries from the host being pulled in:
[snip]
>   - we add a new platfom definitions that inherits from the Linux one,
>     then overrides the problematic settings;

 Not mentioned in the commit log but important to note: this platform file is
only used for target CMake packages, not host packages.

[snip]
> diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
> index a7c8dc3..77fa1dc 100644
> --- a/package/pkg-cmake.mk
> +++ b/package/pkg-cmake.mk
> @@ -87,6 +87,7 @@ define $(2)_CONFIGURE_CMDS
>  	PATH=$$(BR_PATH) \
>  	$$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
>  		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
> +		-DCMAKE_MODULE_PATH="$$(HOST_DIR)/usr/share/buildroot" \

 Since you don't do any processing on the file, you could just use

		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \

and avoid copying the file around. Of course, in that case, support/cmake is
probably a better place to put the file :-)

 On the other hand, in the future we may want to add other stuff to the cmake
module path, and that stuff might get processed. I don't really like adding
complexity for some unknown future use, but it does make some kind of sense.

 If you do copy the file, it should IMHO go into STAGING_DIR, not HOST_DIR. I
think the location of toolchainfile.cmake is incorrect as well. We briefly
discussed this at some BR developer meeting IIRC but nobody took action on it.

 Regards,
 Arnout

>  		-DCMAKE_INSTALL_PREFIX="/usr" \
>  		-DCMAKE_COLOR_MAKEFILE=OFF \
>  		-DBUILD_DOC=OFF \
> @@ -249,3 +250,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
>  		-e 's#@@CMAKE_BUILD_TYPE@@#$(if $(BR2_ENABLE_DEBUG),Debug,Release)#' \
>  		$(TOPDIR)/support/misc/toolchainfile.cmake.in \
>  		> $@
> +
> +$(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake:
> +	$(Q)$(INSTALL) -D -m 0644 support/misc/Buildroot.cmake $(@)
> diff --git a/support/misc/Buildroot.cmake b/support/misc/Buildroot.cmake
> new file mode 100644
> index 0000000..b0046b3
> --- /dev/null
> +++ b/support/misc/Buildroot.cmake
> @@ -0,0 +1,3 @@
> +include(Platform/Linux)
> +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE)
> +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
> diff --git a/support/misc/toolchainfile.cmake.in b/support/misc/toolchainfile.cmake.in
> index d4252dd..5a42644 100644
> --- a/support/misc/toolchainfile.cmake.in
> +++ b/support/misc/toolchainfile.cmake.in
> @@ -10,7 +10,7 @@
>  # RELOCATED_HOST_DIR variable.
>  string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
>  
> -set(CMAKE_SYSTEM_NAME Linux)
> +set(CMAKE_SYSTEM_NAME Buildroot)
>  set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
>  
>  # Set the {C,CXX}FLAGS appended by CMake depending on the build type
> diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> index b16db01..e298373 100644
> --- a/toolchain/toolchain/toolchain.mk
> +++ b/toolchain/toolchain/toolchain.mk
> @@ -38,3 +38,4 @@ endif
>  $(eval $(virtual-package))
>  
>  toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
> +toolchain: $(HOST_DIR)/usr/share/buildroot/Platform/Buildroot.cmake
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7
  2017-03-01  7:49 ` [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Arnout Vandecappelle
@ 2017-03-01  7:59   ` Thomas Petazzoni
  0 siblings, 0 replies; 26+ messages in thread
From: Thomas Petazzoni @ 2017-03-01  7:59 UTC (permalink / raw)
  To: buildroot

Hello,

On Wed, 1 Mar 2017 08:49:47 +0100, Arnout Vandecappelle wrote:

>  I don't think it makes much sense to keep the 4 separate patches. The history
> shows the authorship of the original bump. Having the 4 separate patches just
> adds noise to the history. Also, Thomas reported that the libuv dependency
> introduced by the bump is probably incorrect, so we'd have to revert patch 4/5
> and part of patch 2/5 again later on... And if the dependency on libuv *is*
> needed, then you re-introduce a non-bisectable commit between patch 2/5 and 4/5.

Well, the libuv dependency is incorrect in the sense that ctest doesn't
seem to use libuv.

*However*, the libuv dependency is correct in the sense that the
CMakeLists.txt checks it, and if not, builds the cmake built-in version
of libuv. But since for the target we only build ctest, this whole
libuv is not used.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 20:58     ` Yann E. MORIN
  2017-02-28 22:15       ` Jörg Krause
@ 2017-03-01  8:01       ` Arnout Vandecappelle
  1 sibling, 0 replies; 26+ messages in thread
From: Arnout Vandecappelle @ 2017-03-01  8:01 UTC (permalink / raw)
  To: buildroot



On 28-02-17 21:58, Yann E. MORIN wrote:
> J?rg, All,
> 
> On 2017-02-28 21:41 +0100, J?rg Krause spake thusly:
>> On Tue, 2017-02-28 at 19:07 +0100, Yann E. MORIN wrote:
>>> The handling of RPATH in cmake-3.7 has changed drastically, causing a
>>> slew of build failures dues to libraries from the host being pulled
>>> in:
>>>
>>>   - domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7ab
>>> f973691b39a0ca1bb4e07d749593a/
>>>   - freerdp  : http://autobuild.buildroot.org/results/5d4/5d429d0e288
>>> 754a541ee5d8be515454c5fccd28b/
>>>   - libcec   : http://autobuild.buildroot.org/results/3f3/3f3593bab77
>>> 34dd274faf5b5690895e9424cbb89/
>>>   - and so on...
>>>
>>> The bug was reported upstream [0], which dismissed it altogether [1]
>>> as
>>> being expected behaviour, quoting:
>>>
>>>     I don't think there is anything wrong with that change on its
>>> own.
>>>     It merely exposed some existing behavior in a new case.
>>>
>>> Instead, upstream suggested in that same message that a platform
>>> definition be used instead, quoting:
>>>
>>>     If a toolchain file specifies CMAKE_SYSTEM_NAME such that a
>>> custom
>>>     `Platform/MySystem.cmake` file is loaded then the latter can set
>>>     them as needed for the target platform.
>>
>> Upstream has opened an issue [1] about this and is already working on a
>> fix [2] for version 3.7 and 3.8. It fixes the behavior of how
>> FIND_LIBRARY_USE_LIB32_PATHS handle symlinks. As 'lib32' is just just a
>> symlink to 'lib' in Buildroot, 'find_library()' will skip 'lib32' as a
>> runtime search path and as a consequence 'lib32' will not be used as
>> rpath anymore.
>>
>>> So here we are doing so:
>>>
>>>   - we add a new platfom definitions that inherits from the Linux
>>> one,
>>>     then overrides the problematic settings;
>>>
>>>   - we change our toolchain file to use that platform instead;
>>>
>>>   - we tell cmake where to find additional modules, so that it can
>>> find
>>>     our custom platform file.
>>
>> As the issue might be fixed at some point, do we want to keep the
>> custom platform file?
> 
> Well, what bad would it do to have our own platform file? We could even
> use it for yet more options if need be.
> 
> And in the meantime, there is no release of cmake with a fix. I'll
> believe they've fixed it when I see it! ;-)

 Also, we want to support existing distro CMake, which doesn't have this fix.

 Which reminds me: don't forget to revert
4422eca2d4 dependencies/cmake: blacklist cmake 3.7


 Regards,
 Arnout

[snip]
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-03-01  7:58   ` Arnout Vandecappelle
@ 2017-03-01  8:17     ` Thomas Petazzoni
  2017-03-01  8:35       ` Arnout Vandecappelle
  0 siblings, 1 reply; 26+ messages in thread
From: Thomas Petazzoni @ 2017-03-01  8:17 UTC (permalink / raw)
  To: buildroot

Hello,

On Wed, 1 Mar 2017 08:58:31 +0100, Arnout Vandecappelle wrote:

>  Since you don't do any processing on the file, you could just use
> 
> 		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \

I think the idea is that since the Buildroot.cmake platform files gets
referenced by the toolchainfile.cmake, then Buildroot.cmake anyway
needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can
just as well point CMake to this place.

> and avoid copying the file around. Of course, in that case, support/cmake is
> probably a better place to put the file :-)

No: copying the file is needed, otherwise our toolchainfile.cmake file
no longer works for people using it outside of Buildroot.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-03-01  8:17     ` Thomas Petazzoni
@ 2017-03-01  8:35       ` Arnout Vandecappelle
  2017-03-01 18:43         ` Yann E. MORIN
  0 siblings, 1 reply; 26+ messages in thread
From: Arnout Vandecappelle @ 2017-03-01  8:35 UTC (permalink / raw)
  To: buildroot



On 01-03-17 09:17, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 1 Mar 2017 08:58:31 +0100, Arnout Vandecappelle wrote:
> 
>>  Since you don't do any processing on the file, you could just use
>>
>> 		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
> 
> I think the idea is that since the Buildroot.cmake platform files gets
> referenced by the toolchainfile.cmake, then Buildroot.cmake anyway
> needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can
> just as well point CMake to this place.
> 
>> and avoid copying the file around. Of course, in that case, support/cmake is
>> probably a better place to put the file :-)
> 
> No: copying the file is needed, otherwise our toolchainfile.cmake file
> no longer works for people using it outside of Buildroot.

 Good point. I still think it should be in staging rather than host, but for
sure it's more important to keep them together.

 Therefore:

Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-03-01  8:35       ` Arnout Vandecappelle
@ 2017-03-01 18:43         ` Yann E. MORIN
  2017-03-05 23:27           ` Arnout Vandecappelle
  0 siblings, 1 reply; 26+ messages in thread
From: Yann E. MORIN @ 2017-03-01 18:43 UTC (permalink / raw)
  To: buildroot

Arnout, All,

On 2017-03-01 09:35 +0100, Arnout Vandecappelle spake thusly:
> On 01-03-17 09:17, Thomas Petazzoni wrote:
> > Hello,
> > 
> > On Wed, 1 Mar 2017 08:58:31 +0100, Arnout Vandecappelle wrote:
> > 
> >>  Since you don't do any processing on the file, you could just use
> >>
> >> 		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
> > 
> > I think the idea is that since the Buildroot.cmake platform files gets
> > referenced by the toolchainfile.cmake, then Buildroot.cmake anyway
> > needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can
> > just as well point CMake to this place.
> > 
> >> and avoid copying the file around. Of course, in that case, support/cmake is
> >> probably a better place to put the file :-)
> > 
> > No: copying the file is needed, otherwise our toolchainfile.cmake file
> > no longer works for people using it outside of Buildroot.
> 
>  Good point. I still think it should be in staging rather than host, but for
> sure it's more important to keep them together.

Why would you want it in staging? When we build our own internal cmake,
the moduels it installs are so installed in host, not staging. They are
build-description files, not target files.

Ergo, they should be in host, not staging.

Regards,
Yann E. MORIN.

>  Therefore:
> 
> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> 
>  Regards,
>  Arnout
> 
> -- 
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7
  2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
                   ` (5 preceding siblings ...)
  2017-03-01  7:49 ` [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Arnout Vandecappelle
@ 2017-03-01 21:14 ` Thomas Petazzoni
  2017-03-02  8:41   ` Thomas Petazzoni
  6 siblings, 1 reply; 26+ messages in thread
From: Thomas Petazzoni @ 2017-03-01 21:14 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 28 Feb 2017 19:07:23 +0100, Yann E. MORIN wrote:

> Thomas Petazzoni (1):
>       cmake: adjust dependencies added for libuv
> 
> Vicente Olivert Riera (3):
>       cmake: bump version to 3.7.0
>       cmake: bump version to 3.7.1
>       cmake: bump version to 3.7.2
> 
> Yann E. MORIN (1):
>       core/pkg-cmake: provide our own platform description

All applied to master. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7
  2017-03-01 21:14 ` Thomas Petazzoni
@ 2017-03-02  8:41   ` Thomas Petazzoni
  2017-03-02 17:39     ` Yann E. MORIN
  0 siblings, 1 reply; 26+ messages in thread
From: Thomas Petazzoni @ 2017-03-02  8:41 UTC (permalink / raw)
  To: buildroot

Hello,

On Wed, 1 Mar 2017 22:14:13 +0100, Thomas Petazzoni wrote:

> > Thomas Petazzoni (1):
> >       cmake: adjust dependencies added for libuv
> > 
> > Vicente Olivert Riera (3):
> >       cmake: bump version to 3.7.0
> >       cmake: bump version to 3.7.1
> >       cmake: bump version to 3.7.2
> > 
> > Yann E. MORIN (1):
> >       core/pkg-cmake: provide our own platform description  
> 
> All applied to master. Thanks!

Well, it seems like this introduced some issues.

Look for example at:

  http://autobuild.buildroot.net/?reason=paho-mqtt-c-v1.1.0

paho-mqtt-c builds fine at commit
9951d5c931c419a32d31cc2a67d3a5c388efbed6 (before the CMake changes),
but fails to build at commit 609df3acf644e97d0aa4a66db8998d93f8543f3b
(right after the CMake changes).

Here is a minimal defconfig to reproduce the problem:

BR2_arcle=y
BR2_archs38=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_PAHO_MQTT_C=y
# BR2_TARGET_ROOTFS_TAR is not set

The fastd problems could also be related, but I haven't checked, see
http://autobuild.buildroot.net/?reason=fastd-18.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
                     ` (2 preceding siblings ...)
  2017-03-01  7:58   ` Arnout Vandecappelle
@ 2017-03-02 12:29   ` Baruch Siach
  2017-03-02 12:41     ` Thomas Petazzoni
  3 siblings, 1 reply; 26+ messages in thread
From: Baruch Siach @ 2017-03-02 12:29 UTC (permalink / raw)
  To: buildroot

Hi Yann,

On Tue, Feb 28, 2017 at 07:07:22PM +0100, Yann E. MORIN wrote:
> -set(CMAKE_SYSTEM_NAME Linux)
> +set(CMAKE_SYSTEM_NAME Buildroot)
>  set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)

This breaks libiio.

http://autobuild.buildroot.net/results/281/2812b008a0ab6bab5fe4d45eb9ffe4e9496a8cb4/

/home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c: In function 'local_open':
/home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c:856:33: error: 'O_CLOEXEC' undeclared (first use in this function)

That is because the libiio CMakeLists.txt has the following code:

IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")

		[...]

        set(CMAKE_REQUIRED_DEFINITIONS "-D_GNU_SOURCE=1")
        add_definitions(-D_GNU_SOURCE=1)
endif()

Now cmake skips this code, thus omitting _GNU_SOURCE which leads to the build 
failure.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-03-02 12:29   ` Baruch Siach
@ 2017-03-02 12:41     ` Thomas Petazzoni
  0 siblings, 0 replies; 26+ messages in thread
From: Thomas Petazzoni @ 2017-03-02 12:41 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu, 2 Mar 2017 14:29:40 +0200, Baruch Siach wrote:

> On Tue, Feb 28, 2017 at 07:07:22PM +0100, Yann E. MORIN wrote:
> > -set(CMAKE_SYSTEM_NAME Linux)
> > +set(CMAKE_SYSTEM_NAME Buildroot)
> >  set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)  
> 
> This breaks libiio.
> 
> http://autobuild.buildroot.net/results/281/2812b008a0ab6bab5fe4d45eb9ffe4e9496a8cb4/
> 
> /home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c: In function 'local_open':
> /home/dawncrow/buildroot-test/scripts/instance-0/output/build/libiio-0.9/local.c:856:33: error: 'O_CLOEXEC' undeclared (first use in this function)
> 
> That is because the libiio CMakeLists.txt has the following code:
> 
> IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
> 
> 		[...]
> 
>         set(CMAKE_REQUIRED_DEFINITIONS "-D_GNU_SOURCE=1")
>         add_definitions(-D_GNU_SOURCE=1)
> endif()
> 
> Now cmake skips this code, thus omitting _GNU_SOURCE which leads to the build 
> failure.

As I reported earlier today, this series breaks several other CMake
based packages. So I guess, we're good for yet another revert, back to
CMake 3.6.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7
  2017-03-02  8:41   ` Thomas Petazzoni
@ 2017-03-02 17:39     ` Yann E. MORIN
  0 siblings, 0 replies; 26+ messages in thread
From: Yann E. MORIN @ 2017-03-02 17:39 UTC (permalink / raw)
  To: buildroot

Thomas, All,

On 2017-03-02 09:41 +0100, Thomas Petazzoni spake thusly:
> On Wed, 1 Mar 2017 22:14:13 +0100, Thomas Petazzoni wrote:
> 
> > > Thomas Petazzoni (1):
> > >       cmake: adjust dependencies added for libuv
> > > 
> > > Vicente Olivert Riera (3):
> > >       cmake: bump version to 3.7.0
> > >       cmake: bump version to 3.7.1
> > >       cmake: bump version to 3.7.2
> > > 
> > > Yann E. MORIN (1):
> > >       core/pkg-cmake: provide our own platform description  
> > 
> > All applied to master. Thanks!
> 
> Well, it seems like this introduced some issues.
> 
> Look for example at:
> 
>   http://autobuild.buildroot.net/?reason=paho-mqtt-c-v1.1.0

This package is wrong: it checks the system type to decide whether it
should link with -ldld or not:

    https://github.com/eclipse/paho.mqtt.c/blob/master/src/CMakeLists.txt#L50

This is stupid.

Instead, it should check if the lib is needed or not, and available or
mot, like any other lib, and then decide to fail or deactivate features.

> The fastd problems could also be related, but I haven't checked, see
> http://autobuild.buildroot.net/?reason=fastd-18.

Similarly broken:

    https://git.universe-factory.net/fastd/tree/cmake/config.cmake#n1
    https://git.universe-factory.net/fastd/tree/cmake/config.cmake#n14


I'll try a hack on it, by adding:

    # Impersonate the Linux system, which we really are in fact...
    set(CMAKE_SYSTEM_NAME Linux)

in Buildroot.cmake and see if that fixes the build....

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-03-01 18:43         ` Yann E. MORIN
@ 2017-03-05 23:27           ` Arnout Vandecappelle
  2017-03-06 17:00             ` Yann E. MORIN
  0 siblings, 1 reply; 26+ messages in thread
From: Arnout Vandecappelle @ 2017-03-05 23:27 UTC (permalink / raw)
  To: buildroot



On 01-03-17 19:43, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2017-03-01 09:35 +0100, Arnout Vandecappelle spake thusly:
>> On 01-03-17 09:17, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> On Wed, 1 Mar 2017 08:58:31 +0100, Arnout Vandecappelle wrote:
>>>
>>>>  Since you don't do any processing on the file, you could just use
>>>>
>>>> 		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
>>>
>>> I think the idea is that since the Buildroot.cmake platform files gets
>>> referenced by the toolchainfile.cmake, then Buildroot.cmake anyway
>>> needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can
>>> just as well point CMake to this place.
>>>
>>>> and avoid copying the file around. Of course, in that case, support/cmake is
>>>> probably a better place to put the file :-)
>>>
>>> No: copying the file is needed, otherwise our toolchainfile.cmake file
>>> no longer works for people using it outside of Buildroot.
>>
>>  Good point. I still think it should be in staging rather than host, but for
>> sure it's more important to keep them together.
> 
> Why would you want it in staging? When we build our own internal cmake,
> the moduels it installs are so installed in host, not staging. They are
> build-description files, not target files.
> 
> Ergo, they should be in host, not staging.

 I was looking at it like the .pc files, which are in staging because they talk
about the target.

 About the modules: in fact, packages that install .cmake files will do that in
staging, not in host. So I do hope that cmake looks for them in staging as
well... That's what CMAKE_FIND_ROOT_PATH is for, isn't it?

 In fact, the only .cmake files I see installed in the host dir are:

- the Modules from CMake itself, but these are more related to the CMake
language, e.g. CheckIncludeFiles.cmake;

- the CMake files added by *host* packages;

- the CMake files added by buildroot which talk about *target* packages.

 So I stand by my original statement: I think the cmake files should move from
HOST/usr/share/buildroot to STAGING/usr/lib/cmake.

 Adding Samuel and Luca, our CMake "experts", to Cc.

 Regards,
 Arnout


> 
> Regards,
> Yann E. MORIN.
> 
>>  Therefore:
>>
>> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>>
>>  Regards,
>>  Arnout
>>
>> -- 
>> Arnout Vandecappelle                          arnout at mind be
>> Senior Embedded Software Architect            +32-16-286500
>> Essensium/Mind                                http://www.mind.be
>> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
>> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-03-05 23:27           ` Arnout Vandecappelle
@ 2017-03-06 17:00             ` Yann E. MORIN
  2017-03-06 22:02               ` Arnout Vandecappelle
  0 siblings, 1 reply; 26+ messages in thread
From: Yann E. MORIN @ 2017-03-06 17:00 UTC (permalink / raw)
  To: buildroot

Arnout, All,

On 2017-03-06 00:27 +0100, Arnout Vandecappelle spake thusly:
> On 01-03-17 19:43, Yann E. MORIN wrote:
> > Arnout, All,
> > 
> > On 2017-03-01 09:35 +0100, Arnout Vandecappelle spake thusly:
> >> On 01-03-17 09:17, Thomas Petazzoni wrote:
> >>> Hello,
> >>>
> >>> On Wed, 1 Mar 2017 08:58:31 +0100, Arnout Vandecappelle wrote:
> >>>
> >>>>  Since you don't do any processing on the file, you could just use
> >>>>
> >>>> 		-DCMAKE_MODULE_PATH="$$(TOPDIR)/support/misc" \
> >>>
> >>> I think the idea is that since the Buildroot.cmake platform files gets
> >>> referenced by the toolchainfile.cmake, then Buildroot.cmake anyway
> >>> needs to be installed in $(HOST_DIR)/usr/share/buildroot, so we can
> >>> just as well point CMake to this place.
> >>>
> >>>> and avoid copying the file around. Of course, in that case, support/cmake is
> >>>> probably a better place to put the file :-)
> >>>
> >>> No: copying the file is needed, otherwise our toolchainfile.cmake file
> >>> no longer works for people using it outside of Buildroot.
> >>
> >>  Good point. I still think it should be in staging rather than host, but for
> >> sure it's more important to keep them together.
> > 
> > Why would you want it in staging? When we build our own internal cmake,
> > the moduels it installs are so installed in host, not staging. They are
> > build-description files, not target files.
> > 
> > Ergo, they should be in host, not staging.
> 
>  I was looking at it like the .pc files, which are in staging because they talk
> about the target.

But it is not like a .pc file.  It does not describe libs to link with
(-l), or where to lok for headers and libs (-I and -L).

It is more like the toolchain file itself; but see below...

>  About the modules: in fact, packages that install .cmake files will do that in
> staging, not in host. So I do hope that cmake looks for them in staging as
> well... That's what CMAKE_FIND_ROOT_PATH is for, isn't it?
> 
>  In fact, the only .cmake files I see installed in the host dir are:
> 
> - the Modules from CMake itself, but these are more related to the CMake
> language, e.g. CheckIncludeFiles.cmake;

And what about all the modules describing platforms:

    host/usr/share/cmake-3.7/Modules/Platform/

and the file that actually sources the platform description:

    host/usr/share/cmake-3.7/Modules/CMakeSystemSpecificInformation.cmake

> - the CMake files added by *host* packages;
> 
> - the CMake files added by buildroot which talk about *target* packages.
> 
>  So I stand by my original statement: I think the cmake files should move from
> HOST/usr/share/buildroot to STAGING/usr/lib/cmake.

Still not convinced... ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description
  2017-03-06 17:00             ` Yann E. MORIN
@ 2017-03-06 22:02               ` Arnout Vandecappelle
  0 siblings, 0 replies; 26+ messages in thread
From: Arnout Vandecappelle @ 2017-03-06 22:02 UTC (permalink / raw)
  To: buildroot



On 06-03-17 18:00, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2017-03-06 00:27 +0100, Arnout Vandecappelle spake thusly:
>> On 01-03-17 19:43, Yann E. MORIN wrote:
[snip]
>>> Why would you want it in staging? When we build our own internal cmake,
>>> the moduels it installs are so installed in host, not staging. They are
>>> build-description files, not target files.
>>>
>>> Ergo, they should be in host, not staging.
>>
>>  I was looking at it like the .pc files, which are in staging because they talk
>> about the target.
> 
> But it is not like a .pc file.  It does not describe libs to link with
> (-l), or where to lok for headers and libs (-I and -L).

 How is the specification of the sysroot different from the path to headers and
libs?


> It is more like the toolchain file itself; but see below...

 If with the toolchain file you mean toolchainfile.cmake, that's exactly my
point: I think toolchainfile.cmake should be in staging.


>>  About the modules: in fact, packages that install .cmake files will do that in
>> staging, not in host. So I do hope that cmake looks for them in staging as
>> well... That's what CMAKE_FIND_ROOT_PATH is for, isn't it?
>>
>>  In fact, the only .cmake files I see installed in the host dir are:
>>
>> - the Modules from CMake itself, but these are more related to the CMake
>> language, e.g. CheckIncludeFiles.cmake;
> 
> And what about all the modules describing platforms:
> 
>     host/usr/share/cmake-3.7/Modules/Platform/

 They are not directly related to the target. They contain all the possible
platforms.


> and the file that actually sources the platform description:
> 
>     host/usr/share/cmake-3.7/Modules/CMakeSystemSpecificInformation.cmake

 Note that there is nothing system specific in this file :-)

 Anyway, enough bikeshedding, let's just keep things as they are.

 Regards,
 Arnout

> 
>> - the CMake files added by *host* packages;
>>
>> - the CMake files added by buildroot which talk about *target* packages.
>>
>>  So I stand by my original statement: I think the cmake files should move from
>> HOST/usr/share/buildroot to STAGING/usr/lib/cmake.
> 
> Still not convinced... ;-)
> 
> Regards,
> Yann E. MORIN.
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2017-03-06 22:02 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-28 18:07 [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Yann E. MORIN
2017-02-28 18:07 ` [Buildroot] [PATCH 1/5] core/pkg-cmake: provide our own platform description Yann E. MORIN
2017-02-28 18:26   ` Baruch Siach
2017-02-28 20:03     ` Yann E. MORIN
2017-02-28 20:41   ` Jörg Krause
2017-02-28 20:58     ` Yann E. MORIN
2017-02-28 22:15       ` Jörg Krause
2017-03-01  8:01       ` Arnout Vandecappelle
2017-03-01  7:58   ` Arnout Vandecappelle
2017-03-01  8:17     ` Thomas Petazzoni
2017-03-01  8:35       ` Arnout Vandecappelle
2017-03-01 18:43         ` Yann E. MORIN
2017-03-05 23:27           ` Arnout Vandecappelle
2017-03-06 17:00             ` Yann E. MORIN
2017-03-06 22:02               ` Arnout Vandecappelle
2017-03-02 12:29   ` Baruch Siach
2017-03-02 12:41     ` Thomas Petazzoni
2017-02-28 18:07 ` [Buildroot] [PATCH 2/5] cmake: bump version to 3.7.0 Yann E. MORIN
2017-02-28 18:07 ` [Buildroot] [PATCH 3/5] cmake: bump version to 3.7.1 Yann E. MORIN
2017-02-28 18:07 ` [Buildroot] [PATCH 4/5] cmake: adjust dependencies added for libuv Yann E. MORIN
2017-02-28 18:07 ` [Buildroot] [PATCH 5/5] cmake: bump version to 3.7.2 Yann E. MORIN
2017-03-01  7:49 ` [Buildroot] [PATCH 0/5] package/cmake: re-introduce cmake-3.7 Arnout Vandecappelle
2017-03-01  7:59   ` Thomas Petazzoni
2017-03-01 21:14 ` Thomas Petazzoni
2017-03-02  8:41   ` Thomas Petazzoni
2017-03-02 17:39     ` Yann E. MORIN

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.