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

[Derek Foreman]

On 01/09/16 07:38 AM, Emil Velikov wrote:
> 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.
>>

It's also entirely possible many devs are already using out of tree
builds and haven't read the build docs lately.

> 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

make clean isn't equivalent to rm -r builddir.  rm + configure is.

Pretty sure none of the projects developed on this list have a configure
that's slower than their make clean.

(I agree with the rest of the points though :)

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

What is and is not the topic of this thread appears quite diverse at
this point.  I see no harm in discussing this here.

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

A bit of a strawman agrument, I'll admit.  Will happily test patches to
sort the issue though.  (Though, I wouldn't personally be comfortable
landing any such patch without Quentin's Rb)

Even just filing a bug ticket would be great so the problem isn't
forgotten with this thread.

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

Certainly no hard feelings here.  Although the discussion might reach a
wider audience if it had a different subject line (and didn't appear to
be related to a patch that most developers don't care too terribly much
about)

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