qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] PPC: Fail configure when libfdt is not availabl


From: Alexander Graf
Subject: Re: [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.


Alex




reply via email to

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