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

[Bill Spitzak]

On 05/19/2014 11:55 PM, Pekka Paalanen wrote:

> What is the target audience of the build guide?

Somebody who wants to contribute to wayland.

I have been writing Linux software in C/C++ and OpenGL for about 20 
years now, including making my own autoconf scripts. I have to tell you 
that these dependencies are almost a complete brick wall to anybody who 
is not a libtool/pkg-config expert. I never even heard of these commands 
before. This is very frustrating and will make people give up on working 
on Wayland. From several emails posted here it is obvious I am not 
alone, and those people never sent any other emails so I think they gave up.

> What we at upstream need to do, is to make sure that the complaints
> from configure are understandable.

The biggest hint would be to print something with the word "pkg-config" 
in it. Then I would have the secret password that would lead me to a man 
page that would tell me what is going on.

Please print the package name the error was in (ie the name of the pc file).

The actual git repository name would help too.

pkg-config has an awful lot of bugs and gnu-isms, fixing them would help:

1. If I type "pkg-config --verision foo" I want the version of foo. Or 
an error message. Don't print the pkg-config version. Holy crap.

2. Add an option to print where it found the .pc file! Right now I have 
to run --debug and pick it out of the output.

3. Fix the stupid "add the directory containing 'foo.pc' to 
PKG_CONFIG_PATH" error message. That is *NEVER* what is wrong. A better 
one is "foo.pc not found in any of ~/install/lib/pkgconfig, ..."

4. Make -h print the same thing as --help.

> The question "what package in distribution Foo provides laalaa.pc?" is
> usually best answered by Google...

I did use Google and I never found such a site. Note that any searches 
are going to overwhelmingly be for people trying to *run* software, not 
compile it, and the answers are not that useful.

By far the most useful secret tidbit I found was that you type 
"apt-cache search xyz" to find matching packages, and "apt-cache show 
libxyz-dev" to (maybe) get the version number in it without installing.
I used these commands in the end for most everything, along with 
searching on the top page of git.freedesktop.org.

> I think a verbal description instead of commands would be better,
> because it is plain English. When you write commands, you assume that
> the reader knows what those commands do, and realizes he may need to
> adjust the package names.

The plain english is going to include distribution-specific package 
names so I think is misleading. Actually I may not understand what you 
are requesting. If I have figured out that on Ubunto to fix errors with 
pam I need "libpan0g-dev" installed, how do I say that?

> I still think we should keep the Wayland web site instructions mostly
> generic, at least the main build guide, and have another page or
> external site for distribution specfic guides.

It's just that that is a lot harder than pasting "here are the commands 
that worked on this distribution and I hope they provide a hint for 
other distributions". I think altering the text so that it makes it a 
puzzle for all distributions is both a waste of time on the editor's 
part and is not helping anybody.

If somebody fixes something by using yum I see no problem with putting 
the literal yum command in there.

> It is a question of maintenance, and who gets the blame when the page
> goes out of date.

The page is completely out of date now so I don't think anybody is 
worried about blame.

Yes I know that withing 1 or 2 days Mesa will change and add yet another 
dependency. I was hoping to just add the commands as I discover these. 
Having to edit the commands into distribution-agnostic versions is 
rather annoying.

> Also the process of editing the Wayland web site is much more involved
> than e.g. a wiki has, so it is more likely end users don't bother
> contributing.

True. But again it is obscure. Until you pointed it out I did not know 
there was a wayland-web repository. That information maybe should be at 
the bottom of the index page.

>> I removed the $ signs so that multiple lines could be cut & pasted to a
>> terminal.
>
> I think you don't want to paste multiple commands in one go. If one
> fails, the following will fail even harder, and maybe obscure the first
> error.

I have to tell you that such one-line-at-a-time cut & paste is 
unbelievably tedious, and my biggest screwups when trying this on a 
second machine was when I missed the slight variations in the autogen 
lines because I was using uparrow to re-run the commands from the last 
repository. That convinced me to remove the $ signs, although I agree 
with you that it is not as nice looking.

I considered joining all the lines together with && but I am not sure 
that is a good idea.

>> Previously I have compiled without setting any of the ACLOCAL variables
>> at all, and it worked (at least as well as this), so I'm wondering if
>> they really are necessary.
>
> They are likely necessary for anything that still uses
> wayland-scanner.m4.

Looks like xorg-macros.m4 and xtrans.m4 are also put in there.

