On 01/09/16 07:38 AM, Emil Velikov wrote: > On 1 September 2016 at 10:13, Pekka Paalanen <ppaala...@gmail.com> wrote: >> On Wed, 31 Aug 2016 23:17:09 +0100 >> Emil Velikov <emil.l.veli...@gmail.com> wrote: >> >>> On 31 August 2016 at 19:10, Derek Foreman <der...@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 <der...@osg.samsung.com> wrote: >>>>>> From: "Reynaldo H. Verdejo Pinochet" <reyna...@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/ > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
