[OE-core] [PATCH v2] waf.bbclass: explicitly pass bindir and libdir

[Joshua Watt]

On Tue, 2017-12-12 at 16:56 +0100, Stefan Agner wrote:
> On 2017-12-12 16:47, Otavio Salvador wrote:
> > On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner <stefan at agner.ch>
> > wrote:
> > > On 2017-12-12 15:13, Burton, Ross wrote:
> > > 
> > > > On 12 December 2017 at 14:03, Stefan Agner <stefan at agner.ch>
> > > > wrote:
> > > > 
> > > > > On 2017-12-12 15:00, Burton, Ross wrote:
> > > > > 
> > > > > > On 12 December 2017 at 13:27, Stefan Agner <stefan at agner.ch
> > > > > > > wrote:
> > > > > > 
> > > > > > > On some build hosts distros (e.g. Fedora 26) waf tries to
> > > > > > > be
> > > > > > > smart about libdir detection and defaults to
> > > > > > > [EXEC_PREFIX/lib64].
> > > > > > > This obviously is not what we want for 32-bit targets and
> > > > > > > usually
> > > > > > > fails in the do_package phase:
> > > > > > > WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package:
> > > > > > > QA Issue: gstreamer1.0-plugins-imx: Files/directories
> > > > > > > were installed but not shipped in any package:
> > > > > > > /usr/lib64/libgstimxcommon.so.0
> > > > > > > 
> > > > > > > Waf knows prefix, bindir and libdir as default options.
> > > > > > > Explicitly
> > > > > > > pass those three.
> > > > > > 
> > > > > > Obviously not.
> > > > > > 
> > > > > > ERROR: eglinfo-x11-1.0.0-r0 do_configure: Function failed:
> > > > > > do_configure (log file is located at /data/poky-
> > > > > > tmp/master/build/work/corei7-64-poky-linux/eglinfo-
> > > > > > x11/1.0.0-r0/temp/log.do_configure.17278)
> > > > > > ERROR: Logfile of failure stored in: /data/poky-
> > > > > > tmp/master/build/work/corei7-64-poky-linux/eglinfo-
> > > > > > x11/1.0.0-r0/temp/log.do_configure.17278
> > > > > > Log data follows:
> > > > > > > DEBUG: Executing shell function do_configure
> > > > > > > waf [commands] [options]
> > > > > > > 
> > > > > > > Main commands (example: ./waf build -j4)
> > > > > > >   build    : executes the build
> > > > > > >   clean    : cleans the project
> > > > > > >   configure: configures the project
> > > > > > >   dist     : makes a tarball for redistributing the
> > > > > > > sources
> > > > > > >   distcheck: checks if the project compiles (tarball from
> > > > > > > 'dist')
> > > > > > >   distclean: removes the build directory
> > > > > > >   install  : installs the targets on the system
> > > > > > >   list     : lists the targets to execute
> > > > > > >   step     : executes tasks in a step-by-step fashion,
> > > > > > > for debugging
> > > > > > >   uninstall: removes the targets installed
> > > > > > >   update   : updates the plugins from the *waflib/extras*
> > > > > > > directory
> > > > > > > 
> > > > > > > waf: error: no such option: --bindir
> > > > > 
> > > > > Hm, eglinfo seems to come with a old waf version, 1.7.8 to be
> > > > > specific.
> > > > > 
> > > > > It seems bindir/libdir got added in 1.8 series:
> > > > > https://github.com/waf-project/waf/blob/waf-1.8/waflib/Option
> > > > > s.py
> > > > > 
> > > > > Make version specific variables?
> > > > 
> > > > That neatly shows where the "clever code" that was breaking
> > > > libdir earlier is:
> > > > 
> > > > https://github.com/waf-project/waf/commit/823b4cd2dc03d06a81e0a
> > > > b003606067da03d8745#diff-b44b0c8f383b2fd1b19f2ba039d30237
> > > > 
> > > 
> > > Yeah that seems to be it.
> > > 
> > > That go added in the 1.8.6 dev cycle afaik.
> > > 
> > > I am thinking about adding some kind of version autodetection
> > > 
> > > WAFMINOR=$(${S}/waf --version | sed -e '1{s/waf [0-9]\.//;s/\.[0-
> > > 9]*
> > > (.*//};q')
> > > 
> > > if [ $WAFMINOR -gt "7" ] ...
> > > 
> > > Maybe there is a nicer way of doing this?
> > 
> > What about we provide a package waf version and replace the
> > binaries
> > prior building? So we know what version we'd be using. Kinda
> > autoreconf run in autotools class.
> 
> Waf seems to be extensible using wscript. I don't know how exactly
> wscript depends on waf (version) and whether the API is considered
> stable...
> 
> I'd rather prefer not taking chances...

I agree.

Using a "packaged waf" is against one of the philosophies of waf.
Consequently, this is one of the reasons software built with waf has
trouble getting into things like Debian packages. 

Also, from expirence this is probably not a good idea for 2 reasons:
 1) Different versions of waf behave differently and it can cause
strange build issues if you replace the version a package is normally
built and tested with
 2) A project can "prebuild" waf with all the extra tools it wants. If
there was a packaged version of waf it would have to include every tool
possible, which can be imposible if there are custom project tools
which have been prebuilt. I don't know how common it is to include
custom project tools into the prebuilt waf, but it is certainly
possible.

> 
> --
> Stefan