[Buildroot] [PATCH 0/4] Introducing CMAKETARGETS infrastructure

[Buildroot] [PATCH 0/4] Introducing CMAKETARGETS infrastructure

[Bjørn Forsman]

This patch series adds a new infrastructure for CMake packages called
CMAKETARGETS. It is based on the AUTOTARGETS infrastructure.

Comments and feedback welcome.

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Bjørn Forsman]

The CMAKETARGETS infrastructure makes adding CMake-based packages to
Buildroot easy. It uses the same set of variables as the autotools
infrastructure does, except for autoreconf and libtool stuff which is
not needed. Usage: just call CMAKETARGETS instead of AUTOTARGETS.

Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
---
 package/Makefile.cmake.in |  216 +++++++++++++++++++++++++++++++++++++++++++++
 package/Makefile.in       |    1 +
 2 files changed, 217 insertions(+), 0 deletions(-)
 create mode 100644 package/Makefile.cmake.in

diff --git a/package/Makefile.cmake.in b/package/Makefile.cmake.in
new file mode 100644
index 0000000..133876a
--- /dev/null
+++ b/package/Makefile.cmake.in
@@ -0,0 +1,216 @@
+################################################################################
+# CMake package infrastructure
+#
+# This file implements an infrastructure that eases development of
+# package .mk files for CMake packages. It should be used for all
+# packages that use CMake as their build system.
+#
+# See the Buildroot documentation for details on the usage of this
+# infrastructure
+#
+# In terms of implementation, this CMake infrastructure requires
+# the .mk file to only specify metadata informations about the
+# package: name, version, download URL, etc.
+#
+# We still allow the package .mk file to override what the different
+# steps are doing, if needed. For example, if <PKG>_BUILD_CMDS is
+# already defined, it is used as the list of commands to perform to
+# build the package, instead of the default CMake behaviour. The
+# package can also define some post operation hooks.
+#
+################################################################################
+
+################################################################################
+# CMAKETARGETS_INNER -- defines how the configuration, compilation and
+# installation of a CMake package should be done, implements a few hooks to
+# tune the build process and calls the generic package infrastructure to
+# generate the necessary make targets
+#
+#  argument 1 is the lowercase package name
+#  argument 2 is the uppercase package name, including an HOST_ prefix
+#             for host packages
+#  argument 3 is the uppercase package name, without the HOST_ prefix
+#             for host packages
+#  argument 4 is the package directory prefix
+#  argument 5 is the type (target or host)
+################################################################################
+
+define CMAKETARGETS_INNER
+
+# define package-specific variables to default values
+ifndef $(2)_SUBDIR
+ ifdef $(3)_SUBDIR
+  $(2)_SUBDIR = $($(3)_SUBDIR)
+ else
+  $(2)_SUBDIR ?=
+ endif
+endif
+
+$(2)_CONF_ENV			?=
+$(2)_CONF_OPT			?=
+$(2)_MAKE			?= $(MAKE)
+$(2)_MAKE_ENV			?=
+$(2)_MAKE_OPT			?=
+$(2)_INSTALL_HOST_OPT		?= DESTDIR=$$(HOST_DIR) install
+$(2)_INSTALL_STAGING_OPT	?= DESTDIR=$$(STAGING_DIR) install
+$(2)_INSTALL_TARGET_OPT		?= DESTDIR=$$(TARGET_DIR) install
+$(2)_CLEAN_OPT			?= clean
+
+$(2)_SRCDIR			= $$($(2)_DIR)/$($(2)_SUBDIR)
+
+
+# CMake doesn't support having the --sysroot option directly in the
+# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
+CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
+CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
+CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
+CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX)) $(TARGET_CXXFLAGS)
+
+#
+# Configure step. Only define it if not already defined by the package
+# .mk file. And take care of the differences between host and target
+# packages.
+#
+ifndef $(2)_CONFIGURE_CMDS
+ifeq ($(5),target)
+
+# Configure package for target
+define $(2)_CONFIGURE_CMDS
+	(cd $$($$(PKG)_SRCDIR) && \
+	rm -f CMakeCache.txt && \
+	$$($$(PKG)_CONF_ENV) $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
+		-Wno-dev \
+		-DCMAKE_SYSTEM_NAME:STRING="Linux" \
+		-DCMAKE_C_COMPILER:FILEPATH="$$(CMAKE_TARGET_CC)" \
+		-DCMAKE_CXX_COMPILER:FILEPATH="$$(CMAKE_TARGET_CXX)" \
+		-DCMAKE_C_FLAGS:STRING="$$(CMAKE_TARGET_CFLAGS)" \
+		-DCMAKE_CXX_FLAGS:STRING="$$(CMAKE_TARGET_CXXFLAGS)" \
+		-DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
+		-DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
+		-DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
+		-DCMAKE_FIND_ROOT_PATH:PATH="$$(STAGING_DIR)" \
+		-DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM:STRING="NEVER" \
+		-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING="ONLY" \
+		-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE:STRING="ONLY" \
+		-DCMAKE_INSTALL_PREFIX:PATH="/usr" \
+		$$($$(PKG)_CONF_OPT) \
+	)
+endef
+else
+
+# Configure package for host
+define $(2)_CONFIGURE_CMDS
+	(cd $$($$(PKG)_SRCDIR) && \
+	rm -f CMakeCache.txt && \
+	$(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
+		-Wno-dev \
+		-DCMAKE_C_FLAGS="$$(HOST_CFLAGS)" \
+		-DCMAKE_EXE_LINKER_FLAGS:STRING="$$(HOST_LDFLAGS)" \
+		-DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(HOST_LDFLAGS)" \
+		-DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(HOST_LDFLAGS)" \
+		-DCMAKE_INSTALL_PREFIX:STRING="/usr" \
+		$$($$(PKG)_CONF_OPT) \
+	)
+endef
+endif
+endif
+
+$(2)_DEPENDENCIES += host-cmake
+
+#
+# Build step. Only define it if not already defined by the package .mk
+# file.
+#
+ifndef $(2)_BUILD_CMDS
+ifeq ($(5),target)
+define $(2)_BUILD_CMDS
+	$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_MAKE_OPT) -C $$($$(PKG)_SRCDIR)
+endef
+else
+define $(2)_BUILD_CMDS
+	$(HOST_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_MAKE_OPT) -C $$($$(PKG)_SRCDIR)
+endef
+endif
+endif
+
+#
+# Host installation step. Only define it if not already defined by the
+# package .mk file.
+#
+ifndef $(2)_INSTALL_CMDS
+define $(2)_INSTALL_CMDS
+	$(HOST_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_MAKE_OPT) $$($$(PKG)_INSTALL_HOST_OPT) -C $$($$(PKG)_SRCDIR)
+endef
+endif
+
+#
+# Staging installation step. Only define it if not already defined by
+# the package .mk file.
+#
+ifndef $(2)_INSTALL_STAGING_CMDS
+define $(2)_INSTALL_STAGING_CMDS
+	$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_MAKE_OPT) $$($$(PKG)_INSTALL_STAGING_OPT) -C $$($$(PKG)_SRCDIR)
+endef
+endif
+
+#
+# Target installation step. Only define it if not already defined by
+# the package .mk file.
+#
+ifndef $(2)_INSTALL_TARGET_CMDS
+define $(2)_INSTALL_TARGET_CMDS
+	$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_MAKE_OPT) $$($$(PKG)_INSTALL_TARGET_OPT) -C $$($$(PKG)_SRCDIR)
+endef
+endif
+
+#
+# Clean step. Only define it if not already defined by
+# the package .mk file.
+#
+ifndef $(2)_CLEAN_CMDS
+define $(2)_CLEAN_CMDS
+	-$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)  $$($$(PKG)_CLEAN_OPT) -C $$($$(PKG)_SRCDIR)
+endef
+endif
+
+#
+# Uninstall from staging step. Only define it if not already defined by
+# the package .mk file.
+#
+ifndef $(2)_UNINSTALL_STAGING_CMDS
+define $(2)_UNINSTALL_STAGING_CMDS
+	(cd $$($$(PKG)_SRCDIR) && sed "s:\(.*\):$$(STAGING_DIR)\1:" install_manifest.txt | xargs rm -f)
+endef
+endif
+
+#
+# Uninstall from target step. Only define it if not already defined
+# by the package .mk file.
+#
+ifndef $(2)_UNINSTALL_TARGET_CMDS
+define $(2)_UNINSTALL_TARGET_CMDS
+	(cd $$($$(PKG)_SRCDIR) && sed "s:\(.*\):$$(TARGET_DIR)\1:" install_manifest.txt | xargs rm -f)
+endef
+endif
+
+# Call the generic package infrastructure to generate the necessary
+# make targets
+$(call GENTARGETS_INNER,$(1),$(2),$(3),$(4),$(5))
+
+endef
+
+################################################################################
+# CMAKETARGETS -- the target generator macro for CMake packages
+#
+# Argument 1 is the package directory prefix [mandatory]
+# Argument 2 is the lowercase package name   [mandatory]
+# Argument 3 is "target" or "host"           [optional, default: "target"]
+################################################################################
+
+define CMAKETARGETS
+ifeq ($(3),host)
+$(call CMAKETARGETS_INNER,$(3)-$(2),$(call UPPERCASE,$(3)-$(2)),$(call UPPERCASE,$(2)),$(1),host)
+else
+$(call CMAKETARGETS_INNER,$(2),$(call UPPERCASE,$(2)),$(call UPPERCASE,$(2)),$(1),target)
+endif
+endef
diff --git a/package/Makefile.in b/package/Makefile.in
index d448a7e..a7650f0 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -318,4 +318,5 @@ ENABLE_DEBUG:=
 endif
 
 include package/Makefile.autotools.in
+include package/Makefile.cmake.in
 include package/Makefile.package.in
-- 
1.7.1

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Samuel Martin]

Hi Bj?rn,

Thanks for submitting these patches that join some of my works, especially
about generating a cmake-toolchain file. You beat me to the punch ;)

Details:

+# CMake doesn't support having the --sysroot option directly in the

+# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.

+CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))

+CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))

+CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)

+CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX))
> $(TARGET_CXXFLAGS)

I think it is not necessary to add the --sysroot option to any of these
flags if we correctly define the CMake toolchain file (cf. patch review
of [PATCH 3/4])


+# Configure package for target

+define $(2)_CONFIGURE_CMDS

+       (cd $$($$(PKG)_SRCDIR) && \

You configure and build in the source tree, why not.. but CMake
supports (i'd like to say: it's designed to) build out of source tree (and
it messes up a bite the build tree...).

+       rm -f CMakeCache.txt && \

+       $$($$(PKG)_CONF_ENV) $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \

+               -Wno-dev \

+               -DCMAKE_SYSTEM_NAME:STRING="Linux" \

+               -DCMAKE_C_COMPILER:FILEPATH="$$(CMAKE_TARGET_CC)" \

+               -DCMAKE_CXX_COMPILER:FILEPATH="$$(CMAKE_TARGET_CXX)" \

+               -DCMAKE_C_FLAGS:STRING="$$(CMAKE_TARGET_CFLAGS)" \

+               -DCMAKE_CXX_FLAGS:STRING="$$(CMAKE_TARGET_CXXFLAGS)" \

+               -DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \

+               -DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \

+               -DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \

+               -DCMAKE_FIND_ROOT_PATH:PATH="$$(STAGING_DIR)" \

+               -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM:STRING="NEVER" \

+               -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING="ONLY" \

+               -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE:STRING="ONLY" \

Why don't you use the -DCMAKE_TOOLCHAIN_FILE <cmake-toolchain-file> here
instead of all these -D... ?


> +               -DCMAKE_INSTALL_PREFIX:PATH="/usr" \

+               $$($$(PKG)_CONF_OPT) \

+       )

