[PATCH wayland-web] Added depencies and bug fixes to build instructions

[Bill Spitzak]

On 05/21/2014 02:30 AM, Pekka Paalanen wrote:

> But pkg-config is *the* standard way of finding build dependencies
> during a build. How can you not know about it?

I never used it before and have not encountered it until I tried to 
compile freedesktop.org stuff. Configure was done by testing for the 
existence of files, or making code samples and attempting to compile 
them. Or things were just deferred until compile, when it could produce 
errors if the header file did not exist or defined too old of a version.

I'm not entirely sold on this new system. It seems very fragile since 
the version is stored in different files and different directories than 
the actual code. I would have preferred if the information resided in 
the same directory (and search path) as the includes or libraries.

> It already does print these. I removed the wayland-client.pc and tried
> to configure weston, resulting to this:
>
> -----
> checking for EGL_TESTS... no
> configure: error: Package requirements (egl >= 7.10 glesv2 wayland-client wayland-egl) were not met:
>
> No package 'wayland-client' found
> Package 'wayland-client', required by 'wayland-egl', not found
>
> Consider adjusting the PKG_CONFIG_PATH environment variable if you
> installed software in a non-standard prefix.
>
> Alternatively, you may set the environment variables EGL_TESTS_CFLAGS
> and EGL_TESTS_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.

A lot of the config files print this instead:

Package arrgh was not found in the pkg-config search path.
Perhaps you should add the directory containing `arrgh.pc'
to the PKG_CONFIG_PATH environment variable
No package 'arrgh' found

That does contain the word "pkg-config" but I can tell you I did not 
read that at all as a command name.

The instructions from the web for setting PKG_CONFIG_PATH seemed to be 
the biggest hint but the obvious system-wide directories did not seem to 
exist (this was due to the system using /usr/lib64 at that time, it is 
better on Ubuntu 12.04).

The next hint was that the missing file ended in ".pc". This was the 
first usable clue, I did a find of all such files, cat of those gave me 
some hints as to what is going on.

Of course the directory was called "pkgconfig" and not "pkg-config" and 
every other piece of documentation and web searches I could find 
indicated that the program I wanted was called "libtool". I'm not sure 
what happened after that, but I can certainly believe a lot of 
programmers will have given up before they figured it out.

> Would that not cause the main build guide to become a mixture of
> apt-get, emerge, yum, pacman, aptitude etc. commands? Where the
> complete set of commands would never work on any single distribution,
> because there are always some commands for a different distribution?

Yea maybe. All I want is a hint that "you will probably need to install 
this thing, and here is a possible name for it, before the next step 
will work".

The separate Ubuntu-specific page sounds like a mutually-acceptable 
solution. However I suspect nobody can possibly compile wayland from 
scratch without referring to some of the info in that page.

>>>>>> +sudo apt-get install libpciaccess-dev <font color=#800># needed by drm</font>
>>
>>> Are you sure it is needed?
>>>
>>> Nothing in Weston refers to pciaccess.h or pciaccess.pc.
>>
>> The configure for drm required it.
>
> You mean libdrm? Weston's DRM backend does not need it. It is usually
> Mesa that requires an updated libdrm.

Yes Mesa is the one that required drm. However I was doing this mostly 
because drm was in the original wayland-web instructions page. It sounds 
like this should be removed from the main build directions, similar to 
xkbcommon and cairo?

BTW: Mesa requires 2.4.52 while Ubuntu 12.04 supplies 2.4.46, so I need it.

> Yeah, nowadays Weston can work with a released version of xkbcommon, so
> we could remove the git-clone part, and have a link to its home page.
>
> Collecting links to depended-on projects' home pages would be nice in
> the generic guide.

To be consistent it seems like any package where the necessary version 
has been "released" should not be listed with build instructions, as it 
may be possible on somebody's machine to compile without it.

I think the minimal on a fully-up-to-date system is this:

   wayland (on the assumption that you may want to hack it)
   mesa (because it depends on wayland)
   libinput
   weston
   xserver (because it depends on wayland)

Is this correct? Should mesa and xserver even be removed? They probably 
work even if compiled with an older wayland, right?

 From the original build directions this removes drm, libkbdcommon, 
cairo and pixman, and I think a few others.

> Ok, right. So we probably would like to have a note in the Weston build
> guide at the right point, that if you intend to install Xwayland, now
> would be the right time (before Mesa).

Yes that sounds about right.

> I think that would be left for the user. PATH is such a well-known
> concept. Here clarity on what is added is more important than
> optimization. This is what we already do with LD_LIBRARY_PATH and
> PKG_CONFIG_PATH, we ignore what they might already contain.

Good point, so it is probably ok to do it with PATH too.