Since some CMake modules (even upstream ones) use pgk_check_modules
primitives to find {C,LD}FLAGS, add it to the dependency list.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the trailing slash is stripped from $($(PKG)_SITE) by pkg-generic.mk:
$(call DOWNLOAD,$($(PKG)_SITE:/=)/$($(PKG)_SOURCE))
so it is redundant.
This patch removes it from $(PKG)_SITE variable for BR consistency.
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To speedup building disable ccmake because it's not needed by buildroot.
Also disabling ccmake get rid of the ncurses optional unspecified
dependency for the sake of reproducible builds.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Alexander Potashev <aspotashev@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
During the CMake bootstrap phase, the {C,LD}FLAGS set in the bootstrap
environment are not forwarded/converted as CMake flags.
The CMake build contains a bootstrap phase building a minimal CMake
program using a standard Makfile, then reconfigures itself with this
minimal program.
On system with no ncurses installed, and because the prefix option
points to $(HOST_DIR)/usr, if host-cmake was built after host-ncurses,
then ncurses libraries and headers are correctly found (in the host
tree) during the second configuration (because of the prefix). However,
it fails at building ccmake (the curses interface) because the
CMAKE_C_FLAGS, CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS do not
point to the host tree.
Because these flags are needed when running the bootstrap script,
this patch makes sure the same flags are set when running the second
configuration.
Reported-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The dummy target package is not needed anymore since commit 79bfcd5560.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thanks to the pkgparentdir and pkgname functions, we can rewrite the
GENTARGETS macro in a way that avoids the need for each package to
repeat its name and the directory in which it is present.
[Peter: pkgdir->pkgparentdir]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The FindQt4 module of CMake insists on having uic, even if the QtGui
module isn't part of the requirements to build the program. This isn't
correct, as Qt doesn't build/install the uic program when QtGui is
disabled (uic is used to generate some UI code).
This has been fixed upstream in
http://cmake.org/gitweb?p=cmake.git;a=commit;h=43cb9b8276a70d153d56a69d5c61daaf2bc51b78. This
commit will be part of the upcoming 2.8.4 CMake release, but in the
mean time, let's include it in Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Passing LDFLAGS/CFLAGS when building for the host allows cmake to be
compiled with the proper -rpath value (the -rpath option is added to
HOST_LDFLAGS in a later commit).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Only compilation for the host is supported, why explains why we don't
have a Config.in and the corresponding BR2_PACKAGE_CMAKE option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