+endef




Regards,

Samuel


2010/12/12 Bj?rn Forsman <bjorn.forsman@gmail.com>

> The CMAKETARGETS infrastructure makes adding CMake-based packages to
> Buildroot easy. It uses the same set of variables as the autotools
> infrastructure does, except for autoreconf and libtool stuff which is
> not needed. Usage: just call CMAKETARGETS instead of AUTOTARGETS.
>
> Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
> ---
>  package/Makefile.cmake.in |  216
> +++++++++++++++++++++++++++++++++++++++++++++
>  package/Makefile.in       |    1 +
>  2 files changed, 217 insertions(+), 0 deletions(-)
>  create mode 100644 package/Makefile.cmake.in
>
> diff --git a/package/Makefile.cmake.in b/package/Makefile.cmake.in
> new file mode 100644
> index 0000000..133876a
> --- /dev/null
> +++ b/package/Makefile.cmake.in
> @@ -0,0 +1,216 @@
>
> +################################################################################
> +# CMake package infrastructure
> +#
> +# This file implements an infrastructure that eases development of
> +# package .mk files for CMake packages. It should be used for all
> +# packages that use CMake as their build system.
> +#
> +# See the Buildroot documentation for details on the usage of this
> +# infrastructure
> +#
> +# In terms of implementation, this CMake infrastructure requires
> +# the .mk file to only specify metadata informations about the
> +# package: name, version, download URL, etc.
> +#
> +# We still allow the package .mk file to override what the different
> +# steps are doing, if needed. For example, if <PKG>_BUILD_CMDS is
> +# already defined, it is used as the list of commands to perform to
> +# build the package, instead of the default CMake behaviour. The
> +# package can also define some post operation hooks.
> +#
>
> +################################################################################
> +
>
> +################################################################################
> +# CMAKETARGETS_INNER -- defines how the configuration, compilation and
> +# installation of a CMake package should be done, implements a few hooks
> to
> +# tune the build process and calls the generic package infrastructure to
> +# generate the necessary make targets
> +#
> +#  argument 1 is the lowercase package name
> +#  argument 2 is the uppercase package name, including an HOST_ prefix
> +#             for host packages
> +#  argument 3 is the uppercase package name, without the HOST_ prefix
> +#             for host packages
> +#  argument 4 is the package directory prefix
> +#  argument 5 is the type (target or host)
>
> +################################################################################
> +
> +define CMAKETARGETS_INNER
> +
> +# define package-specific variables to default values
> +ifndef $(2)_SUBDIR
> + ifdef $(3)_SUBDIR
> +  $(2)_SUBDIR = $($(3)_SUBDIR)
> + else
> +  $(2)_SUBDIR ?=
> + endif
> +endif
> +
> +$(2)_CONF_ENV                  ?=
> +$(2)_CONF_OPT                  ?=
> +$(2)_MAKE                      ?= $(MAKE)
> +$(2)_MAKE_ENV                  ?=
> +$(2)_MAKE_OPT                  ?=
> +$(2)_INSTALL_HOST_OPT          ?= DESTDIR=$$(HOST_DIR) install
> +$(2)_INSTALL_STAGING_OPT       ?= DESTDIR=$$(STAGING_DIR) install
> +$(2)_INSTALL_TARGET_OPT                ?= DESTDIR=$$(TARGET_DIR) install
> +$(2)_CLEAN_OPT                 ?= clean
> +
> +$(2)_SRCDIR                    = $$($(2)_DIR)/$($(2)_SUBDIR)
> +
> +
> +# CMake doesn't support having the --sysroot option directly in the
> +# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
> +CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
> +CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
> +CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
> +CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX))
> $(TARGET_CXXFLAGS)
> +
> +#
> +# Configure step. Only define it if not already defined by the package
> +# .mk file. And take care of the differences between host and target
> +# packages.
> +#
> +ifndef $(2)_CONFIGURE_CMDS
> +ifeq ($(5),target)
> +
> +# Configure package for target
> +define $(2)_CONFIGURE_CMDS
> +       (cd $$($$(PKG)_SRCDIR) && \
> +       rm -f CMakeCache.txt && \
> +       $$($$(PKG)_CONF_ENV) $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
> +               -Wno-dev \
> +               -DCMAKE_SYSTEM_NAME:STRING="Linux" \
> +               -DCMAKE_C_COMPILER:FILEPATH="$$(CMAKE_TARGET_CC)" \
> +               -DCMAKE_CXX_COMPILER:FILEPATH="$$(CMAKE_TARGET_CXX)" \
> +               -DCMAKE_C_FLAGS:STRING="$$(CMAKE_TARGET_CFLAGS)" \
> +               -DCMAKE_CXX_FLAGS:STRING="$$(CMAKE_TARGET_CXXFLAGS)" \
> +               -DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
> +               -DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
> +               -DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
> +               -DCMAKE_FIND_ROOT_PATH:PATH="$$(STAGING_DIR)" \
> +               -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM:STRING="NEVER" \
> +               -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING="ONLY" \
> +               -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE:STRING="ONLY" \
> +               -DCMAKE_INSTALL_PREFIX:PATH="/usr" \
> +               $$($$(PKG)_CONF_OPT) \
> +       )
> +endef
> +else
> +
> +# Configure package for host
> +define $(2)_CONFIGURE_CMDS
> +       (cd $$($$(PKG)_SRCDIR) && \
> +       rm -f CMakeCache.txt && \
> +       $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
> +               -Wno-dev \
> +               -DCMAKE_C_FLAGS="$$(HOST_CFLAGS)" \
> +               -DCMAKE_EXE_LINKER_FLAGS:STRING="$$(HOST_LDFLAGS)" \
> +               -DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(HOST_LDFLAGS)" \
> +               -DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(HOST_LDFLAGS)" \
> +               -DCMAKE_INSTALL_PREFIX:STRING="/usr" \
> +               $$($$(PKG)_CONF_OPT) \
> +       )
> +endef
> +endif
> +endif
> +
> +$(2)_DEPENDENCIES += host-cmake
> +
> +#
> +# Build step. Only define it if not already defined by the package .mk
> +# file.
> +#
> +ifndef $(2)_BUILD_CMDS
> +ifeq ($(5),target)
> +define $(2)_BUILD_CMDS
> +       $(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
> $$($$(PKG)_MAKE_OPT) -C $$($$(PKG)_SRCDIR)
> +endef
> +else
> +define $(2)_BUILD_CMDS
> +       $(HOST_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
> $$($$(PKG)_MAKE_OPT) -C $$($$(PKG)_SRCDIR)
> +endef
> +endif
> +endif
> +
> +#
> +# Host installation step. Only define it if not already defined by the
> +# package .mk file.
> +#
> +ifndef $(2)_INSTALL_CMDS
> +define $(2)_INSTALL_CMDS
> +       $(HOST_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
> $$($$(PKG)_MAKE_OPT) $$($$(PKG)_INSTALL_HOST_OPT) -C $$($$(PKG)_SRCDIR)
> +endef
> +endif
> +
> +#
> +# Staging installation step. Only define it if not already defined by
> +# the package .mk file.
> +#
> +ifndef $(2)_INSTALL_STAGING_CMDS
> +define $(2)_INSTALL_STAGING_CMDS
> +       $(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
> $$($$(PKG)_MAKE_OPT) $$($$(PKG)_INSTALL_STAGING_OPT) -C $$($$(PKG)_SRCDIR)
> +endef
> +endif
> +
> +#
> +# Target installation step. Only define it if not already defined by
> +# the package .mk file.
> +#
> +ifndef $(2)_INSTALL_TARGET_CMDS
> +define $(2)_INSTALL_TARGET_CMDS
> +       $(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
> $$($$(PKG)_MAKE_OPT) $$($$(PKG)_INSTALL_TARGET_OPT) -C $$($$(PKG)_SRCDIR)
> +endef
> +endif
> +
> +#
> +# Clean step. Only define it if not already defined by
> +# the package .mk file.
> +#
> +ifndef $(2)_CLEAN_CMDS
> +define $(2)_CLEAN_CMDS
> +       -$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
>  $$($$(PKG)_CLEAN_OPT) -C $$($$(PKG)_SRCDIR)
> +endef
> +endif
> +
> +#
> +# Uninstall from staging step. Only define it if not already defined by
> +# the package .mk file.
> +#
> +ifndef $(2)_UNINSTALL_STAGING_CMDS
> +define $(2)_UNINSTALL_STAGING_CMDS
> +       (cd $$($$(PKG)_SRCDIR) && sed "s:\(.*\):$$(STAGING_DIR)\1:"
> install_manifest.txt | xargs rm -f)
> +endef
> +endif
> +
> +#
> +# Uninstall from target step. Only define it if not already defined
> +# by the package .mk file.
> +#
> +ifndef $(2)_UNINSTALL_TARGET_CMDS
> +define $(2)_UNINSTALL_TARGET_CMDS
> +       (cd $$($$(PKG)_SRCDIR) && sed "s:\(.*\):$$(TARGET_DIR)\1:"
> install_manifest.txt | xargs rm -f)
> +endef
> +endif
> +
> +# Call the generic package infrastructure to generate the necessary
> +# make targets
> +$(call GENTARGETS_INNER,$(1),$(2),$(3),$(4),$(5))
> +
> +endef
> +
>
> +################################################################################
> +# CMAKETARGETS -- the target generator macro for CMake packages
> +#
> +# Argument 1 is the package directory prefix [mandatory]
> +# Argument 2 is the lowercase package name   [mandatory]
> +# Argument 3 is "target" or "host"           [optional, default: "target"]
>
> +################################################################################
> +
> +define CMAKETARGETS
> +ifeq ($(3),host)
> +$(call CMAKETARGETS_INNER,$(3)-$(2),$(call UPPERCASE,$(3)-$(2)),$(call
> UPPERCASE,$(2)),$(1),host)
> +else
> +$(call CMAKETARGETS_INNER,$(2),$(call UPPERCASE,$(2)),$(call
> UPPERCASE,$(2)),$(1),target)
> +endif
> +endef
> diff --git a/package/Makefile.in b/package/Makefile.in
> index d448a7e..a7650f0 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -318,4 +318,5 @@ ENABLE_DEBUG:=
>  endif
>
>  include package/Makefile.autotools.in
> +include package/Makefile.cmake.in
>  include package/Makefile.package.in
> --
> 1.7.1
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101213/b5473b4b/attachment-0001.html>

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Bjørn Forsman]

Hi Samuel,

2010/12/13 Samuel Martin <s.martin49@gmail.com>:
> Hi?Bj?rn,
> Thanks for submitting these patches that join some of my works, especially
> about generating a cmake-toolchain file. You?beat me to the punch ;)
> Details:
>>
>> +# CMake doesn't support having the --sysroot option directly in the
>>
>> +# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
>>
>> +CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
>>
>> +CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
>>
>> +CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
>>
>> +CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX))
>> $(TARGET_CXXFLAGS)
>
> I think it is not necessary to add the --sysroot option to any of these
> flags if we correctly define the CMake toolchain file (cf. patch review
> of?[PATCH 3/4])

I guess you're right.

>> +# Configure package for target
>>
>> +define $(2)_CONFIGURE_CMDS
>>
>> + ? ? ? (cd $$($$(PKG)_SRCDIR) && \
>
> You configure and build in the source tree, why not.. but CMake
> supports?(i'd like to say: it's designed to)?build?out of source tree (and
> it messes up a bite the build tree...).

I agree, it's a bit messy. But where to but the build tree? Inside the
srctree or in a directory at the same level? I guess I would prefer the
latter, something like

srctree:
  output/build/cdrkit-1.1.10

buildtree:
  output/build/cdrkit-1.1.10.build

But as the autotools infrastructure does (AFAIK) buildtree == srctree, I
just did the same.

>>
>> + ? ? ? rm -f CMakeCache.txt && \
>>
>> + ? ? ? $$($$(PKG)_CONF_ENV) $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR)
>> \
>>
>> + ? ? ? ? ? ? ? -Wno-dev \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_SYSTEM_NAME:STRING="Linux" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_C_COMPILER:FILEPATH="$$(CMAKE_TARGET_CC)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_CXX_COMPILER:FILEPATH="$$(CMAKE_TARGET_CXX)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_C_FLAGS:STRING="$$(CMAKE_TARGET_CFLAGS)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_CXX_FLAGS:STRING="$$(CMAKE_TARGET_CXXFLAGS)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH:PATH="$$(STAGING_DIR)" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM:STRING="NEVER" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING="ONLY" \
>>
>> + ? ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE:STRING="ONLY" \
>
> Why don't you use the -DCMAKE_TOOLCHAIN_FILE <cmake-toolchain-file> here
> instead of all these -D... ?

Good question :-)

