[Buildroot] svn commit: trunk/buildroot/package/cairo

[Buildroot] svn commit: trunk/buildroot/package/cairo

[thomasez at uclibc.org]

Author: thomasez
Date: 2009-01-12 15:22:41 +0000 (Mon, 12 Jan 2009)
New Revision: 24801

Log:
Fix dependencies.


Modified:
   trunk/buildroot/package/cairo/Config.in
   trunk/buildroot/package/cairo/cairo.mk


Changeset:
Modified: trunk/buildroot/package/cairo/Config.in
===================================================================
--- trunk/buildroot/package/cairo/Config.in	2009-01-12 15:10:04 UTC (rev 24800)
+++ trunk/buildroot/package/cairo/Config.in	2009-01-12 15:22:41 UTC (rev 24801)
@@ -3,6 +3,7 @@
 	select BR2_PACKAGE_PKGCONFIG
 	select BR2_PACKAGE_LIBPNG
 	select BR2_PACKAGE_ZLIB
+	select BR2_PACKAGE_PIXMAN
 	select BR2_PACKAGE_FONTCONFIG
 	depends on BR2_PACKAGE_XORG||BR2_PACKAGE_XORG7||BR2_PACKAGE_TINYX||BR2_PACKAGE_DIRECTFB
 	help

Modified: trunk/buildroot/package/cairo/cairo.mk
===================================================================
--- trunk/buildroot/package/cairo/cairo.mk	2009-01-12 15:10:04 UTC (rev 24800)
+++ trunk/buildroot/package/cairo/cairo.mk	2009-01-12 15:22:41 UTC (rev 24801)
@@ -41,15 +41,13 @@
 		ac_use_included_regex=no gl_cv_c_restrict=no \
 		ac_cv_path_GLIB_GENMARSHAL=$(HOST_GLIB)/bin/glib-genmarshal
 
-CAIRO_CONF_OPT = --disable-gtk-doc --with-html-dir=/dev/null
 
 ifeq ($(BR2_PACKAGE_DIRECTFB),y)
-	CAIRO_CONF_OPT = --disable-xlib --without-x --enable-directfb \
-		--disable-gtk-doc --with-html-dir=/dev/null
+	CAIRO_CONF_OPT = --disable-xlib --without-x --enable-directfb
 	CAIRO_DEPENDENCIES_EXTRA = directfb
 endif
+CAIRO_CONF_OPT += --disable-gtk-doc --with-html-dir=/dev/null
 
+CAIRO_DEPENDENCIES = uclibc gettext libintl pkgconfig zlib libpng fontconfig $(CAIRO_DEPENDENCIES_EXTRA) pixman $(XSERVER) 
 
-CAIRO_DEPENDENCIES = uclibc gettext libintl pkgconfig libglib2 zlib libpng fontconfig $(CAIRO_DEPENDENCIES_EXTRA) pixman $(XSERVER) 
-
 $(eval $(call AUTOTARGETS,package,cairo))

[Buildroot] Some issues I have found in buildroot today.

[Daniel James Laird]

All,

I have found that libcurl is not properly dependent on host-sed so if I build this package alone it does not work.

I have also found that autoconf can not be built with multi jobs (i.e -j X).

I have also found that for external toolchains you cannot set that you have LOCALE/WCHAR support this limits options somewhat and means libiconv is always built and I would rather not do this.  Can anyone explain the LOCALE support options and what it means for an external toolchain instead of a uclibc built toolchain.

Hope people can help
Daniel Laird

[Buildroot] Some issues I have found in buildroot today.

[Peter Korsgaard]

>>>>> "Daniel" == Daniel James Laird <daniel.j.laird@nxp.com> writes:

Hi,

 Daniel> I have found that libcurl is not properly dependent on
 Daniel> host-sed so if I build this package alone it does not work.

And it needs it internally for the build?

 Daniel> I have also found that autoconf can not be built with multi
 Daniel> jobs (i.e -j X).

Ok, that should be fixable with a simple s/MAKE/MAKE1/

 Daniel> I have also found that for external toolchains you cannot set
 Daniel> that you have LOCALE/WCHAR support this limits options
 Daniel> somewhat and means libiconv is always built and I would
 Daniel> rather not do this.  Can anyone explain the LOCALE support
 Daniel> options and what it means for an external toolchain instead
 Daniel> of a uclibc built toolchain.

I guess the LOCALE stuff for external toolchain should just match what
the toolchain has, but I don't use the external stuff.

-- 
Bye, Peter Korsgaard

[Buildroot] Some issues I have found in buildroot today.

[Daniel James Laird]

My thoughts on the BR2_ENABLE_LOCALE were this:

Should the BR2_ENABLE_LOCALE options be moved from the uclibc/Config.in file so that they are globally available.  I could then set that I have a LOCALE enabled toolchain.  If I set that I did not have a LOCALE enabled toolchain then it would build libiconv like it does now.

Or do I just add the same options to the external-toolchain/Config.in?

Cheers,
Daniel Laird

-----Original Message-----
From: Peter Korsgaard [mailto:jacmet at gmail.com] On Behalf Of Peter Korsgaard
Sent: 2009 Jan 12 15:39
To: Daniel James Laird
Cc: buildroot at uclibc.org
Subject: Re: [Buildroot] Some issues I have found in buildroot today.

>>>>> "Daniel" == Daniel James Laird <daniel.j.laird@nxp.com> writes:

Hi,

 Daniel> I have found that libcurl is not properly dependent on
 Daniel> host-sed so if I build this package alone it does not work.

And it needs it internally for the build?

 Daniel> I have also found that autoconf can not be built with multi
 Daniel> jobs (i.e -j X).

Ok, that should be fixable with a simple s/MAKE/MAKE1/

 Daniel> I have also found that for external toolchains you cannot set
 Daniel> that you have LOCALE/WCHAR support this limits options
 Daniel> somewhat and means libiconv is always built and I would
 Daniel> rather not do this.  Can anyone explain the LOCALE support
 Daniel> options and what it means for an external toolchain instead
 Daniel> of a uclibc built toolchain.

I guess the LOCALE stuff for external toolchain should just match what
the toolchain has, but I don't use the external stuff.

-- 
Bye, Peter Korsgaard

[Buildroot] Some issues I have found in buildroot today.

[Peter Korsgaard]

>>>>> "Daniel" == Daniel James Laird <daniel.j.laird@nxp.com> writes:

Hi,

 Daniel> My thoughts on the BR2_ENABLE_LOCALE were this:

 Daniel> Should the BR2_ENABLE_LOCALE options be moved from the
 Daniel> uclibc/Config.in file so that they are globally available.  I
 Daniel> could then set that I have a LOCALE enabled toolchain.  If I
 Daniel> set that I did not have a LOCALE enabled toolchain then it
 Daniel> would build libiconv like it does now.

Again, I don't know anything about the external toolchain stuff, but
it seems like you should have something to set the LOCALE/WCHAR
settings with external toolchains.

How is that handled now?

 Daniel> Or do I just add the same options to the
 Daniel> external-toolchain/Config.in?

That afaik won't work - Kconfig will complain.

-- 
Bye, Peter Korsgaard