The following changes allow for use of a central configure cache
file. This speeds up configuration of packages.
Its use is configurable at the top level (BR2_CONFIG_CACHE - default n).
Old style makefiles can use it if they use the following MACRO in makefiles:
$(AUTO_CONFIGURE_TARGET) see my change to directfb.mk.
New style Autotools.in will use it if you set the global option.
However you can enable the global option and on a per package overrule it by doing
the following: $(PKGNAME)_USE_CONFIG_CACHE = NO see fontconfig.mk for an example
of this.
Finally I have removed a few config variable settings which indicated no CXX compiler
as this is wrong and breaks the build when using this central cache.
Config.in | 8 ++++++++
package/Makefile.autotools.in | 5 ++++-
package/Makefile.in | 28 +++++++++++++++++++++++++++-
package/atk/atk.mk | 2 +-
package/directfb/directfb.mk | 7 +------
package/fontconfig/fontconfig.mk | 3 +++
package/libglib2/libglib2.mk | 2 +-
package/libgtk2/libgtk2.mk | 1 -
8 files changed, 45 insertions(+), 11 deletions(-)
I would appreciate feedback on this change (I have been testing for 2-3 weeks)
But I can never test all cases! If you enable the BR2_CONFIG_CACHE option some
Makefile.autotools.in based packages may now break - I cannot build them all.
In this case you may need to remove config options that are being hardcoded all
over the place (like gtk saying we have 2 CXX compiler) or disable the use
of CONFIG CACHE file like I have done in fontconfig.
I can build all packages required to get WebKit on DirectFB up and running
and it runs fine.
I will try to resolve any issues this creates as fast as I can.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
The id applet in 1.13.0 only compiles with uclibc < 0.9.30 if the
busybox internal passwd/grp functions are used.
Therefore, automatically enable CONFIG_USE_BB_PWD_GRP if that situation
is detected and warn the user.
Prepare for the merge of audio and video packages. Many packages cannot
properly be assigned to either audio or video, because they have support
for both (libogg, mplayer, vlc).
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Also remove --enable-shared and --enable-static as it's default
and --disable-oggtest and $(DISABLE_NLS) as they are not supported.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
This patch adds a patch to fix bug
https://bugs.freedesktop.org/show_bug.cgi?id=16464 affecting parallel
compilation of fontconfig.
The patch is the one proposed in the bugzilla entry, available at
https://bugs.freedesktop.org/attachment.cgi?id=17294.
Without this patch, the compilation (at BR2_JLEVEL > 1) of fontconfig
sometimes fails with:
In file included from fc-case.c:25:
../src/fcint.h:118:21: error: fcalias.h: No such file or directory
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch fixes two Qtopia build issues, encountered while trying to
use system implementation of zlib, freetype, jpeg and libpng :
* The build process doesn't look in $(STAGING_DIR)/usr/include for
includes and $(STAGING_DIR)/usr/lib. Same problem as the patch
currently floating around adding LDFLAGS to TARGET_CONFIGURE_OPTS,
but as Qtopia doesn't use TARGET_CONFIGURE_OPTS, we need a specific
fix here. So we use the -I and -L options of Qtopia's configure
script.
* The build process doesn't use pkg-config to get the header path for
Freetype headers (located in $(STAGING_DIR)/usr/include/freetype2
and not directly in $(STAGING_DIR)/usr/include/). There was already
a fix for this, consisting in adding $(FREETYPE_DIR)/include to the
-I path of Qtopia's configure. This patch modifies this fix to use
$(STAGING_DIR)/usr/include/freetype2 instead, which looks more
coherent with how all the packages are built (using $(STAGING_DIR)
as the reference to get headers and libraries).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch is a new version of a patch already sent several times on
the mailing-list, committed and reverted a few times by Daniel Laird,
due to several imperfections. This version is a new try at finding a
solution that works for everybody. Hopefully it'll work :-)
The original problem is that external toolchain builds failed because
packages couldn't find their dependent libraries at configure time and
could not be linked with them. To fix these two problems, two things
are added:
* The TARGET_LDFLAGS variable was exposed as LDFLAGS at ./configure
time thanks to TARGET_CONFIGURE_OPTS. The TARGET_LDFLAGS variable
contains -L options with the path in the STAGING_DIR for the
libraries. It allows ./configure scripts to properly compile the
small test programs testing whether a dependency is properly
installed.
* The TARGET_CFLAGS contains a new -Wl,--rpath-link option for both
$(STAGING_DIR)/lib and $(STAGING_DIR)/usr/lib. It allows library
depending on other libraries to link properly. The TARGET_CFLAGS is
exposed as CFLAGS in TARGET_CONFIGURE_OPTS.
This new version fixes a problem encountered by hartleys
<hartleys@visionengravers.com> when building the kernel. The problem
was that the -Wl,--rpath-link options were added to LDFLAGS, while
there are options for the C compiler, not the ld linker. Moving them
to CFLAGS seems to fix the issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bounce tiff into Autotools.in format.
Did not use install to target as this puts loads of executables into TARGET.
So just copied tiff.so instead.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
Looking into adding a configure cache to the build (like the GIT buildroot version)
This means that freetype needs to know about zlib so make
sure it had it as a dependency.
Also remove install rule for staging as it matches default.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
The following patch makes the MESSAGE Macro in Makefile.autotools.in
work.
I think it was originally intended to print the messages in bold type
but it doesn't appear to work correctly. This patch should work on all
platforms.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
(Fixed to not continously call tput)
Revert the rpath patch, it looked good up until someone tried
to build a kernel as well. This seems to break as a result.
Will post a new patch soon and see how that goes..
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
Apply the patch I posted some time ago that fixes
rpath issues with external toolchains.
Has been tested by users of buildroot and feedback looks good.
Signed-off-by: Thomas Petazzoni
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>