http://freehackers.org/~tnagy/bksys.html
Yawn... Yet another broken build system.
I second the request for an ebuild. I can maybe help (but i dont now ebuilds very much). It is used by some projects like xmms2 or kde-misc/kdissert.
No progress here for over one year; closing WONTFIX. Feel free to reopen with an ebuild.
The install information doesn't look much targeted to linux distros: "Waf is a small script (fits in about 100kb) that can be redistributed easily. Most people put the waf script just in their project directory" - http://code.google.com/p/waf/wiki/InstallingWaf Looks like installing means unpacking, then running "./waf-light --make-waf --strip" (without "--strip" if useflag "doc") and then moving "waf" to a more permanent location like usr/bin/waf
The WONTFIX status is indeed correct: Waf is meant to be redistributed with the projects using it as a compilation script (in its appropriate version), and not an application to install. Go install your apps, not the build script. Reference: http://freehackers.org/~tnagy/wafbook159/ch01s02.html
Created attachment 216577 [details] waf-1.5.10.ebuild An ebuild for installing waf, since the reasons given by - http://freehackers.org/~tnagy/wafbook159/ch01s02.html for not installing waf are pretty irrelevant in Gentoo. For reference the reasons with rebuttal: 1. Installation: installation is cumbersome, and requires administrative privileges -> that's the preferred way to install in Gentoo. Also "emerge waf" isn't cumbersome. 2. Waf versions: users rarely install the appropriate software version (too old, too new) -> that's the job portage does damn well. 3. Bugs: newer Waf versions may result in broken builds -> bugs are everywhere. If they appear they should be fixed and not ignored by "use another version". 4. Size: Waf is extremely small (about 70kB) -> so is ogg2mp3 (140kB), and installed waf takes about 700kB (ask `equery s waf`; the ebuild doesn't strip) 5. Operating systems: Waf cannot be installed on Windows (yet) -> do I need to comment on this "disadvantage"? (I changed my mind on that after reading a lot of arguments between "webdevelopers" and "sysadmins" about package managers for python)
The build script is "wscript". waf itself offers build utilities which use the build script (similar to make using the Makefile). I tested it with the examples for which I have the necessary dependencies (mor exactly: I just ran all examples: $mkdir test_waf $for i in waf-1.5.10/demos/* ; do cp -r $i test_waf/; done; for i in test_waf/*/; do cd $i; waf configure >/dev/null 2>/dev/null; waf >/dev/null 2>/dev/null && echo $i succeeded ; cd ../../; done test_waf/adv/ succeeded test_waf/cc/ succeeded test_waf/cxx/ succeeded test_waf/java/ succeeded test_waf/jni/ succeeded test_waf/pch/ succeeded test_waf/perl/ succeeded test_waf/python/ succeeded test_waf/qt4/ succeeded test_waf/simple_scenarios/ succeeded test_waf/tex/ succeeded test_waf/unit_test/ succeeded $ rm -r test_waf/* $ for i in waf-1.5.10/demos/* ; do cp -r $i test_waf/; done; for i in test_waf/*/; do cd $i; waf configure >/dev/null 2>/dev/null; waf >/dev/null 2>/dev/null || echo $i failed ; cd ../../; done test_waf/d/ failed test_waf/gnome/ failed test_waf/ocaml/ failed test_waf/swig/ failed test_waf/vala/ failed -> I don't have d, GNOME, ocaml or vala. the only part which worries me is the failed swig install. Details: $ waf configure Checking for program g++,c++ : ok /usr/bin/g++ Checking for program cpp : ok /usr/bin/cpp Checking for program ar : ok /usr/bin/ar Checking for program ranlib : ok /usr/bin/ranlib Checking for program python : ok /usr/bin/python2.6 Checking for Python version >= 2.4.2 : ok 2.6.4 Checking for library python2.6 : ok Checking for program python2.6-config : not found Checking for program python-config-2.6 : ok /usr/bin/python-config-2.6 Checking for header Python.h : ok Checking for program swig : ok /usr/bin/swig Checking for swig version >= 1.3.27 : ok 1.3.36 'configure' finished successfully (0.664s) $ waf Waf: Entering directory `/home/arne/Diplomarbeit/sonstiges/test_waf/swig/build' [ 3/11] swig: extend/python/test_swig_waf.i -> build/default/extend/python/test_swig_waf.swigwrap_3.cxx build/default/extend/python/test_swig_waf.py ../extend/python/test_swig_waf.i:5: Error: Unable to find 'a.h' Waf: Leaving directory `/home/arne/Diplomarbeit/sonstiges/test_waf/swig/build' Build failed -> task failed (err #1): {task: swig test_swig_waf.i -> test_swig_waf.swigwrap_3.cxx,test_swig_waf.py}
Arne: Now the Waf binary script supports both Python 2.x and 3.x, but the installed version can only support Python 2.x. Also, Waf 1.5.11 is about to be released, your ebuild will be obsolete in a few days. To the Gentoo devs: please make sure to leave this issue as WONTFIX.
The "obsolete" is overvalued (it's just renaming the ebuild), but since waf normally "autogenerates" its libraries and needs to be in a writeable directory for that (IRC discussion on #waf) it doesn't look like it would work nicely with portage. -> http://freehackers.org/~tnagy/wafbook/single.html#using (The libraries are in a compressed bytestream at the end of the waf file)
Created attachment 216605 [details] waf-1.5.10-r1.ebuild I currently don't care if this will be itnegrated in the portage - that's a decision for other people to take. I worked on the ebuild, because it posed a nice packaging challenge (files created at runtime, different users, make sure pyc-files can be rewritten by any user when the python version changes) - and it was fun :) Next attachment will be a tiny patch to the generated waf file (the core part of the ebuild work) which makes it put the cache into /tmp/waf-$USER/.waf... That way all features will be preserved (including independence from the used python version), but waf is installed systemwide and can be used as dependency. I know this work might be wasted for Gentoo, but whatever happens to the ebuild, the work won't be wasted for me, since I had fun and learned some stuff on the way :)
Created attachment 216607 [details] files/1.5.10-cache-in-tmp.patch patch to make waf store the cache in /tmp/waf-$USER/.waf...
note to Gentoo devs: ita = waf upstream in IRC
Additional note: Even with the changes, this ebuild suffers from a fatal flaw: since it makes waf store all libs in /tmp/, another user can create pseudo-libs, chmod them to me and that way get me to execute arbitrary python code when I fire up waf the next time. This won't get hime instant root permissions (sandbox still holds when installing, and I normally don't use waf as root), but it's still a security risk. So the safe way is to use waf as it's intended to be used by upstream (or to patch the script some more to create the libraries in the directory in which the waf command is called).
I see waf in several other distros. I would like to know which benefit exactly we have in having it in portage? If a developer wants to builds his package with waf, does he need to install waf anyay?
The advantage is that developers can just install it locally for their projects instead of having to download it from the web. Especially if you have many small projects that can be useful. The waf developer is not happy with waf in distros, though. He wants waf as single script inside every source tree.
Another advantage would be that legacy programs could automatically be built with a more recent waf, for example when security problems are found in waf, without requring every single developer to watch out for waf updates. But that’s the very thing the waf developer wants to avoid by telling developers to include a fixed waf version in their projects, because it might break when the cli syntax of waf changes (or similar).
(In reply to comment #14) > I see waf in several other distros. Only Fedora remains. Waf has been successfully removed from Debian a while ago. > I would like to know which benefit exactly > we have in having it in portage? If a developer wants to builds his package > with waf, does he need to install waf anyay? There are no benefits: it is one more thing to maintain and it will only cause build failures. (In reply to comment #16) Arne, the files and folder unpacked locally by waf do not create additional security issues - they are only writeable by the user - dowloading and unpacking whatever archive to /tmp *is* the problem. Stop trying to scare people and leave this issue as WONTFIX.
The only advantage for waf on gentoo then would be to skip the 2.1.2 step in the waf book. So a user using waf for many of his local projects would generate his waf script. But this is not hard to do anyway. We can always avoid using system-wide waf for packages by simply using ./waf in ebuilds. But my main worry is to include a package not supported by upstream, especially after reading waf removal in the Debian mailing list.
Please note (with my comments on advantages) that I drew back my request for getting this added to the tree. Discussing the advantages of having waf in the tree is already purely academic for me. The bug is RESOLVED WONTFIX, and that’s OK with me. One point there: If I use it for my own small projects and install it locally by hand and then another developer wants to test my projects, he will have to install w1af by hand, too, and I can’t just tell him “emerge waf”. So collaborating with different unconnected groups on small projects gets harder. If you have one big project, the single waf file doesn’t make much difference and people don’t have any external dependencies for building, and if you have many projects you work on alone, you can install waf locally by hand without too much overhead. Still it feels wrong to *have to* resort to anything else than portage to get a program… (having the option to just put the build tool in the tree with only minor overhead feels like a very nice way of lowering the barrier for contributors, though).
Arne, I have no doubt about the usefulness of having waf in the main tree. As I said I will probably not include it in the main tree mainly because of the upstream crusade against distribution maintainship. Bundling third party packages is pretty much *always* a bad idea. And not only for security reason (which you might run into by running "sudo ./waf install"). Many of us devs could go on and on about it. If you have a more recent ebuild, post it anyway, I'll take a look at it.
One more point: When I install something from the Gentoo tree, it is verified via md5, sha1 and even GnuPG signature to be safe. When I download waf from the net, all someone has to do is setting up a proxy with my internet provider and replacing the file. This only applies to waf itself, though. Programs using waf which are installed via portage ind bundle waf are secure against that. But I can already see Gentoo devs patching waf in each source file when a developer ships a broken waf but isn’t actively maintaining the package, so that the internal waf isn’t updated…
(In reply to comment #21) > net, all someone has to do is setting up a proxy with my internet provider and replacing the file. Note: waf offers a sha1 for verification, but that isn’t done automatically.
Created attachment 243017 [details] /usr/local/overlays/genbab/dev-util/waf/waf-1.5.10-r1.ebuild now uses python_depend instead of need_python. I saw portage complain about that a few times and then decided to fix it instead of removing it from my local overlay.
With multilib installed having a waf ebuild would help. For example the pycairo-1.10.0-r1 ebuild uses waf and does: command ['/usr/bin/python', '/usr/bin/python-config-2.7', '--includes'] returned 1 this fails since multilib links /usr/bin/python-config-2.7 to abi-wrapper to handle the different abis. abi-wapper is bash. waf assumes its python which is a bad assumption. Having a waf ebuild would let us fix this.
