[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH] PPC: Fail configure when libfdt is n

From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] PPC: Fail configure when libfdt is not available
Date: Tue, 18 Oct 2011 19:08:53 -0700

On 18.10.2011, at 11:30, Blue Swirl wrote:

> On Tue, Oct 18, 2011 at 9:02 AM, Alexander Graf <address@hidden> wrote:
>> Am 18.10.2011 um 10:55 schrieb Andreas Färber <address@hidden>:
>>> Am 18.10.2011 02:18, schrieb Alexander Graf:
>>>> We have several targets in the PPC tree now that basically require libfdt
>>>> to function properly, namely the pseries and the e500 targets. This 
>>>> dependency
>>>> will rather increase than decrease in the future, so I want to make sure
>>>> that people building shiny new 1.0 actually have libfdt installed to get
>>>> rid of a few ifdefs in the code.
>>>> Warning: This patch will likely make configure fail for people who don't
>>>> select their own --target-list, but don't have libfdt development packages
>>>> installed. However, we really need this new dependency to move on.
>>>> Signed-off-by: Alexander Graf <address@hidden>
>>> openSUSE 12.1 has libfdt1-devel, but you should set up a submodule and
>>> working build rules for Darwin, Haiku, etc. `make` doesn't fully work so
>>> I used custom scripts to build the right parts and to manually "install"
>>> the resulting binary and headers.
>> I don't fully understand. It's a build dependency, so whoever maintains 
>> libfdt / is interested in running ppc targets on those OSs needs to fix 
>> libfdt to build there.
>> It's really the same as a dependency on glib or sdl or ... :). It's just 
>> less well known (and less active as a project).
> It's not available on Ubuntu or Debian and I doubt that compiled
> packages are available for OSX or Windows. OpenBSD does not have it in
> the ports. So I'd use submodule approach.

If we do a submodule, it will never get packaged. And then we'll practically 
have yet another fork of it :(. The submodule approach is reasonable for our 
binary blobs, sure. But this is a library and IMHO should be treated as such.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]