1) It's because the toolchain-file patch was written after this :-)

2) The -D... flags come from cdrkit.mk, which I used as "template" for
CMAKETARGETS. Some of the flags I'm not sure if are right (or is needed)
for a toolchain-file:

CMAKE_{C,CXX}_FLAGS, CMAKE_{EXE,MODULE,SHARED}_LINKER_FLAGS

Neither of these are listed in CMake Cross-compiling page[1].

So, I took the easy way out: build CMake packages inside Buildroot using
cdrkit.mk settings (should cause minimal breakage) and add a minimal
toolchain-file for out-of-Buildroot packages which just have the bare
minimum of settings.

I will take another look at the above CMake variables during a build, and
try to come up with a minimal toolchain-file that can work well internally
and externally.

However, isn't there a little conflict between internal and external use?
For internal use I'd like Buildroot to force build configurations on all
packages, like Debug/Release. but for external packages I'd like to control
this in the package itself. Maybe we should use the same toolchain-file
internally and externally, but give CMake CFLAGS/CXXFLAGS on the
commandline when building internal packages?

[1] the http://www.vtk.org/Wiki/CMake_Cross_Compiling

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Samuel Martin]

Hi Bj?rn,


> You configure and build in the source tree, why not.. but CMake

> supports (i'd like to say: it's designed to) build out of source tree (and

> it messes up a bite the build tree...).


> I agree, it's a bit messy. But where to but the build tree? Inside the

srctree or in a directory at the same level? I guess I would prefer the

latter, something like


> srctree:

 output/build/cdrkit-1.1.10


> buildtree:

 output/build/cdrkit-1.1.10.build

or:
srctree:
  output/build/cdrkit-1.1.10
buildtree:
  output/build/cdrkit-1.1.10/build
Like this, we keep only one directory per package and don't mess up the
source tree.
Whatever, both solutions are good. For me, it's not a big deal, but maybe BR
leaders will prefer one or the other solution to keep it consistent.

However, isn't there a little conflict between internal and external use?

For internal use I'd like Buildroot to force build configurations on all

packages, like Debug/Release. but for external packages I'd like to control

this in the package itself.

Debug/Release configuration is a setting managed by CMAKE_BUILD_TYPE, so if
we want to force the release config inside BR, we can
define CMAKE_BUILD_TYPE in the CONFIGURE_CMDS function.
We can even add the option in the menuconfig...

Maybe we should use the same toolchain-file internally and externally,

That's my goal.


> but give CMake CFLAGS/CXXFLAGS on the commandline when building internal
> packages?

If we need, yes, but i am quite doubtful about the usefulness of these
flags.


Cheers,

Samuel


2010/12/14 Bj?rn Forsman <bjorn.forsman@gmail.com>

> Hi Samuel,
>
> 2010/12/13 Samuel Martin <s.martin49@gmail.com>:
> > Hi Bj?rn,
> > Thanks for submitting these patches that join some of my works,
> especially
> > about generating a cmake-toolchain file. You beat me to the punch ;)
> > Details:
> >>
> >> +# CMake doesn't support having the --sysroot option directly in the
> >>
> >> +# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
> >>
> >> +CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
> >>
> >> +CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
> >>
> >> +CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC))
> $(TARGET_CFLAGS)
> >>
> >> +CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX))
> >> $(TARGET_CXXFLAGS)
> >
> > I think it is not necessary to add the --sysroot option to any of these
> > flags if we correctly define the CMake toolchain file (cf. patch review
> > of [PATCH 3/4])
>
> I guess you're right.
>
> >> +# Configure package for target
> >>
> >> +define $(2)_CONFIGURE_CMDS
> >>
> >> +       (cd $$($$(PKG)_SRCDIR) && \
> >
> > You configure and build in the source tree, why not.. but CMake
> > supports (i'd like to say: it's designed to) build out of source tree
> (and
> > it messes up a bite the build tree...).
>
> I agree, it's a bit messy. But where to but the build tree? Inside the
> srctree or in a directory at the same level? I guess I would prefer the
> latter, something like
>
> srctree:
>  output/build/cdrkit-1.1.10
>
> buildtree:
>  output/build/cdrkit-1.1.10.build
>
> But as the autotools infrastructure does (AFAIK) buildtree == srctree, I
> just did the same.
>
> >>
> >> +       rm -f CMakeCache.txt && \
> >>
> >> +       $$($$(PKG)_CONF_ENV) $(HOST_DIR)/usr/bin/cmake
> $$($$(PKG)_SRCDIR)
> >> \
> >>
> >> +               -Wno-dev \
> >>
> >> +               -DCMAKE_SYSTEM_NAME:STRING="Linux" \
> >>
> >> +               -DCMAKE_C_COMPILER:FILEPATH="$$(CMAKE_TARGET_CC)" \
> >>
> >> +               -DCMAKE_CXX_COMPILER:FILEPATH="$$(CMAKE_TARGET_CXX)" \
> >>
> >> +               -DCMAKE_C_FLAGS:STRING="$$(CMAKE_TARGET_CFLAGS)" \
> >>
> >> +               -DCMAKE_CXX_FLAGS:STRING="$$(CMAKE_TARGET_CXXFLAGS)" \
> >>
> >> +               -DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
> >>
> >> +               -DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)"
> \
> >>
> >> +               -DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)"
> \
> >>
> >> +               -DCMAKE_FIND_ROOT_PATH:PATH="$$(STAGING_DIR)" \
> >>
> >> +               -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM:STRING="NEVER" \
> >>
> >> +               -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING="ONLY" \
> >>
> >> +               -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE:STRING="ONLY" \
> >
> > Why don't you use the -DCMAKE_TOOLCHAIN_FILE <cmake-toolchain-file> here
> > instead of all these -D... ?
>
> Good question :-)
>
> 1) It's because the toolchain-file patch was written after this :-)
>
> 2) The -D... flags come from cdrkit.mk, which I used as "template" for
> CMAKETARGETS. Some of the flags I'm not sure if are right (or is needed)
> for a toolchain-file:
>
> CMAKE_{C,CXX}_FLAGS, CMAKE_{EXE,MODULE,SHARED}_LINKER_FLAGS
>
> Neither of these are listed in CMake Cross-compiling page[1].
>
> So, I took the easy way out: build CMake packages inside Buildroot using
> cdrkit.mk settings (should cause minimal breakage) and add a minimal
> toolchain-file for out-of-Buildroot packages which just have the bare
> minimum of settings.
>
> I will take another look at the above CMake variables during a build, and
> try to come up with a minimal toolchain-file that can work well internally
> and externally.
>
> However, isn't there a little conflict between internal and external use?
> For internal use I'd like Buildroot to force build configurations on all
> packages, like Debug/Release. but for external packages I'd like to control
> this in the package itself. Maybe we should use the same toolchain-file
> internally and externally, but give CMake CFLAGS/CXXFLAGS on the
> commandline when building internal packages?
>
> [1] the http://www.vtk.org/Wiki/CMake_Cross_Compiling
>
> Best regards,
> Bj?rn Forsman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101222/ea44e062/attachment-0001.html>

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Thomas Petazzoni]

Hello,

On Wed, 22 Dec 2010 22:34:17 +0100
Samuel Martin <s.martin49@gmail.com> wrote:

> srctree:
>   output/build/cdrkit-1.1.10
> buildtree:
>   output/build/cdrkit-1.1.10/build
> Like this, we keep only one directory per package and don't mess up the
> source tree.
> Whatever, both solutions are good. For me, it's not a big deal, but maybe BR
> leaders will prefer one or the other solution to keep it consistent.

I agree.

> > but give CMake CFLAGS/CXXFLAGS on the commandline when building internal
> > packages?
> 
> If we need, yes, but i am quite doubtful about the usefulness of these
> flags.

Huh ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Bjørn Forsman]

Hi,

On 23 December 2010 08:46, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 22 Dec 2010 22:34:17 +0100
> Samuel Martin <s.martin49@gmail.com> wrote:
>
>> srctree:
>> ? output/build/cdrkit-1.1.10
>> buildtree:
>> ? output/build/cdrkit-1.1.10/build
>> Like this, we keep only one directory per package and don't mess up the
>> source tree.
>> Whatever, both solutions are good. For me, it's not a big deal, but maybe BR
>> leaders will prefer one or the other solution to keep it consistent.
>
> I agree.

I actually chose to build in SRCDIR for the sake of consistency - autotools
packages build in SRCDIR :-)

What if a package already has a build/ dir inside of its source tree?
Maybe a bit safer
if we call the build dir _cmake_build/ or something? I'll introduce a
$(2)_BUILDDIR
variable in the next patch series and point it to a build dir inside
the source tree.

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Thomas Petazzoni]

On Thu, 23 Dec 2010 09:46:12 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> I actually chose to build in SRCDIR for the sake of consistency - autotools
> packages build in SRCDIR :-)

Oh, if CMake supports nicely the build-inside-source directory thing,
then we can just use it as we do for autotools packages.

I've been wondering whether we could build out-of-tree for autotools
based packages, in order to share the source code between target and
host package, and to ease the support of overriden packages, but I'm
pretty sure we'll it a lot of problems with out-of-tree build in
different packages, and it'll only work with autotools or cmake based
packages. So the safest is probably to keep the build-inside-source
mechanism we are currently doing.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Bjørn Forsman]

Hi,

2010/12/23 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> On Thu, 23 Dec 2010 09:46:12 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> I actually chose to build in SRCDIR for the sake of consistency - autotools
>> packages build in SRCDIR :-)
>
> Oh, if CMake supports nicely the build-inside-source directory thing,
> then we can just use it as we do for autotools packages.

Yes. CMake has no problems with build-inside-source.

> I've been wondering whether we could build out-of-tree for autotools
> based packages, in order to share the source code between target and
> host package, and to ease the support of overriden packages, but I'm
> pretty sure we'll it a lot of problems with out-of-tree build in
> different packages, and it'll only work with autotools or cmake based
> packages. So the safest is probably to keep the build-inside-source
> mechanism we are currently doing.

Agree.

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Thomas Petazzoni]

Hello Bjorn,

On Sun, 12 Dec 2010 20:29:12 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> +# CMake doesn't support having the --sysroot option directly in the
> +# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
> +CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
> +CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
> +CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
> +CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX)) $(TARGET_CXXFLAGS)

Those definitions should be *outside* the CMAKETARGETS_INNER macro,
because:

 1/ They might be useful even if no package makes use of the
    CMAKETARGETS infrastructure

 2/ They are not package specific, so they have no reason to be inside
    the macro.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Bjørn Forsman]

Hi Thomas,

