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

[Peter Hutterer]

On Tue, May 20, 2014 at 01:12:32PM -0700, Bill Spitzak 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.
> 
> >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.

these are all good suggestions, did you report/request any of these in the
upstream bugzilla?
https://bugs.freedesktop.org/enter_bug.cgi?product=pkg-config

Cheers,
   Peter

> >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.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>