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

2017-12-12 16:56 GMT+01:00 Stefan Agner <stefan@agner.ch>:

> On 2017-12-12 16:47, Otavio Salvador wrote:
> > On Tue, Dec 12, 2017 at 12:38 PM, Stefan Agner <stefan@agner.ch> wrote:
> >> On 2017-12-12 15:13, Burton, Ross wrote:
> >>
> >>> On 12 December 2017 at 14:03, Stefan Agner <stefan@agner.ch> wrote:
> >>>
> >>>> On 2017-12-12 15:00, Burton, Ross wrote:
> >>>>
> >>>>> On 12 December 2017 at 13:27, Stefan Agner <stefan@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
>