Compiling weston now needs colord

[Armin K.]

http://lists.freedesktop.org/archives/wayland-devel/2013-May/009554.html

Next time check list before taking time to duplicate the effort. 

----- Original Message -----
From: Othman, Ossama
Sent: 06/03/13 08:44 PM
To: sardemff7+wayland at sardemff7.net
Subject: Re: Compiling weston now needs colord
 Hi, On Thu, May 30, 2013 at 12:42 AM, <sardemff7+wayland at sardemff7.net> wrote:On 30/05/2013 08:24, Michael Hasselmann wrote:On Tue, 2013-05-28 at 22:16 -0700, Bill Spitzak wrote:Running autogen.sh in weston with --disable-colord works to avoid this,
I suspect nothing I care about is lost this way.
I ran into the very same problems. I would have preferred if such new
dependencies were optional or if someone would explain what we will miss
if we disable them. For colord, trying to build the latest required
version from git just pulls in more dependencies that you also have to
build from git (as Bill mentioned).

It's kind of frustrating, even if weston is meant to be a playground and
thus new dependencies have to be expected.

http://wayland.freedesktop.org/building.html should be updated I guess?

ciao Michael
colord is an optional dependency: you just need to pass --disable-colord to ./configure (or ./autogen.sh), and it is gone. Making the configure script have a hard failure by default if colord is unavailable is not consistent with the dependency being optional.  Even if --disable-colord is added to the configure/autogen.sh command line "make distcheck" will still fail on platforms without colord installed since the configure script flags are not passed down.  One could tweak the flags passed to the distcheck target using AM_DISTCHECK_CONFIGURE_FLAGS and DISTCHECK_CONFIGURE_FLAGS but that would be hack. I think it would be better to issue a warning if colord wasn't found rather than error out, or flip the logic so that the user must enable colord support, and only then error out.  The same goes for libunwind. I just submitted a patch that causes a missing colord or libunwind to issue a warning rather than error out. It is not an automagic dependency (which automatically detect the package’s presence), because it is more work for the developer to add the autotools logic to do so. Also, it is much more work to make packagers happy (packagers hate automagic dependencies, it makes either more work by patching or hard-dependency on optional features).

A little configure switch, and you are done, nothing to complain about. :-) The configure switch in question doesn't appear to be enough to keep some of us from complaining.  :) Thanks,-Ossama