On 05/19/2014 12:39 AM, Pekka Paalanen wrote:
On Fri, 16 May 2014 13:43:50 -0700
spit...@gmail.com wrote:
From: spitzak <spit...@gmail.com>
This is based on several experimental runs on two different
Ubuntu 12.04 machines. Latest version includes instructions for
a recent update of Mesa (which requires llvm-3.1) and that you
must compile Cairo to avoid bugs in the system-supplied version.
Hi,
This is v3 of the same patch, right?
Please mention that, so no-one goes reviewing the outdated versions,
especially when it's this long.
Okay, I will try to get that right. Still trying to get git format-patch
and send-email to work correctly. The only method I have found to
reliably set the subject and text is to edit the patch file after it is
produced. You probably saw some very screwy stuff I posted trying to
make the --compose switch work, before I realized I better send
everything to myself first.
I would like to produce instructions on how to make and send a patch to
the mailing list too, so I hope I am getting it right and not missing
something obvious.
General comments:
- Drop all the re-line-wrapping that does not actually change the
content. It just makes this patch daunting to review.
Will try to make the patch again without this.
- I think we should keep the main building page distribution agnostic.
Otherwise it would be specific to Fedora rawhide or latest release or
something, since Fedora is what many main developers use, IIRC (not
me, though). Certainly choosing an ancient distribution like Ubuntu
12.04 is far too old to be considered in detail on or as the base of
the main building page. The same goes for the xserver page.
I suppose you could make a sub-page for Ubuntu specifics, but I think
it might be better on some ubuntu-specific wiki where end users can
update it easily. We could still link there.
The problem is that without the "what is the name of the package
containing foo" information, it is pretty near impossible for a beginner
to compile this. Trust me, having worked on this literally for four
years now, it is NOT easy and this information is valuable. I did assume
the package names were relevant to other systems.
I think instructions lacking the "install this package" commands are not
usable. I suppose I could change it to "install xyz, ddd and foobar" but
I'm not sure if that is any better than showing a command that works on
one platform at least.
I bet the next person fixing these instructions will not be on Ubuntu
12.04, so better drop this, or it gets outdated quick when the person
forgets to remove this.
I am unable to change any machine I am using off of Ubuntu 12.04 as they
are being used for commercial software development and that software
must run on that system, since this is really what people use. I don't
think I am the only software developer in this position.
There have also been a number of emails sent to this list from people
complaining that they could not figure out how to compile it. When they
identified the system it seems they were all using either Raspberry pi
or Ubuntu 12.04.
-export WLD LD_LIBRARY_PATH PKG_CONFIG_PATH ACLOCAL ACLOCAL_PATH
+<pre>
+export WLD=$HOME/install <font color=#800># change this to another location if you
prefer</font>
+export LD_LIBRARY_PATH=$WLD/lib
+export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/
+export ACLOCAL_PATH="$WLD/share/aclocal"
+export ACLOCAL="aclocal -I $ACLOCAL_PATH"
</pre>
This is a good hunk IMO, and the boxing is nice, but I'd like to keep
(and add) the $ in front for manually typed commands.
I removed the $ signs so that multiple lines could be cut & pasted to a
terminal. I agree it looks better with them, but this seems much more
important. Maybe there is some trick so that both can work but I have
not come up with one.
If you didn't test it, then don't change the instructions. If you are
not changing the instructions, don't add "not tested".
Yes there were some comments to myself left in there. Also after some
more studying of this I suspect the system-wide install will work, and
will not kill X, or OpenGL if you are already using Mesa.
+sudo apt-get install doxygen <font color=#800># or use
--disable-documentation</font>
Distribution specifics.
Not sure what I should say. Saying "requires Doxygen" is not enough
information, especially in the many cases where the package name is not
"Doxygen". I suppose I could say "install doxygen" using the Debian
package names but I really don't see what I could say that would provide
the secret info that is not going to be distribution-specific.
+mkdir -p $WLD/share/aclocal <font color=#800># avoid a bug in aclocal</font>
A good addition, though might also use $ACLOCAL_PATH directly.
Yes 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.
+sudo apt-get install libpciaccess-dev <font color=#800># needed by drm</font>
Distribution specifics.
Yes but this is a good example. The error message said only "pci" I
think. I had to do a lot of searching and test-installs before I found
that this package (with the word "lib" on the start, and "access-dev" on
the end) was the one. That is not something we should require everybody
to repeat. I think it is making people give up on wayland long before
they get anywhere.
(all the proto git packages)
These should not usually be needed. I think it would be enough to
just mention --disable-dri3 in case someone has a problem with these
dependencies. The rest are only because you used such an old
distribution as a base. I don't think we should go that far in the
generic guide.
Some of those git repositories were updated at the same time xserver
was. About 2 months ago it compiled with the packaged ones, and it does
not now, and in fact in one day another package was added. Since it
changes that fast I doubt any distribution is going to be up to date.
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.
+<p>If you want to compile the XServer, it may be a good idea to
+compile all it's <a href="xserver.html">prerequisites</a> now, so
+that Mesa is using the same version as xserver.</p>
Not sure that really matters.
I searched and mesa is referring to the proto packages. I agree it
probably does not matter, but it seemed bad to make the compilation of
mesa different depending on whether you do it before or after the xserver.
+<p>And finally you can compile Mesa:</p>
+
+<pre>
+git clone git://anongit.freedesktop.org/mesa/mesa
+cd mesa
+./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \
+ --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi \
+ --with-gallium-drivers=r300,r600,swrast,nouveau \
+ --disable-llvm-shared-libs <font color=#800># this may be a bug in the llvm
package</font>
+make && make install
+cd ..
I'm not sure should tell people to use --disable-llvm-shared-libs, the
Mesa default must be good enough, or it is a distribution problem with
the dependencies. Anyway, this is not really a Mesa build guide but
just enough details to configure Mesa properly for Wayland needs in
general.
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...
The configure error is pretty clear that adding
"--disable-llvm-shared-libs" will work so I suppose removing it is not
that bad. Despite what I am trying to do, mesa changes so fast that it
is very unlikely the next code update will compile without changing
these instructions anyway. Maybe putting it in a comment will help.
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?
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.
+sudo apt-get install libmtdev-dev libpam0g-dev
Distribution specifics.
Again these are good examples of mystery package names that I had to
figure out by trial and error and installing a lot of incorrect
packages. Nobody is going to guess that pam has "0g" on the end. This is
the important information I was trying to add to the instructions.
Compiling these from git might be more acceptable?
Not only Weston needs libxkbcommon, but all other Wayland compositors
and clients need it too. Why squash this into the Weston section?
Left over from an attempt to reduce all the instructions to a few large
steps. I will put it back as before.
+<p>For pdf viewer you need poppler-glib and gio-2.0, I did not test this.</p>
The pdf viewer does not exist anymore.
Ok.
+PATH=$WLD/bin:$PATH ./autogen.sh --prefix=$WLD --disable-setuid-install
No need for PATH, we have a proper fix coming.
Well it sounds like there is some disagreement about the fix. I think I
should leave the text in there until I can confirm the version in git
has this fixed.
+<font color=#800># remove --disable-setuid-install if installing
system-wide</font>
No, system-wide has nothing to do with needing or not needing
setuid-install. weston-launch needs to be setuid if it used, at least
without proper systemd I believe.
Okay got that. Does it only set setuid on the weston-launch executable?
I have not gotten any indication that this works at all. I only get the
error about needing to add myself to the weston-launch group, which I
certainly did!
-<h2><code>$XDG_RUNTIME_DIR</code></h2>
+<h2><tt>$XDG_RUNTIME_DIR</tt></h2>
Why tt instead of code?
That is an editing mistake.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
