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 <ste...@agner.ch>: > >> On 2017-12-12 16:47, Otavio Salvador wrote: >>> On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner <ste...@agner.ch> wrote: >>>> On 2017-12-12 15:13, Burton, Ross wrote: >>>> >>>>> On 12 December 2017 at 14:03, Stefan Agner <ste...@agner.ch> wrote: >>>>> >>>>>> On 2017-12-12 15:00, Burton, Ross wrote: >>>>>> >>>>>>> On 12 December 2017 at 13:27, Stefan Agner <ste...@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@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
