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

[Emil Velikov]

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.

What's stopping wayland/weston devs from moving away from this bad practise ?

>> As mentioned before using --prefix=$WLD/foo + make install will make
>> things shorter/simpler
>
> Takes more time (waiting for misc relinking during the install - perhaps
> not overly onerous for wayland/weston/libinput), takes more steps
> (performing the install), takes more effort to undo (make distclean is
> essentially a complete uninstall of a package - of course I could have a
> separate prefix for each repo and a bunch more env vars, so perhaps
> that's not an important distinction), takes more space on disk.
>
> This doesn't seem shorter or less complicated?
>
In one case you have a setup that resembles closer to what _everyone_
will be using. Not by a huge margin, but still.
Afaict one of the reasons behind --prefix was exactly this -
intermediate location to accommodate testing before deployment.

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

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

>> LD_LIBRARY_PATH="\
>> $WLD/foo/lib/\
>> ${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
>>
>> WESTON_BUILD_DIR="\
>> $WLD/build/weston/\
>> ${WESTON_BUILD_DIR:+:$WESTON_BUILD_DIR}"
>>
>> PKG_CONFIG_PATH="\
>> :$WLD/foo/lib/pkgconfig/
>> ${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}"
>>
>> PATH="\
>> $WLD/foo/bin/\
>> :$PATH"
>>
>>
>>> +* Edit a local copy of the script to make $WLD point to the base directory
>> How about one honours the WLD that's already set since ...
>
> It's not already set - the script exports it.  Oh, this seems to be the
> same variable name used in some of the build instructions at:
> https://wayland.freedesktop.org/building.html
>
> and in weston's releasing.txt.
>
> Is that the problem?
>
Definitely not a problem, esp. since I've completely misread the help
text. Hope I'm the only one...
In general I'm biased towards "the script should just work and if you
modify it that means there's something wrong" behaviour.

Mostly because any form of modifying it implies (and it really does)
that making further changes it is perfectly fine and before you know
it your version has little resemblance to the one used by another dev.
At the same time both of you believe to be using the same procedure
:-\

>>> +  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 running from the uninstalled environment.
>>> +
>>> +    cd $WLD
>> ... they will likely use it here ?
>
> These instructions are performed after running the script, so WLD should
> have been set in the environment by the script.
>
>>> +    for i in wayland wayland-protocols libinput weston; do
>>> +    cd $i && ./autogen.sh && make && cd ..; done
>> Use OOT builds, please.
>
> Only if all the existing scripts and documentation are updated to stop
> using in tree builds. ;)
>
Don't think one needs to update the existing documentation for that.
Most/all of those serve different purposes so one can sort them
separately, in due time, right ?

>>
>>> +if [ "$1"yes != "yes" ]; then
>>> +  cat << EOF
>>> +
>>> +This script uses no arguments. Aborting execution.
>>> +
>> The number of arguments is $#, why not use that one ?
>>
>>
>>> +WLD=$HOME/devel/wayland/git
>>> +
>> With the above said, one can just check it and bail out if WLD invalid/unset ?
>
> I'm somewhat undecided on this.  Setting up the env var outside of the
> script is potentially a little more annoying (have to add it to your rc
> scripts, cycle any shells, or do it manually every time you use the
> script) but I think anyone using this stuff shouldn't have too much
> trouble figuring that out.
>
If that's big enough annoyance for people to notice then ... well you
get where I'm going.

> We're copying functionality that exists elsewhere (gst-uninstalled from
> gstreamer), so maybe it's best to stick with their paradigm since they
> seem happy with it?
>
There's plenty of people who'll (almost literally) throw stones as you
for taking gst as example.
Personally I'm not crazy against/for gst yet I try to preach:

Don't copy everything someone else does. There may be a valid reason
for them to do so but not all of if it is applicable for you.
</preach mode>

Not to mention that comparing components that have a layer or two
distance in the stack sounds iffy.

That said, I won't nag any more on the topic unless explicitly asked ;-)

Thanks
Emil