It looks like I was wrong about it working if ACLOCAL is not set. The 
git repositories that make these files fail to install. Others don't 
care however.

>>>> +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.

> Do you think we can keep this guide up-to-date? Would you commit to
> that?

Sure, if I am allowed to put in what worked on Ubuntu 12.04 (or whatever 
I am using). Yes this means I may say you have to compile something from 
git when a package might work on your system, and I will provide the 
name that Ubuntu happened to name a package.

> Another idea: keep the main build guide short, but have another page
> for "configure failed with .... " sections with hints how to solve it.
> That way people only need to read what they actually require.
>
> I'd like to avoid manual building of dependencies for which the
> distribution packages would be just fine.

The problem is that I have lost the information about exactly what 
configure said. I only recorded how I fixed the problems.

Generally the error and the solution share some words in common, so it 
may be ok to just list the solutions *after* the configure line. The 
user can then make a pretty reliable guess what solution matches the 
error they got.

It's hard to say when a something is a solution or a required step. For 
instance you seem pretty certain that libxkbcommon must be required, but 
I could in fact figure that out from compilation errors. It could just 
say to build weston, followed by listing all the things you may need to 
make configure work, including wayland.

I am also concerned about discovering a requirement (like xcb) in a 
later step that then causes you to have to recompile an earlier step (ie 
so mesa uses the same version of stuff as xserver).

>> I did have --disable-dri3 in there for a while, but eventually the
>> xserver required most of the same packages as mesa, so I removed that,
>> wanting to configure mesa exactly like you are doing.
>
> Maybe worth re-checking, if building only the Xwayland servers gets rid
> of some of those.

I did not explain that correctly.

I did avoid compiling xcb for a long time, by using --disable-dri3 on 
mesa. However the most recent xserver seems to have changed and suddenly 
requires the xcb proto files compiled from git. This removed 3 of the 4 
dri3 missing dependencies, and libxshmfence was easy to fix, so I 
thought it best to re-add it.

This does mean that dependencies that were really required for xserver 
had to be moved before mesa.

>>> I'm not sure should tell people to use --disable-llvm-shared-libs,
>>
>>   From what I read on the web it is a problem with the llvm packages. I
>> feel like this is not fixable without recompiling llvm from source...
>
> In a specfic distribution, right?

I cannot figure out what is wrong from what I learned on the web. They 
all claim a symbolic link will fix it. And there are .so files there. 
But it does not look like enough (or large enough) .so files, and I was 
unable to find out the actual name of the missing symbolic link.

That said, the configure error was pretty clear on how to fix it. So a 
comment saying you may need to add this is ok. Actually I have no idea 
how bad this problem is, do you know?

>> I also discovered that it does not complain about a missing llvm if you
>> remove the r300 driver. However I think this also silently removed all
>> shader compilation from all backends, right?
>
> Err, I don't know. I wouldn't think so. Something has to build the
> shaders, but I'm not sure what.

That's what I was asking. If I uninstall llvm, and remove r300 from the 
autogen line, the mesa configure runs. However it says "no" for LLVM in 
the output. My guess is that it silently disabled the shaders, which 
would be bad.

Therefore instead of removing r300, I went through the trouble of 
getting it to work with llvm.

>>> Distribution specifics. Just drop the Cairo and Pixman parts.
>>
>> The versions included with my system have bugs that I thought were bugs
>> in wayland or the wayland xserver. It might be a good idea that people
>> don't see such errors the first time they run it.
>
> Did these bugs appear with cairo-image, or cairo-gl only? If cairo-gl
> only, then we can just forget about it. If cairo-image is affected, we
> should consider bumping the version requirements in Weston's
> configure.ac.

It is cairo-image.

The bug is pretty obvious in xserver output. Gradients in the shadow and 
parts of the frame are backwards or missing.

I have cairo 1.10.2 installed, while the git repository that works is at 
1.13.1. So the cutoff is somewhere in there.

>>>> +PATH=$WLD/bin:$PATH ./autogen.sh --prefix=$WLD --disable-setuid-install

> Yes indeed. Now it seem like the PATH is actually the better way, and
> it would also work without patching Weston, so I take that back. You
> could add PATH into the generic environment setup section.

Is there a recommended way to add to the path so that it does nothing if 
the directory is already there? It can be bash-specific like the 
$XDG_RUNTIME_DIR stuff is. I would like to allow the user to re-run 
commands.