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

[Stefan Agner]

On 2017-12-12 17:04, Vincent Prince wrote:

> As waf_do_configure takes care of EXTRA_OECONF, maybe we can only fix gstreamer1.0-plugins-imx_0.13.0.bb by adding libdir ?  
> It is much a bug fix than a longterm solution, but if any waf version breaks options, it can be a nightmare to handle... 

For me, that definitly would work too.

But then, since all version of waf > 1.8.6 seem to use this
autodetection it is quite likely that other packages fail/will fail.

I am about to send a v3 with version detection, lets see if we can agree
on such a solution (and backport it to rocko).

--
Stefan


> 
> 2017-12-12 16:56 GMT+01:00 Stefan Agner <stefan at agner.ch>:
> 
>> 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/Options.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/823b4cd2dc03d06a81e0ab003606067da03d8745#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...
>> 
>> --
>> Stefan
>> 
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core