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