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

[Derek Foreman]

On 31/08/16 05:17 PM, Emil Velikov 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>
>>>>
<trying to snip things that have moved on to other threads a bit>
>>> 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.

None of that explains "shorter" or "less complicated" - that's an
entirely different concern.

People should still be doing a make check/distcheck before sending
patches regardless of what workflow they use.  If someone finds this
workflow faster for development, I'm not going to argue against it.

I think a wl-prefixed script that sets up that workflow would also be of
value in wayland-build-tools.

>> 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
> :-\

I will concede that point :) and let Reynaldo continue to argue if he
wants.  I think having the script honor the env var if it's set, and
replace it otherwise seems to be an ok middle ground?

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

It just seems silly to me to require changes here when it's not
something we've ever considered to be a problem before.  Adding a way to
make out of tree builds work with this script seems like an additional
feature to me, that could be added by the first person interested in
using it that way.

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

Point taken, but I'm afraid I'm going to have to call you our for the
sake of a cheap punchline.  No offense intended...

In the same email you've told me I'll get rocks thrown at me for using
gst as an example, and you've told me/us/the wayland community to draw
inspiration from the Xserver.

I'm sure you can imagine a project that's drawn together a diaspora of X
expats might throw a few rocks over your comment. ;)

(Rock throwing in either case would be pointlessly ad hominem, of
course, as we should consider the merits of individual approaches and
not the names of projects, amirite?)

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

Not that I agree that it's iffy in the first place, but gstreamer's
kmssink is arguably at the same layer as weston, and waylandsink at the
same layer as anything in toytoolkit.

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

I do thank you for your input, and hope some of the concerns you've
voiced with the build system are addressed or at least end up as bug
tickets for later.

I don't think this patch is promoting one workflow as better than the
other, and am a little surprised this turned into a discussion of how I
should be building (or not) and installing (or not) software I develop.
I've generally considered these issues to be left to the preference of
individual developers.

I wouldn't mind seeing a similar script to trivialize a --prefixed
installation along side this in wayland-build-tools.  Ultimately it
doesn't matter what I want on this one though, as the repo in question
is entirely under Bryce's control... :)

> Thanks
> Emil
> 

PS.

vi vs emacs, go go go! ;)