2011/1/7 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Hello Bjorn,
>
> On Sun, 12 Dec 2010 20:29:12 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> +# CMake doesn't support having the --sysroot option directly in the
>> +# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
>> +CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
>> +CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
>> +CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
>> +CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX)) $(TARGET_CXXFLAGS)
>
> Those definitions should be *outside* the CMAKETARGETS_INNER macro,
> because:
>
> ?1/ They might be useful even if no package makes use of the
> ? ?CMAKETARGETS infrastructure
>
> ?2/ They are not package specific, so they have no reason to be inside
> ? ?the macro.

You are right. I will fix it in the next version of the patch series.

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Thomas Petazzoni]

Hello,

On Sun, 12 Dec 2010 20:29:12 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> +		-DCMAKE_SYSTEM_NAME:STRING="Linux" \
> +		-DCMAKE_C_COMPILER:FILEPATH="$$(CMAKE_TARGET_CC)" \
> +		-DCMAKE_CXX_COMPILER:FILEPATH="$$(CMAKE_TARGET_CXX)" \
> +		-DCMAKE_C_FLAGS:STRING="$$(CMAKE_TARGET_CFLAGS)" \
> +		-DCMAKE_CXX_FLAGS:STRING="$$(CMAKE_TARGET_CXXFLAGS)" \
> +		-DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
> +		-DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
> +		-DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
> +		-DCMAKE_FIND_ROOT_PATH:PATH="$$(STAGING_DIR)" \
> +		-DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM:STRING="NEVER" \
> +		-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING="ONLY" \
> +		-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE:STRING="ONLY" \
> +		-DCMAKE_INSTALL_PREFIX:PATH="/usr" \

We lack CMAKE_PROGRAM_PATH and CMAKE_INSTALL_SO_NO_EXE in this list. As
pointed out by others, it'd be great if the infrastructure could use
the generated CMake toolchain file.

Could you update your patch set and resend ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] Add CMAKETARGETS infrastructure for CMake packages

[Bjørn Forsman]

Hi,

On 10 January 2011 18:51, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sun, 12 Dec 2010 20:29:12 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> + ? ? ? ? ? ? -DCMAKE_SYSTEM_NAME:STRING="Linux" \
>> + ? ? ? ? ? ? -DCMAKE_C_COMPILER:FILEPATH="$$(CMAKE_TARGET_CC)" \
>> + ? ? ? ? ? ? -DCMAKE_CXX_COMPILER:FILEPATH="$$(CMAKE_TARGET_CXX)" \
>> + ? ? ? ? ? ? -DCMAKE_C_FLAGS:STRING="$$(CMAKE_TARGET_CFLAGS)" \
>> + ? ? ? ? ? ? -DCMAKE_CXX_FLAGS:STRING="$$(CMAKE_TARGET_CXXFLAGS)" \
>> + ? ? ? ? ? ? -DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
>> + ? ? ? ? ? ? -DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
>> + ? ? ? ? ? ? -DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
>> + ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH:PATH="$$(STAGING_DIR)" \
>> + ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM:STRING="NEVER" \
>> + ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY:STRING="ONLY" \
>> + ? ? ? ? ? ? -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE:STRING="ONLY" \
>> + ? ? ? ? ? ? -DCMAKE_INSTALL_PREFIX:PATH="/usr" \
>
> We lack CMAKE_PROGRAM_PATH and CMAKE_INSTALL_SO_NO_EXE in this list. As
> pointed out by others, it'd be great if the infrastructure could use
> the generated CMake toolchain file.

Yes, next version uses the toolchain-file internally. Regarding
CMAKE_PROGRAM_PATH, I'm adding that for target configuration. But for host
configuration I'm trying to use this instead:

CMAKE_FIND_ROOT_PATH=$(HOST_DIR)
CMAKE_FIND_ROOT_PATH_MODE_PROGRAM=BOTH
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=BOTH
CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=BOTH

Setting CMAKE_PROGRAM_PATH only affects FIND_PROGRAM but the above affects
all of FIND_{PROGRAM,LIBRARY,PATH,FILE} which I think is the right thing
here. What do you think?

> Could you update your patch set and resend ?

Yes, it's on my TODO list :-) But there are some issues I'm still working
on.

I've been experimenting with removing the following flags:

-DCMAKE_EXE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
-DCMAKE_MODULE_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \
-DCMAKE_SHARED_LINKER_FLAGS:STRING="$$(TARGET_LDFLAGS)" \

as I feel it is not the "CMake"-way of doing it. I mean that
CMAKE_FIND_ROOT_PATH and friends should be enough and that there should be
no need to "micro manage" CMake. However, the only package I've got for
testing which has any sort of external dependency is the cdrkit package and
it fails to build without explicitly adding -Lpath/to/lib to the command
line (which the above does). cdrkit doesn't use FIND_LIBRARY, it just adds
libs as dependencies without looking for them and assumes they will be
found during linking. This must be wrong of cdrkit.

Maybe the linker flags should go only in cdrkit.mk and not in CMAKETARGETS?
A part of me feels that having these extra flags in the framework may hide
bugs in a package CMakeLists.txt file...

If it matters, OE doesn't have linker flags to its cmake.bbclass.

Oh, and speaking of OE (thanks for reminding me of their cmake.bbclass),
they have some interresting settings:

  echo "set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST}
${STAGING_DIR_NATIVE}
${STAGING_DIR_NATIVE}${prefix_native}/${BASE_PACKAGE_ARCH} )" >>
${WORKDIR}/toolchain.cmake
  echo "set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )" >>
${WORKDIR}/toolchain.cmake
  echo "set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )" >>
${WORKDIR}/toolchain.cmake
  echo "set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )" >>
${WORKDIR}/toolchain.cmake

And they disable ccache. Maybe we should too, as there are issues with
ccache in the current CMAKETARGETS implementation. Or we could symlink
gcc->ccache which I think should fix the issue.

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 2/4] doc: add CMAKETARGETS documentation

[Bjørn Forsman]

---
 docs/buildroot.html |  151 +++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 147 insertions(+), 4 deletions(-)

diff --git a/docs/buildroot.html b/docs/buildroot.html
index 8293c8f..2f69940 100644
--- a/docs/buildroot.html
+++ b/docs/buildroot.html
@@ -801,6 +801,8 @@ endif
           <li><a href="#generic-reference">Makefile for generic packages : reference</a></li>
           <li><a href="#autotools-tutorial">Makefile for autotools-based packages : tutorial</a></li>
           <li><a href="#autotools-reference">Makefile for autotools-based packages : reference</a></li>
+          <li><a href="#cmake-tutorial">Makefile for CMake-based packages : tutorial</a></li>
+          <li><a href="#cmake-reference">Makefile for CMake-based packages : reference</a></li>
           <li><a href="#manual-tutorial">Manual Makefile : tutorial</a></li>
         </ul>
       </li>
@@ -1376,13 +1378,154 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
       general case.</li>
     </ul>
 
+   <h4 id="cmake-tutorial">Makefile for CMake-based packages : tutorial</h4>
+
+   <p>First, let's see how to write a <code>.mk</code> file for an
+   CMake-based package, with an example :</p>
+
+<pre>
+<span style="color: #000000">01:</span><span style="font-style: italic; color: #9A1900"> #############################################################</span>
+<span style="color: #000000">02:</span><span style="font-style: italic; color: #9A1900"> #</span>
+<span style="color: #000000">03:</span><span style="font-style: italic; color: #9A1900"> # libfoo</span>
+<span style="color: #000000">04:</span><span style="font-style: italic; color: #9A1900"> #</span>
+<span style="color: #000000">05:</span><span style="font-style: italic; color: #9A1900"> #############################################################</span>
+<span style="color: #000000">06:</span><span style="color: #009900"> LIBFOO_VERSION</span> = 1.0
+<span style="color: #000000">07:</span><span style="color: #009900"> LIBFOO_SOURCE</span> = libfoo-<span style="color: #009900">$(LIBFOO_VERSION)</span>.tar.gz
+<span style="color: #000000">08:</span><span style="color: #009900"> LIBFOO_SITE</span> = http://www.foosoftware.org/download
+<span style="color: #000000">09:</span><span style="color: #009900"> LIBFOO_INSTALL_STAGING</span> = YES
+<span style="color: #000000">10:</span><span style="color: #009900"> LIBFOO_INSTALL_TARGET</span> = YES
+<span style="color: #000000">11:</span><span style="color: #009900"> LIBFOO_CONF_OPT</span> = -DBUILD_DEMOS=ON
+<span style="color: #000000">12:</span><span style="color: #009900"> LIBFOO_DEPENDENCIES</span> = libglib2 host-pkg-config
+<span style="color: #000000">13:</span>
+<span style="color: #000000">14:</span><span style="color: #009900"> $(eval $(call CMAKETARGETS,package,libfoo))</span>
+</pre>
+
+    <p>On line 6, we declare the version of the package.</p>
+
+    <p>On line 7 and 8, we declare the name of the tarball and the location
+    of the tarball on the Web. Buildroot will automatically download the
+    tarball from this location.</p>
+
+    <p>On line 9, we tell Buildroot to install the package to the staging
+    directory. The staging directory, located in <code>output/staging/</code>
+    is the directory where all the packages are installed, including their
+    development files, etc. By default, packages are not installed to the
+    staging directory, since usually, only libraries need to be installed in
+    the staging directory: their development files are needed to compile
+    other libraries or applications depending on them. Also by default, when
+    staging installation is enabled, packages are installed in this location
+    using the <code>make install</code> command.</p>
+
+    <p>On line 10, we tell Buildroot to also install the package to the
+    target directory. This directory contains what will become the root
+    filesystem running on the target. Usually, we try not to install header
+    files and to install stripped versions of the binary. By default, target
+    installation is enabled, so in fact, this line is not strictly
+    necessary. Also by default, packages are installed in this location
+    using the <code>make install</code> command.</p>
+
+    <p>On line 11, we tell Buildroot to pass custom options to CMake when it is
+    configuring the package.</p>
+
+    <p>On line 12, we declare our dependencies, so that they are built
+    before the build process of our package starts.</p>
+
+    <p>Finally, on line line 14, we invoke the <code>CMAKETARGETS</code>
+    macro that generates all the Makefile rules that actually allows the
+    package to be built.</p>
+
+    <h4 id="cmake-reference">Makefile for CMake packages : reference</h4>
+
+    <p>The main macro of the CMake package infrastructure is
+    <code>CMAKETARGETS</code>. It has the same number of arguments and the
+    same semantic as the <code>GENTARGETS</code> macro, which is the main
+    macro of the generic package infrastructure. For CMake packages, the
+    ability to have target and host packages is also available.</p>
+
+    <p>Just like the generic infrastructure, the CMake infrastructure
+    works by defining a number of variables before calling the
+    <code>CMAKETARGETS</code> macro.</p>
+
+    <p>First, all the package metadata information variables that exist in the
+    generic infrastructure also exist in the CMake infrastructure:
+    <code>LIBFOO_VERSION</code>, <code>LIBFOO_SOURCE</code>,
+    <code>LIBFOO_PATCH</code>, <code>LIBFOO_SITE</code>,
+    <code>LIBFOO_SUBDIR</code>, <code>LIBFOO_DEPENDENCIES</code>,
+    <code>LIBFOO_INSTALL_STAGING</code>, <code>LIBFOO_INSTALL_TARGET</code>.</p>
+
+    <p>A few additional variables, specific to the CMake infrastructure,
+    can also be defined. Many of them are only useful in very specific
+    cases, typical packages will therefore only use a few of them.</p>
+
+    <ul>
+      <li><code>LIBFOO_SUBDIR</code> may contain the name of a subdirectory
+      inside the package that contains CMakeLists.txt. This is useful,
+      if for example, the main CMakeLists.txt file is not at the root of the
+      tree extracted by the tarball. If <code>HOST_LIBFOO_SUBDIR</code> is
+      not specified, it defaults to <code>LIBFOO_SUBDIR</code>.</li>
+
+      <li><code>LIBFOO_CONF_ENV</code>, to specify additional environment
+      variables to pass to CMake. By default, empty.</li>
+
+      <li><code>LIBFOO_CONF_OPT</code>, to specify additional configure
+      options to pass to CMake. By default, empty.</li>
+
+      <li><code>LIBFOO_MAKE</code>, to specify an alternate <code>make</code>
+      command. This is typically useful when parallel make is enabled in
+      the configuration (using <code>BR2_JLEVEL</code>) but that this
+      feature should be disabled for the given package, for one reason or
+      another. By default, set to <code>$(MAKE)</code>. If parallel building
+      is not supported by the package, then it should be set to
+      <code>LIBFOO_MAKE=$(MAKE1)</code>.</li>
+
+      <li><code>LIBFOO_MAKE_ENV</code>, to specify additional environment
+      variables to pass to make in the build step. These are passed before
+      the <code>make</code> command. By default, empty.</li>
+
+      <li><code>LIBFOO_MAKE_OPT</code>, to specify additional variables to
+      pass to make in the build step. These are passed after the
+      <code>make</code> command. By default, empty.</li>
+
+      <li><code>LIBFOO_INSTALL_STAGING_OPT</code> contains the make options
+      used to install the package to the staging directory. By default, the
+      value is <code>DESTDIR=$$(STAGING_DIR) install</code>, which is
+      correct for most CMake packages. It is still possible to override
+      it.</li>
+
+      <li><code>LIBFOO_INSTALL_TARGET_OPT</code> contains the make options
+      used to install the package to the target directory. By default, the
+      value is <code>DESTDIR=$$(TARGET_DIR) install</code>. The default
+      value is correct for most CMake packages, but it is still possible
+      to override it if needed.</li>
+
+      <li><code>LIBFOO_CLEAN_OPT</code> contains the make options used to
+      clean the package. By default, the value is <code>clean</code>.</li>
+    </ul>
+
+    <p>With the CMake infrastructure, all the steps required to build
+    and install the packages are already defined, and they generally work
+    well for most CMake-based packages. However, when required, it is
+    still possible to customize what is done in any particular step:</p>
+
+    <ul>
+      <li>By adding a post-operation hook (after extract, patch, configure,
+      build or install). See the reference documentation of the generic
+      infrastructure for details.</li>
+
+      <li>By overriding one of the steps. For example, even if the CMake
+      infrastructure is used, if the package <code>.mk</code> file defines its
+      own <code>LIBFOO_CONFIGURE_CMDS</code> variable, it will be used
+      instead of the default CMake one. However, using this method
+      should be restricted to very specific cases. Do not use it in the
+      general case.</li>
+    </ul>
+
     <h4 id ="manual-tutorial">Manual Makefile : tutorial</h4>
 
     <p><b>NOTE: new manual makefiles should not be created, and existing
