Compiling weston now needs colord

Pekka Paalanen ppaalanen at gmail.com
Tue Jun 4 00:29:38 PDT 2013


On Mon, 3 Jun 2013 11:44:25 -0700
"Othman, Ossama" <ossama.othman at intel.com> wrote:

> 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<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 think one could take that argument and turn it upside down. What is
'make distcheck' supposed to check? Should it not fail hard, if
something cannot be checked? If it fails hard by default, that is a
nudge for the developer to install the dependencies, so that he can
validate his changes to the fullest. Of course, that needs an opt-out,
a way to tell distcheck that one is not interested in testing the e.g.
colord related code. But I think it should be an opt-out, not opt-in or
automatic.

Optionality is good for end users and distros building stuff, but
making it automatic makes it easy for developers to just ignore
testing some bits. :-)


Cheers,
pq


More information about the wayland-devel mailing list