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

[Pekka Paalanen]

On Tue, 20 May 2014 13:12:32 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

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

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

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

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

It says exactly which .pc files are not found, and it tells you to look
at the pkg-config man page.

> The actual git repository name would help too.

We do not track the intended upstream git repositories. In some cases,
there are multiple implementations that each provide the same .pc file,
and we cannot tell you which one you particularly want.

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

No, the plain English should contain project names or pkg-config file
names, as those are as universal as it gets. A link to the project home
page, if it has one, is always a good thing.

> 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?

You'd put that in the ubuntu-specific guide.

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

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?

"This happened to work for me" is web forum stuff.

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

They are not meant to be copied repeatedly. Even basic common sense
says, that if you end up copying them more than once, it would probably
be worth to save them in a script.

If you manually do those commands every single time you open a new
terminal to work in, you are bound to miss something.

The commands are an example. They are the foundation on which you can
write your own environment setup.

OTOH, git-clone is ran only once. 'make' and 'make install' come from
the spine. autogen.sh/configure arguments are better saved in a script
if there are many of them like for Mesa, but you can always see them in
'head config.log', too.

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

That would be terrible indeed. You wouldn't know where the output of
one command ends and the next begins.

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

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

I would be ok with a separate page for Ubuntu-specifics, just like we
have a page for RaspberryPi/Raspbian-specifics.

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

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.

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

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

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

You'd have to ask the Mesa people about that. All I have seen in the
discussions is that LLVM is a pain to build with, and personally I have
never had a problem with it.

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

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.


Thanks,
pq