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

[Derek Foreman]

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

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

If we do install, we must configure weston with --disable-weston-launch
as it requires root perms during installation.  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.

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

>> +  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. ;)

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

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?

I realize that's a lazy answer. :)

Thanks,
Derek

> 
>> +# Export new environment
>> +
>> +export WLD
> Then you can drop this (maybe) ?
> 
> 
>> +The following environment has been exported:
>> +
>> +WLD=$WLD
> And this ?
> 
> 
> Regards,
> Emil
>