[PATCH wayland-build-tools] Add helper script to setup and use an uninstalled environment

[Emil Velikov]

On 1 September 2016 at 10:13, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 31 Aug 2016 23:17:09 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> On 31 August 2016 at 19:10, Derek Foreman <derekf at osg.samsung.com> wrote:
>> > Thanks for taking a look!
>> >
>> > On 31/08/16 04:22 AM, Emil Velikov wrote:
>> >> On 30 August 2016 at 19:56, Derek Foreman <derekf at osg.samsung.com> wrote:
>> >>> From: "Reynaldo H. Verdejo Pinochet" <reynaldo at osg.samsung.com>
>> >>>
>> >>> The wl_uninstalled script provides a shell environment to
>> >>> build and use an uninstalled Wayland/Weston setup.
>> >>>
>> >>> For example, this script and a fresh checkout of Wayland,
>> >>> libinput, wayland-protocols and Weston is all you need to
>> >>> run Weston from the uninstalled environment created by
>> >>> building every module. No installation required.
>> >>>
>> >>> Quick instructions:
>> >>>
>> >>> Lets use Weston as an example altough other Wayland-based
>> >>> software should work as well.
>> >>>
>> >>> Edit a local copy of the script to make $WLD point to the
>> >>> base directory where your repositories are (make sure to
>> >>> use the absolute paths), then, after executing the script,
>> >>> issue the following commands to have everything built and
>> >>> Weston runing from the uninstalled environment.
>> >>>
>> >>> cd <basedir>
>> >>> for i in wayland wayland-protocols libinput weston; do
>> >>> cd $i && ./autogen.sh && make && cd ..; done
>> >> Above all please do _not_ recommend building in-tree. Pretty please.
>> >
>> > Uhh, for better or worse, perhaps too late?  The build instructions at:
>> > https://wayland.freedesktop.org/building.html
>> > explain how to do in tree builds.
>> >
>> > The existing wl_build script in wayland-build-tools does in tree builds
>> > as well.
>> >
>> > Really don't want this to degenerate into a debate about in tree vs out
>> > of tree builds - but our instructions and scripts have been doing
>> > in-tree for a while now...
>> >
>> in case it was unclear none of what I've said is meant to block any of
>> the work but to point out some mispractise/bad ideas.
>> It's up-to the core devs/community to make a decision.
>
> Hi
>
>> What's stopping wayland/weston devs from moving away from this bad practise ?
>
> Not knowing why it's bad. It will also be even more steps in the build
> guide so there wasn't a known benefit for going more complicated, AFAIK.
>
Here as the first things that come to mind:
 - one cannot have/use different builds on the same checkout (think
having a debug vs optimised vs release etc. on the same codebase)
 - in-tree builds don't interact nicely with different git
tools/workflows like gitlink (or so I've been told)
 - if solely using in-tree builds one can easily break the OOT ones.
On the other hand if the OOT works, 99.(9)% of the time the in-tree
one is fine.
 - performance-wise: make clean and friends is slower (move disk
intense) than rm -r builddir

While I couldn't find the article about the last topic, here is one
that iterates most of the other ones in different light [1]


> The most important thing at the time was trying to get people to not
> install to default prefix /usr/local.
>
I couldn't agree more.


>> > If we do install, we must configure weston with --disable-weston-launch
>> > as it requires root perms during installation.
>> Grr this sounds like a sub-optimal/busted configure. One should be able to do
>> $ autoreconf --force --verbose --install --prefix=`pwd`/install && make install
>> and
>> $ autoreconf --force --verbose --install && make distcheck
>>
>> If the latter works while the former does not it means that one is
>> only working around the bug via the *DISTCHECK_CONFIGURE_FLAGS.
>
> Yes, we have --disable-setuid-install for ./configure. It works also
> for normal uses, no need for --disable-weston-launch.
>
> Whether that's a thing to change is another topic.
>
Afaict by design (of autoconf and friends) one should be able to do
the two commands and they must always succeed.
If I'm reading things correctly - the former will fail, while the
latter is worked around by adding the option you mentioned in
AM_DISTCHECK_CONFIGURE_FLAGS.

And yes it's not directly related. I've only jumped the gun as one
could use it as an argument against the make install suggestion.

>> > Not sure what to make of
>> > that - it's not very useful without root perms anyway, and not required
>> > on systems with systemd.  Building it "uninstalled" seems to only have
>> > value to check for compilation and warnings anyway.
>> >
>> Having a look and there isn't even a help text on this option. Yet it
>> requires root, is enabled by default and if chown root (and co) fails
>> so does `make install` :-( This doesn't sound good ...
>>
>> Please draw some inspiration from Xserver on this one.
>
> It sounds like you are talking to Derek when you should be addressing
> everyone. Anyway, AFAICR you are the first one in years to say this
> actually bothers anyone.
>
> I don't have any prejudice against changing things there.
>
Did not mean to target anyone. Sincere apologies if anyone felt in such a spot.

Hope the above proves at least a bit more objective and technical (and useful).
Emil

[1] http://voices.canonical.com/jussi.pakkanen/2013/04/16/why-you-should-consider-using-separate-build-directories/