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

Bryce Harrington bryce at osg.samsung.com
Thu Sep 8 06:25:55 UTC 2016


On Wed, Aug 31, 2016 at 01:10:59PM -0500, Derek Foreman 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...

It probably wouldn't be a bad idea to add a setting to allow
wayland-build-tools to do out-of-tree builds.  But the wl_clone script's
existance kind of strongly implies that the tree it creates is for build
purposes only.

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

To each their own I suppose.  None of that really bothers me -- most
stuff builds and links quickly enough even when done from scratch.
Mesa + xserver build times tend to swamp everything else, but I tend not
to do those often.

One thing I do like about using --prefix=$WLD is that I can have
multiple local wayland and weston checkouts where I do my day to day
work, and use the build tree to link against via --prefix.

Bryce

> 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
> > 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


More information about the wayland-devel mailing list