-    manual makefiles should be converted either to the generic
-    infrastructure or the autotools infrastructure. This section is only
-    kept to document the existing manual makefiles and to help understand
-    how they work.</b></p>
+    manual makefiles should be converted either to the generic, autotools
+    or cmake infrastructure. This section is only kept to document the existing
+    manual makefiles and to help understand how they work.</b></p>
 
 <pre>
 01: #############################################################
-- 
1.7.1

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Bjørn Forsman]

A CMake toolchain file makes it easy to develop CMake-based packages
outside of Buildroot. Just give the toolchain file path to CMake via the
-DCMAKE_TOOLCHAIN_FILE=... option.

Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
---
 Makefile |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 7d6e4af..0cf49d4 100644
--- a/Makefile
+++ b/Makefile
@@ -358,7 +358,7 @@ $(TARGETS_ALL): __real_tgt_%: $(BASE_TARGETS) %
 dirs: $(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
 	$(HOST_DIR) $(BR2_DEPENDS_DIR) $(BINARIES_DIR) $(STAMP_DIR)
 
-$(BASE_TARGETS): dirs
+$(BASE_TARGETS): dirs $(O)/toolchainfile.cmake
 
 $(BUILD_DIR)/buildroot-config/auto.conf: $(CONFIG_DIR)/.config
 	$(MAKE) $(EXTRAMAKEARGS) silentoldconfig
@@ -367,6 +367,16 @@ prepare: $(BUILD_DIR)/buildroot-config/auto.conf
 
 world: prepare dependencies dirs $(BASE_TARGETS) $(TARGETS_ALL)
 
+$(O)/toolchainfile.cmake:
+	@echo -en "\
+	set(CMAKE_SYSTEM_NAME Linux)\n\
+	set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
+	set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
+	set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
+	set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
+	set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
+	set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\
+	" > $@
 
 .PHONY: all world dirs clean distclean source outputmakefile \
 	$(BASE_TARGETS) $(TARGETS) $(TARGETS_ALL) \
-- 
1.7.1

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Samuel Martin]

Hi Bj?rn,

Again, this reviews may refer to the other patch reviews of the set...

+$(O)/toolchainfile.cmake:

+       @echo -en "\

+       set(CMAKE_SYSTEM_NAME Linux)\n\

+       set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\

+       set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\

In my version (not submitted), i also set the following
variables: CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH

+       set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\

+       set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\

Here is the main point of disagreement. Because in BR the cross-compiler and
all tools around are located somewhere in a subdirectory of $(STAGING_DIR),
i do set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to "ONLY".


> +       set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\

+       set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\

+       " > $@



The generated toolchain file does not seem to support external
 cross-toolchain (btw, from my understanding, CTNG is installed in the
staging, so no problem)
To do that, I think CMAKE_FIND_ROOT_PATH is a list (so are
CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH), so adjust them, CMAKE_C_COMPILER
and CMAKE_CXX_COMPILER.


Regards,

Samuel

2010/12/12 Bj?rn Forsman <bjorn.forsman@gmail.com>

> A CMake toolchain file makes it easy to develop CMake-based packages
> outside of Buildroot. Just give the toolchain file path to CMake via the
> -DCMAKE_TOOLCHAIN_FILE=... option.
>
> Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
> ---
>  Makefile |   12 +++++++++++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 7d6e4af..0cf49d4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -358,7 +358,7 @@ $(TARGETS_ALL): __real_tgt_%: $(BASE_TARGETS) %
>  dirs: $(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR)
> \
>        $(HOST_DIR) $(BR2_DEPENDS_DIR) $(BINARIES_DIR) $(STAMP_DIR)
>
> -$(BASE_TARGETS): dirs
> +$(BASE_TARGETS): dirs $(O)/toolchainfile.cmake
>
>  $(BUILD_DIR)/buildroot-config/auto.conf: $(CONFIG_DIR)/.config
>        $(MAKE) $(EXTRAMAKEARGS) silentoldconfig
> @@ -367,6 +367,16 @@ prepare: $(BUILD_DIR)/buildroot-config/auto.conf
>
>  world: prepare dependencies dirs $(BASE_TARGETS) $(TARGETS_ALL)
>
> +$(O)/toolchainfile.cmake:
> +       @echo -en "\
> +       set(CMAKE_SYSTEM_NAME Linux)\n\
> +       set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
> +       set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
> +       set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
> +       set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
> +       set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
> +       set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\
> +       " > $@
>
>  .PHONY: all world dirs clean distclean source outputmakefile \
>        $(BASE_TARGETS) $(TARGETS) $(TARGETS_ALL) \
> --
> 1.7.1
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101213/9964ef11/attachment.html>

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Bjørn Forsman]

Hi Samuel,

2010/12/13 Samuel Martin <s.martin49@gmail.com>:
> Hi?Bj?rn,
> Again, this reviews may refer to the other patch reviews of the set...
>>
>> +$(O)/toolchainfile.cmake:
>>
>> + ? ? ? @echo -en "\
>>
>> + ? ? ? set(CMAKE_SYSTEM_NAME Linux)\n\
>>
>> + ? ? ? set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
>>
>> + ? ? ? set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
>
> In my version (not submitted), i also set the following
> variables:?CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH

I just read up on those variables (man cmake) and it seems to me that they
are used in addition to a default set of paths(?), which I presume are
relative to CMAKE_FIND_ROOT_PATH. So are they really needed? What paths
do you set them to?

>>
>> + ? ? ? set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
>>
>> + ? ? ? set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
>
> Here is the main point of disagreement. Because in BR the cross-compiler and
> all tools around are located somewhere in a subdirectory of?$(STAGING_DIR),
> i do set?CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to "ONLY".

Is it completely safe to set it to "ONLY"? Couldn't host binaries be picked
up during cross-compilation? Or am I missing something?

I haven't tested more than 'hello world' packages (no dependencies) with
the toolchain-file, so if having "ONLY" is mandatory for more complex
packages (like using pkg-config?) I'll change it.

>> + ? ? ? set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
>>
>> + ? ? ? set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\
>>
>> + ? ? ? " > $@
>
> The generated toolchain file does not seem to support external
> ?cross-toolchain (btw, from my understanding, CTNG is installed in the
> staging, so no problem)
> To do that, I think?CMAKE_FIND_ROOT_PATH is a list (so are
> CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH), so adjust them,?CMAKE_C_COMPILER
> and?CMAKE_CXX_COMPILER.

Did you test external toolchain? Did it break? I haven't tested it (yet),
but AFAIK Buildroot copies external toolchain's sysroot into staging so
there should no need for multiple entries in CMAKE_FIND_ROOT_PATH
(or changes to CMAKE_{C,CXX}_COMPILER). Right?

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Samuel Martin]

Hi Bj?rn,


> > In my version (not submitted), i also set the following

> variables: CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH


> I just read up on those variables (man cmake) and it seems to me that they

are used in addition to a default set of paths(?), which I presume are

relative to CMAKE_FIND_ROOT_PATH. So are they really needed? What paths

do you set them to?

You're right.

It might be an interesting point to add in the doc, but needs to be tested
and confirmed.
use case:
  You build a BR environment, then an external lib out of BR and develop a
project for the BR's target that use this external lib.
  In this case, there are 2 solutions at least:
    - add the external lib output directory path to the CMAKE_FIND_ROOT_PATH
variable (need to alter the toolchain file)
    - or set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH pointed on the
corresponding sub-directories of the external lib output directory.


>> +       set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\

>

> Here is the main point of disagreement. Because in BR the cross-compiler
> and

> all tools around are located somewhere in a subdirectory of
> $(STAGING_DIR),

> i do set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to "ONLY".


> Is it completely safe to set it to "ONLY"? Couldn't host binaries be picked

up during cross-compilation? Or am I missing something?

When cross-compiling, you need to build the whole toolchain (ie. the
cross-compiler, assembler, linker, and all useful cross-tools) and the
sysroot for the target.
You have to do this and only refer to these tools and sysroot when building
binaries for the target to avoid building broken binaries that could
be linked with something from the host.
So, yes, for the target, i think it's safe to set it to "ONLY"


> The generated toolchain file does not seem to support external

>  cross-toolchain (btw, from my understanding, CTNG is installed in the

> staging, so no problem)

> To do that, I think CMAKE_FIND_ROOT_PATH is a list (so are

> CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH), so adjust them,
> CMAKE_C_COMPILER

> and CMAKE_CXX_COMPILER.


> Did you test external toolchain? Did it break? I haven't tested it (yet),

but AFAIK Buildroot copies external toolchain's sysroot into staging so

there should no need for multiple entries in CMAKE_FIND_ROOT_PATH

(or changes to CMAKE_{C,CXX}_COMPILER). Right?

I haven't test external toolchain nor crosstool-NG, but afaik, crosstool-NG
toolchain is copied in the BR staging,
but not external ones.

Btw, the toolchain is currently located in the staging, but if this change
[1] (or if you're using a external tc), then, there needs to append both the
staging directory and the toolchain directory to CMAKE_FIND_ROOT_PATH.


[1] http://lists.busybox.net/pipermail/buildroot/2010-December/039824.html


Cheers,

Samuel


2010/12/14 Bj?rn Forsman <bjorn.forsman@gmail.com>

> Hi Samuel,
>
> 2010/12/13 Samuel Martin <s.martin49@gmail.com>:
> > Hi Bj?rn,
> > Again, this reviews may refer to the other patch reviews of the set...
> >>
> >> +$(O)/toolchainfile.cmake:
> >>
> >> +       @echo -en "\
> >>
> >> +       set(CMAKE_SYSTEM_NAME Linux)\n\
> >>
> >> +       set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
> >>
> >> +       set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
> >
> > In my version (not submitted), i also set the following
> > variables: CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH
>
> I just read up on those variables (man cmake) and it seems to me that they
> are used in addition to a default set of paths(?), which I presume are
> relative to CMAKE_FIND_ROOT_PATH. So are they really needed? What paths
> do you set them to?
>
> >>
> >> +       set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
> >>
> >> +       set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
> >
> > Here is the main point of disagreement. Because in BR the cross-compiler
> and
> > all tools around are located somewhere in a subdirectory
> of $(STAGING_DIR),
> > i do set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to "ONLY".
>
> Is it completely safe to set it to "ONLY"? Couldn't host binaries be picked
> up during cross-compilation? Or am I missing something?
>
> I haven't tested more than 'hello world' packages (no dependencies) with
> the toolchain-file, so if having "ONLY" is mandatory for more complex
> packages (like using pkg-config?) I'll change it.
>
> >> +       set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
> >>
> >> +       set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\
> >>
> >> +       " > $@
> >
> > The generated toolchain file does not seem to support external
> >  cross-toolchain (btw, from my understanding, CTNG is installed in the
> > staging, so no problem)
> > To do that, I think CMAKE_FIND_ROOT_PATH is a list (so are
> > CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH), so adjust
> them, CMAKE_C_COMPILER
> > and CMAKE_CXX_COMPILER.
>
> Did you test external toolchain? Did it break? I haven't tested it (yet),
> but AFAIK Buildroot copies external toolchain's sysroot into staging so
> there should no need for multiple entries in CMAKE_FIND_ROOT_PATH
> (or changes to CMAKE_{C,CXX}_COMPILER). Right?
>
> Best regards,
> Bj?rn Forsman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101222/a5d6b80f/attachment-0001.html>

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Thomas Petazzoni]

On Wed, 22 Dec 2010 22:32:30 +0100
Samuel Martin <s.martin49@gmail.com> wrote:

> I haven't test external toolchain nor crosstool-NG, but afaik, crosstool-NG
> toolchain is copied in the BR staging,
> but not external ones.

The sysroot of external toolchain is copied to $(STAGING_DIR) as well.

> Btw, the toolchain is currently located in the staging, but if this change
> [1] (or if you're using a external tc), then, there needs to append both the
> staging directory and the toolchain directory to CMAKE_FIND_ROOT_PATH.

I don't know what you call the "toolchain directory", but the changes
made by Gustavo only *move* the location of the sysroot, but there will
still be only one location for it, and $(STAGING_DIR) will continue to
point to it.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Samuel Martin]

Hi,

> Btw, the toolchain is currently located in the staging, but if this change

> [1] (or if you're using a external tc), then, there needs to append both
> the

> staging directory and the toolchain directory to CMAKE_FIND_ROOT_PATH.


> I don't know what you call the "toolchain directory", but the changes

made by Gustavo only *move* the location of the sysroot, but there will

still be only one location for it, and $(STAGING_DIR) will continue to

point to it.

Ok, i didn't see that any toolchain is copied in the staging directory, so
forget what i meant

Cheers,

Samuel


2010/12/23 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> On Wed, 22 Dec 2010 22:32:30 +0100
> Samuel Martin <s.martin49@gmail.com> wrote:
>
> > I haven't test external toolchain nor crosstool-NG, but afaik,
> crosstool-NG
> > toolchain is copied in the BR staging,
> > but not external ones.
>
> The sysroot of external toolchain is copied to $(STAGING_DIR) as well.
>
> > Btw, the toolchain is currently located in the staging, but if this
> change
> > [1] (or if you're using a external tc), then, there needs to append both
> the
> > staging directory and the toolchain directory to CMAKE_FIND_ROOT_PATH.
>
> I don't know what you call the "toolchain directory", but the changes
> made by Gustavo only *move* the location of the sysroot, but there will
> still be only one location for it, and $(STAGING_DIR) will continue to
> point to it.
>
> Regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101224/d1545657/attachment.html>

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Bjørn Forsman]

Hi,

2010/12/22 Samuel Martin <s.martin49@gmail.com>:
> Hi Bj?rn,
>
>>
>> > In my version (not submitted), i also set the following
>>
>> > variables:?CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH
>>
>> I just read up on those variables (man cmake) and it seems to me that they
>>
>> are used in addition to a default set of paths(?), which I presume are
>>
>> relative to CMAKE_FIND_ROOT_PATH. So are they really needed? What paths
>>
>> do you set them to?
>
> You're right.
> It might be an interesting point to add in the doc, but needs to be tested
> and confirmed.
> use case:
> ??You build a BR environment, then an external lib out of BR and develop a
> project for the BR's target?that use this external lib.
> ??In this case, there are 2 solutions at least:
> ?? ?- add the external lib output directory path to the?CMAKE_FIND_ROOT_PATH
> variable (need to alter the toolchain file)
> ?? ?- or set?CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH pointed on the
> corresponding?sub-directories of?the external lib output directory.

Yes. Also, the toolchain file can be copied out of buildroot and
modified (if desired).

>> >> + ? ? ? set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
>>
>> >
>>
>> > Here is the main point of disagreement. Because in BR the cross-compiler
>> > and
>>
>> > all tools around are located somewhere in a subdirectory of
>> > $(STAGING_DIR),
>>
>> > i do set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to "ONLY".
>>
>> Is it completely safe to set it to "ONLY"? Couldn't host binaries be
>> picked
>>
>> up during cross-compilation? Or am I missing something?
>
> When cross-compiling, you need to build the whole toolchain (ie. the
> cross-compiler, assembler, linker, and all useful cross-tools) and the
> sysroot for the target.
> You have to do this and only refer to these tools and sysroot when building
> binaries for the target to avoid building broken binaries that could
> be?linked with something from the host.
> So, yes, for the target, i think it's safe to set it to "ONLY"

But is it necessary? Wouldn't "NEVER" suffice? I don't mean to be
difficult, but I'd like to see a real world example of when it is needed
and not just add it because it "also works".

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Samuel Martin]

Hi,

Yes. Also, the toolchain file can be copied out of buildroot and

modified (if desired).

Agree.


> > So, yes, for the target, i think it's safe to set it to "ONLY"


> But is it necessary? Wouldn't "NEVER" suffice? I don't mean to be

difficult, but I'd like to see a real world example of when it is needed

and not just add it because it "also works".

Instead of being so strict with "ONLY" or "NEVER", maybe "FIRST" or "LAST"
[1] can solve this issue.
Months ago, I had some trouble with CMAKE_FIND_ROOT_PATH set to "NEVER"
while cross-compiling OpenCV, and I fixed this setting it to "ONLY". I hope
having some freetime during Xmas break to (re)run some tests about that.
That's a tricky point that certainly needs some tests to get the right
solution.

Cheers,

[1]
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_program

Samuel

2010/12/23 Bj?rn Forsman <bjorn.forsman@gmail.com>

> Hi,
>
> 2010/12/22 Samuel Martin <s.martin49@gmail.com>:
> > Hi Bj?rn,
> >
> >>
> >> > In my version (not submitted), i also set the following
> >>
> >> > variables: CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH
> >>
> >> I just read up on those variables (man cmake) and it seems to me that
> they
> >>
> >> are used in addition to a default set of paths(?), which I presume are
> >>
> >> relative to CMAKE_FIND_ROOT_PATH. So are they really needed? What paths
> >>
> >> do you set them to?
> >
> > You're right.
> > It might be an interesting point to add in the doc, but needs to be
> tested
> > and confirmed.
> > use case:
> >   You build a BR environment, then an external lib out of BR and develop
> a
> > project for the BR's target that use this external lib.
> >   In this case, there are 2 solutions at least:
> >     - add the external lib output directory path to
> the CMAKE_FIND_ROOT_PATH
> > variable (need to alter the toolchain file)
> >     - or set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH pointed on the
> > corresponding sub-directories of the external lib output directory.
>
> Yes. Also, the toolchain file can be copied out of buildroot and
> modified (if desired).
>
> >> >> +       set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
> >>
> >> >
> >>
> >> > Here is the main point of disagreement. Because in BR the
> cross-compiler
> >> > and
> >>
> >> > all tools around are located somewhere in a subdirectory of
> >> > $(STAGING_DIR),
> >>
> >> > i do set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to "ONLY".
> >>
> >> Is it completely safe to set it to "ONLY"? Couldn't host binaries be
> >> picked
> >>
> >> up during cross-compilation? Or am I missing something?
> >
> > When cross-compiling, you need to build the whole toolchain (ie. the
> > cross-compiler, assembler, linker, and all useful cross-tools) and the
> > sysroot for the target.
> > You have to do this and only refer to these tools and sysroot when
> building
> > binaries for the target to avoid building broken binaries that could
> > be linked with something from the host.
> > So, yes, for the target, i think it's safe to set it to "ONLY"
>
> But is it necessary? Wouldn't "NEVER" suffice? I don't mean to be
> difficult, but I'd like to see a real world example of when it is needed
> and not just add it because it "also works".
>
> Best regards,
> Bj?rn Forsman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101224/b4098878/attachment.html>

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Thomas Petazzoni]

Hello Bjorn,

I finally had the time to try this, and got some issues, fixed by the
below patch.

On Sun, 12 Dec 2010 20:29:14 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> +$(O)/toolchainfile.cmake:
> +	@echo -en "\
> +	set(CMAKE_SYSTEM_NAME Linux)\n\
> +	set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
> +	set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
> +	set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
> +	set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
> +	set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
> +	set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\
> +	" > $@
>  
>  .PHONY: all world dirs clean distclean source outputmakefile \
>  	$(BASE_TARGETS) $(TARGETS) $(TARGETS_ALL) \

diff --git a/Makefile b/Makefile
index 831b424..994dd52 100644
--- a/Makefile
+++ b/Makefile
@@ -375,8 +375,11 @@ world: prepare dependencies dirs $(BASE_TARGETS)
$(TARGETS_ALL) $(O)/toolchainfile.cmake:
        @echo -en "\
        set(CMAKE_SYSTEM_NAME Linux)\n\
+       set(CMAKE_PROGRAM_PATH $(HOST_DIR)/usr/bin)\n\
        set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
        set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
+       set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\")\n\
+       set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\")\n\
        set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
        set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
        set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\

With those, I can successfully use the CMake toolchain file to build a
Qt application against the Buildroot libraries.

If you agree, could you merge those modifications into your patch ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Bjørn Forsman]

Hi Thomas,

2011/1/7 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Hello Bjorn,
>
> I finally had the time to try this, and got some issues, fixed by the
> below patch.
>
> On Sun, 12 Dec 2010 20:29:14 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> +$(O)/toolchainfile.cmake:
>> + ? ? @echo -en "\
>> + ? ? set(CMAKE_SYSTEM_NAME Linux)\n\
>> + ? ? set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
>> + ? ? set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\
>> + ? ? " > $@
>>
>> ?.PHONY: all world dirs clean distclean source outputmakefile \
>> ? ? ? $(BASE_TARGETS) $(TARGETS) $(TARGETS_ALL) \
>
> diff --git a/Makefile b/Makefile
> index 831b424..994dd52 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -375,8 +375,11 @@ world: prepare dependencies dirs $(BASE_TARGETS)
> $(TARGETS_ALL) $(O)/toolchainfile.cmake:
> ? ? ? ?@echo -en "\
> ? ? ? ?set(CMAKE_SYSTEM_NAME Linux)\n\
> + ? ? ? set(CMAKE_PROGRAM_PATH $(HOST_DIR)/usr/bin)\n\
> ? ? ? ?set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
> ? ? ? ?set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
> + ? ? ? set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\")\n\
> + ? ? ? set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\")\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
>
> With those, I can successfully use the CMake toolchain file to build a
> Qt application against the Buildroot libraries.
>
> If you agree, could you merge those modifications into your patch ?

Yes, I will merge it. Thanks for testing and patching!

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Bjørn Forsman]

Hi Thomas,

2011/1/7 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Hello Bjorn,
>
> I finally had the time to try this, and got some issues, fixed by the
> below patch.
>
> On Sun, 12 Dec 2010 20:29:14 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> +$(O)/toolchainfile.cmake:
>> + ? ? @echo -en "\
>> + ? ? set(CMAKE_SYSTEM_NAME Linux)\n\
>> + ? ? set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
>> + ? ? set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
>> + ? ? set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)\n\
>> + ? ? " > $@
>>
>> ?.PHONY: all world dirs clean distclean source outputmakefile \
>> ? ? ? $(BASE_TARGETS) $(TARGETS) $(TARGETS_ALL) \
>
> diff --git a/Makefile b/Makefile
> index 831b424..994dd52 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -375,8 +375,11 @@ world: prepare dependencies dirs $(BASE_TARGETS)
> $(TARGETS_ALL) $(O)/toolchainfile.cmake:
> ? ? ? ?@echo -en "\
> ? ? ? ?set(CMAKE_SYSTEM_NAME Linux)\n\
> + ? ? ? set(CMAKE_PROGRAM_PATH $(HOST_DIR)/usr/bin)\n\
> ? ? ? ?set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
> ? ? ? ?set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
> + ? ? ? set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\")\n\
> + ? ? ? set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\")\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
>
> With those, I can successfully use the CMake toolchain file to build a
> Qt application against the Buildroot libraries.

I assume that CMAKE_PROGRAM_PATH is needed so CMake can
find (at least) moc and/or qmake? But after a git pull + build moc
and qmake are not in HOST_DIR/usr/bin:

$ find -type f -name moc -o -name qmake
./output/host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/usr/bin/moc
./output/host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/usr/bin/qmake
[snip matches from ./output/build/qt-everywhere-opensource-src-4.7.1]

And if I let find follow symlinks I also get these additional matches:

./output/host/usr/arm-linux/sysroot/usr/bin/moc
./output/host/usr/arm-linux/sysroot/usr/bin/qmake
./output/staging/usr/bin/moc
./output/staging/usr/bin/qmake

Is this maybe caused by the recent toolchain/sysroot changes? Or is
qt.mk just installing to bad dir? I mean, moc and qmake are host
binaries so I think they should be in HOST_DIR/usr/bin and not in
(target) sysroot.

Any thoughts?

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Thomas Petazzoni]

Hello,

On Sun, 9 Jan 2011 13:52:48 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> I assume that CMAKE_PROGRAM_PATH is needed so CMake can
> find (at least) moc and/or qmake?

Yes, exactly.

> But after a git pull + build moc
> and qmake are not in HOST_DIR/usr/bin:
> 
> $ find -type f -name moc -o -name qmake
> ./output/host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/usr/bin/moc
> ./output/host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/usr/bin/qmake
> [snip matches from ./output/build/qt-everywhere-opensource-src-4.7.1]

Yes, this is a mistake in the current qt package. It should install
those host tools to $(HOST_DIR)/usr/bin. I have a patch here that fixes
this, I need to clean it up and send it (I just did it on Friday, I
didn't had the time to send it yet).

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Thomas Petazzoni]

Hello Bjorn,

On Fri, 7 Jan 2011 18:15:36 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> diff --git a/Makefile b/Makefile
> index 831b424..994dd52 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -375,8 +375,11 @@ world: prepare dependencies dirs $(BASE_TARGETS)
> $(TARGETS_ALL) $(O)/toolchainfile.cmake:
>         @echo -en "\
>         set(CMAKE_SYSTEM_NAME Linux)\n\
> +       set(CMAKE_PROGRAM_PATH $(HOST_DIR)/usr/bin)\n\
>         set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
>         set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
> +       set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\")\n\
> +       set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\")\n\
>         set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
>         set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
>         set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
> 
> With those, I can successfully use the CMake toolchain file to build a
> Qt application against the Buildroot libraries.
> 
> If you agree, could you merge those modifications into your patch ?

It'd be great if you could also add

	set(CMAKE_INSTALL_SO_NO_EXE 0)

This is related to the executable permission of the shared libraries
installed by CMake. As explained in Modules/Platform/Linux.cmake, the
behaviour of CMake depends on the host system: on Debian systems, it
installs shared libraries without executable permissions, and on Fedora
systems it installs shared libraries with executable permissions.

In Buildroot, all shared libraries are installed with executable
permissions, and this fact is used to support stripping of shared
libraries in the target-finalize target of the main Makefile.

Therefore, we should not rely on CMake default behaviour, and instead
tell CMake what to do: set the executable permission on the installed
shared libraries. Which is what is done by setting the above variable.

For reference, this issue has also been raised on OpenEmbedded:
http://www.mail-archive.com/openembedded-devel at lists.openembedded.org/msg04736.html.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Bjørn Forsman]

Hi,

On 10 January 2011 18:50, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello Bjorn,
>
> On Fri, 7 Jan 2011 18:15:36 +0100
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>
>> diff --git a/Makefile b/Makefile
>> index 831b424..994dd52 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -375,8 +375,11 @@ world: prepare dependencies dirs $(BASE_TARGETS)
>> $(TARGETS_ALL) $(O)/toolchainfile.cmake:
>> ? ? ? ? @echo -en "\
>> ? ? ? ? set(CMAKE_SYSTEM_NAME Linux)\n\
>> + ? ? ? set(CMAKE_PROGRAM_PATH $(HOST_DIR)/usr/bin)\n\
>> ? ? ? ? set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
>> ? ? ? ? set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
>> + ? ? ? set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\")\n\
>> + ? ? ? set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\")\n\
>> ? ? ? ? set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
>> ? ? ? ? set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
>> ? ? ? ? set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
>>
>> With those, I can successfully use the CMake toolchain file to build a
>> Qt application against the Buildroot libraries.
>>
>> If you agree, could you merge those modifications into your patch ?
>
> It'd be great if you could also add
>
> ? ? ? ?set(CMAKE_INSTALL_SO_NO_EXE 0)
>
> This is related to the executable permission of the shared libraries
> installed by CMake. As explained in Modules/Platform/Linux.cmake, the
> behaviour of CMake depends on the host system: on Debian systems, it
> installs shared libraries without executable permissions, and on Fedora
> systems it installs shared libraries with executable permissions.
>
> In Buildroot, all shared libraries are installed with executable
> permissions, and this fact is used to support stripping of shared
> libraries in the target-finalize target of the main Makefile.
>
> Therefore, we should not rely on CMake default behaviour, and instead
> tell CMake what to do: set the executable permission on the installed
> shared libraries. Which is what is done by setting the above variable.
>
> For reference, this issue has also been raised on OpenEmbedded:
> http://www.mail-archive.com/openembedded-devel at lists.openembedded.org/msg04736.html.

Yes, I'll add that, thanks! I guess it only matters for the target build and
not native build (we don't strip HOST_DIR do we?), but I think I'll add
it to native build anyway, for consistency.

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Thomas Petazzoni]

On Mon, 10 Jan 2011 19:30:16 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> Yes, I'll add that, thanks! I guess it only matters for the target build and
> not native build (we don't strip HOST_DIR do we?), but I think I'll add
> it to native build anyway, for consistency.

Yes, it really only matters for the target build, but as most of
the .so in $(HOST_DIR) are also installed with executable permissions,
it's probably ok to set this variable to 0 as well for host builds.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Thomas Petazzoni]

Hello,

On Mon, 10 Jan 2011 19:30:16 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> Yes, I'll add that, thanks! I guess it only matters for the target
> build and not native build (we don't strip HOST_DIR do we?), but I
> think I'll add it to native build anyway, for consistency.

I had another two problems with the CMake toolchain file. The first is
that the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS variables were not taken
into account. It's more or less explained at
http://www.mail-archive.com/cmake at cmake.org/msg33248.html why this
happens. The second problem is that --sysroot was missing at link time,
so I had to add CMAKE_EXE_LINKER_FLAGS as well.

So I have the following changes:

diff --git a/Makefile b/Makefile
index 994dd52..b154007 100644
--- a/Makefile
+++ b/Makefile
@@ -378,8 +378,9 @@ $(O)/toolchainfile.cmake:
        set(CMAKE_PROGRAM_PATH $(HOST_DIR)/usr/bin)\n\
        set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
        set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
-       set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\")\n\
-       set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\")\n\
+       set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\" CACHE STRING \"\" FORCE)\n\
+       set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\" CACHE STRING \"\" FORCE)\n\
+       set(CMAKE_EXE_LINKER_FLAGS \"$(CMAKE_TARGET_LDFLAGS)\" CACHE STRING \"\" FORCE)\n\
        set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
        set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
        set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
diff --git a/package/Makefile.cmake.in b/package/Makefile.cmake.in
index 08a0395..ce50b10 100644
--- a/package/Makefile.cmake.in
+++ b/package/Makefile.cmake.in
@@ -41,6 +41,7 @@ CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
 CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
 CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
 CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX)) $(TARGET_CXXFLAGS)
+CMAKE_TARGET_LDFLAGS = $(filter --sysroot=%,$(TARGET_LD)) $(TARGET_LDFLAGS)

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Thomas Petazzoni]

Hello,

On Tue, 11 Jan 2011 11:22:28 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> +       set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\" CACHE STRING \"\" FORCE)\n\
> +       set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\" CACHE STRING \"\" FORCE)\n\
> +       set(CMAKE_EXE_LINKER_FLAGS \"$(CMAKE_TARGET_LDFLAGS)\" CACHE STRING \"\" FORCE)\n\


Argh, it should probably be :


> +       set(CMAKE_C_FLAGS \"${CMAKE_C_FLAGS} $(CMAKE_TARGET_CFLAGS)\" CACHE STRING \"\" FORCE)\n\
> +       set(CMAKE_CXX_FLAGS \"${CMAKE_CXX_FLAGS} $(CMAKE_TARGET_CXXFLAGS)\" CACHE STRING \"\" FORCE)\n\
> +       set(CMAKE_EXE_LINKER_FLAGS \"${CMAKE_EXE_LINKER_FLAGS} $(CMAKE_TARGET_LDFLAGS)\" CACHE STRING \"\" FORCE)\n\

To keep the possibly existing values of CMAKE_C_FLAGS, CMAKE_CXX_FLAGS
and CMAKE_EXE_LINKER_FLAGS.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] Makefile: generate CMake toolchain file in $(O)

[Bjørn Forsman]

Hi,

Sorry for the late reply.

2011/1/11 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Mon, 10 Jan 2011 19:30:16 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> Yes, I'll add that, thanks! I guess it only matters for the target
>> build and not native build (we don't strip HOST_DIR do we?), but I
>> think I'll add it to native build anyway, for consistency.
>
> I had another two problems with the CMake toolchain file. The first is
> that the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS variables were not taken
> into account. It's more or less explained at
> http://www.mail-archive.com/cmake at cmake.org/msg33248.html why this
> happens. The second problem is that --sysroot was missing at link time,
> so I had to add CMAKE_EXE_LINKER_FLAGS as well.
>
> So I have the following changes:
>
> diff --git a/Makefile b/Makefile
> index 994dd52..b154007 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -378,8 +378,9 @@ $(O)/toolchainfile.cmake:
> ? ? ? ?set(CMAKE_PROGRAM_PATH $(HOST_DIR)/usr/bin)\n\
> ? ? ? ?set(CMAKE_C_COMPILER $(CMAKE_TARGET_CC))\n\
> ? ? ? ?set(CMAKE_CXX_COMPILER $(CMAKE_TARGET_CXX))\n\
> - ? ? ? set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\")\n\
> - ? ? ? set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\")\n\
> + ? ? ? set(CMAKE_C_FLAGS \"$(CMAKE_TARGET_CFLAGS)\" CACHE STRING \"\" FORCE)\n\
> + ? ? ? set(CMAKE_CXX_FLAGS \"$(CMAKE_TARGET_CXXFLAGS)\" CACHE STRING \"\" FORCE)\n\
> + ? ? ? set(CMAKE_EXE_LINKER_FLAGS \"$(CMAKE_TARGET_LDFLAGS)\" CACHE STRING \"\" FORCE)\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH $(STAGING_DIR))\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)\n\
> ? ? ? ?set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)\n\
> diff --git a/package/Makefile.cmake.in b/package/Makefile.cmake.in
> index 08a0395..ce50b10 100644
> --- a/package/Makefile.cmake.in
> +++ b/package/Makefile.cmake.in
> @@ -41,6 +41,7 @@ CMAKE_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
> ?CMAKE_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
> ?CMAKE_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
> ?CMAKE_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX)) $(TARGET_CXXFLAGS)
> +CMAKE_TARGET_LDFLAGS = $(filter --sysroot=%,$(TARGET_LD)) $(TARGET_LDFLAGS)

The FORCE stuff seems like a good idea, thanks!

Hm... I've been thinking about --sysroot, -I and -L flags in the
toolchain-file lately. AFAIK, any CMake package should be able to
build perfectly without manually specifying these flags. Actually, I
would go so far as saying that passing -I, -L (or --sysroot) may hide
bugs in CMakeLists.txt files because a package should use FIND_XXX()
macros and not depend on -I, -L or --sysroot.

However, my impression is that not all CMake packages are looking for
headers and libs using FIND_XXX() and actually relies on -I, -L flags
(or built-in compiler config) to build. Thus, it may be easier to add
these flags to the CMake infrastructure than to fix the packages. But I
think it is a bit of a hack/workaround...

CMAKE_C_FLAGS is a bit special because it includes not only (unneeded)
-I flags, but some important flags such as the -march flag. So we at
least need some way to get -march into the compiler line and using the whole
TARGET_CFLAGS is an easy way to do that. CMAKE_EXE_LINKER_FLAGS
is just -L flags, so this is IMO just a workaround broken packages...

There is also the possibility to pass CMAKE_EXE_LINKER_FLAGS as
<PKG>_CONF_OPT in each broken package.

What do you think?

Best regards,
Bj?rn Forsman

[Buildroot] [PATCH 4/4] cdrkit: convert to CMAKETARGETS infrastructure

[Bjørn Forsman]

Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
---
 package/cdrkit/cdrkit.mk |   60 ++-------------------------------------------
 1 files changed, 3 insertions(+), 57 deletions(-)

diff --git a/package/cdrkit/cdrkit.mk b/package/cdrkit/cdrkit.mk
index a0ce9cb..fd3af24 100644
--- a/package/cdrkit/cdrkit.mk
+++ b/package/cdrkit/cdrkit.mk
@@ -11,61 +11,7 @@ else
 CMAKE_ENDIAN_OPT=-DBITFIELDS_HTOL=0
 endif
 
-# CMake doesn't support having the --sysroot option directly in the
-# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
-CDRKIT_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
-CDRKIT_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
-CDRKIT_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
-CDRKIT_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX)) $(TARGET_CXXFLAGS)
-
-define CDRKIT_CONFIGURE_CMDS
- -mkdir $(@D)/build
- (cd $(@D)/build ; \
-	$(HOST_DIR)/usr/bin/cmake .. \
-		-Wno-dev \
-		-DCMAKE_SYSTEM_NAME:STRING="Linux" \
-		-DCMAKE_C_COMPILER:FILEPATH="$(CDRKIT_TARGET_CC)" \
-		-DCMAKE_CXX_COMPILER:FILEPATH="$(CDRKIT_TARGET_CXX)" \
-		-DCMAKE_C_FLAGS:STRING="$(CDRKIT_TARGET_CFLAGS)" \
-		-DCMAKE_CXX_FLAGS:STRING="$(CDRKIT_TARGET_CXXFLAGS)" \
-		-DCMAKE_EXE_LINKER_FLAGS:STRING="$(TARGET_LDFLAGS)" \
-		-DCMAKE_MODULE_LINKER_FLAGS:STRING="$(TARGET_LDFLAGS)" \
-		-DCMAKE_SHARED_LINKER_FLAGS:STRING="$(TARGET_LDFLAGS)" \
-		-DCMAKE_FIND_ROOT_PATH:PATH="$(STAGING_DIR)" \
-		-DCMAKE_INSTALL_PREFIX:PATH="$(TARGET_DIR)/usr" \
-		$(CMAKE_ENDIAN_OPT) \
- )
-endef
-
-define CDRKIT_BUILD_CMDS
- $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build
-endef
-
-define CDRKIT_INSTALL_TARGET_CMDS
- $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build install
-endef
-
-define HOST_CDRKIT_CONFIGURE_CMDS
- -mkdir $(@D)/build
- (cd $(@D)/build ; \
-	$(HOST_DIR)/usr/bin/cmake .. \
-		-Wno-dev \
-		-DCMAKE_C_FLAGS="$(HOST_CFLAGS)" \
-		-DCMAKE_EXE_LINKER_FLAGS:STRING="$(HOST_LDFLAGS)" \
-		-DCMAKE_MODULE_LINKER_FLAGS:STRING="$(HOST_LDFLAGS)" \
-		-DCMAKE_SHARED_LINKER_FLAGS:STRING="$(HOST_LDFLAGS)" \
-		-DCMAKE_INSTALL_PREFIX:STRING="$(HOST_DIR)/usr" \
- )
-endef
-
-define HOST_CDRKIT_BUILD_CMDS
- $(HOST_MAKE_ENV) $(MAKE) -C $(@D)/build
-endef
-
-define HOST_CDRKIT_INSTALL_CMDS
- $(HOST_MAKE_ENV) $(MAKE) -C $(@D)/build  install
-endef
-
-$(eval $(call GENTARGETS,package,cdrkit))
-$(eval $(call GENTARGETS,package,cdrkit,host))
+CDRKIT_CONF_OPT += $(CMAKE_ENDIAN_OPT)
 
+$(eval $(call CMAKETARGETS,package,cdrkit))
+$(eval $(call CMAKETARGETS,package,cdrkit,host))
-- 
1.7.1

[Buildroot] [PATCH 4/4] cdrkit: convert to CMAKETARGETS infrastructure

[Samuel Martin]

Hi Bj?rn,

So easy using this framework! :)

Regards,

Samuel

2010/12/12 Bj?rn Forsman <bjorn.forsman@gmail.com>

> Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
> ---
>  package/cdrkit/cdrkit.mk |   60
> ++-------------------------------------------
>  1 files changed, 3 insertions(+), 57 deletions(-)
>
> diff --git a/package/cdrkit/cdrkit.mk b/package/cdrkit/cdrkit.mk
> index a0ce9cb..fd3af24 100644
> --- a/package/cdrkit/cdrkit.mk
> +++ b/package/cdrkit/cdrkit.mk
> @@ -11,61 +11,7 @@ else
>  CMAKE_ENDIAN_OPT=-DBITFIELDS_HTOL=0
>  endif
>
> -# CMake doesn't support having the --sysroot option directly in the
> -# compiler path, so move this option to the CFLAGS/CXXFLAGS variables.
> -CDRKIT_TARGET_CC = $(filter-out --sysroot=%,$(TARGET_CC))
> -CDRKIT_TARGET_CXX = $(filter-out --sysroot=%,$(TARGET_CXX))
> -CDRKIT_TARGET_CFLAGS = $(filter --sysroot=%,$(TARGET_CC)) $(TARGET_CFLAGS)
> -CDRKIT_TARGET_CXXFLAGS = $(filter --sysroot=%,$(TARGET_CXX))
> $(TARGET_CXXFLAGS)
> -
> -define CDRKIT_CONFIGURE_CMDS
> - -mkdir $(@D)/build
> - (cd $(@D)/build ; \
> -       $(HOST_DIR)/usr/bin/cmake .. \
> -               -Wno-dev \
> -               -DCMAKE_SYSTEM_NAME:STRING="Linux" \
> -               -DCMAKE_C_COMPILER:FILEPATH="$(CDRKIT_TARGET_CC)" \
> -               -DCMAKE_CXX_COMPILER:FILEPATH="$(CDRKIT_TARGET_CXX)" \
> -               -DCMAKE_C_FLAGS:STRING="$(CDRKIT_TARGET_CFLAGS)" \
> -               -DCMAKE_CXX_FLAGS:STRING="$(CDRKIT_TARGET_CXXFLAGS)" \
> -               -DCMAKE_EXE_LINKER_FLAGS:STRING="$(TARGET_LDFLAGS)" \
> -               -DCMAKE_MODULE_LINKER_FLAGS:STRING="$(TARGET_LDFLAGS)" \
> -               -DCMAKE_SHARED_LINKER_FLAGS:STRING="$(TARGET_LDFLAGS)" \
> -               -DCMAKE_FIND_ROOT_PATH:PATH="$(STAGING_DIR)" \
> -               -DCMAKE_INSTALL_PREFIX:PATH="$(TARGET_DIR)/usr" \
> -               $(CMAKE_ENDIAN_OPT) \
> - )
> -endef
> -
> -define CDRKIT_BUILD_CMDS
> - $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build
> -endef
> -
> -define CDRKIT_INSTALL_TARGET_CMDS
> - $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build install
> -endef
> -
> -define HOST_CDRKIT_CONFIGURE_CMDS
> - -mkdir $(@D)/build
> - (cd $(@D)/build ; \
> -       $(HOST_DIR)/usr/bin/cmake .. \
> -               -Wno-dev \
> -               -DCMAKE_C_FLAGS="$(HOST_CFLAGS)" \
> -               -DCMAKE_EXE_LINKER_FLAGS:STRING="$(HOST_LDFLAGS)" \
> -               -DCMAKE_MODULE_LINKER_FLAGS:STRING="$(HOST_LDFLAGS)" \
> -               -DCMAKE_SHARED_LINKER_FLAGS:STRING="$(HOST_LDFLAGS)" \
> -               -DCMAKE_INSTALL_PREFIX:STRING="$(HOST_DIR)/usr" \
> - )
> -endef
> -
> -define HOST_CDRKIT_BUILD_CMDS
> - $(HOST_MAKE_ENV) $(MAKE) -C $(@D)/build
> -endef
> -
> -define HOST_CDRKIT_INSTALL_CMDS
> - $(HOST_MAKE_ENV) $(MAKE) -C $(@D)/build  install
> -endef
> -
> -$(eval $(call GENTARGETS,package,cdrkit))
> -$(eval $(call GENTARGETS,package,cdrkit,host))
> +CDRKIT_CONF_OPT += $(CMAKE_ENDIAN_OPT)
>
> +$(eval $(call CMAKETARGETS,package,cdrkit))
> +$(eval $(call CMAKETARGETS,package,cdrkit,host))
> --
> 1.7.1
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101213/7f4f31ae/attachment.html>