[oe] [meta-qt5] populate_sdk_ext fails

Paul Eggleton paul.eggleton at linux.intel.com
Tue Jan 31 04:14:46 UTC 2017


Hi Mike,

On Monday, 30 January 2017 8:23:28 PM NZDT Mike Nicholson wrote:
> I’m attempting to generate an extensible SDK that includes the meta-qt5
> layer.  Generating a standard sdk via Yocto works just fine but generating
> the extensible sdk fails with the following error:
> 
> 
> | NOTE: Executing create_sdk_files ...
> | DEBUG: Executing shell function create_sdk_files
> | touch: cannot touch
> | '/home/nic47222/Projects/viavi-platform/viavi-bsp/build/tmp/work/mts-poky
> | -linux-gnueabi/viavi-image-qt5/1.0-r0/sdk-ext/image//opt/poky/2.1.1/sysroo
> | ts/x86_64-pokysdk-linux/usr/bin/qt5/qt.conf': No such file or directory
>  
> It appears that here
> https://github.com/meta-qt5/meta-qt5/blob/9aa870eecf6dc7a87678393bd55b97e21
> 033ab48/classes/populate_sdk_qt5_base.bbclass#L7 the directory that should
> contain the qt.conf file does not exist.
>
> Are there known issues with the populate_sdk_ext command and the meta-qt5
> layer?

As Martin indicated you may be among the first people to try it.

> I can get generate the extensible SDK just fine if I make the following
> changes:
>
> diff --git a/classes/populate_sdk_qt5_base.bbclass
> b/classes/populate_sdk_qt5_base.bbclass
> index b6ce596..b66fe25 100644
> --- a/classes/populate_sdk_qt5_base.bbclass
> +++ b/classes/populate_sdk_qt5_base.bbclass
> @@ -4,6 +4,7 @@ inherit qmake5_paths
> create_sdk_files_prepend () {
>      # Generate a qt.conf file to be deployed with the SDK
>     
> qtconf=${SDK_OUTPUT}/${SDKPATHNATIVE}${OE_QMAKE_PATH_HOST_BINS}/qt.conf
> +  mkdir -p ${SDK_OUTPUT}/${SDKPATHNATIVE}${OE_QMAKE_PATH_HOST_BINS} touch
> $qtconf
>      echo '[Paths]' >> $qtconf
>      echo 'Prefix = ${OE_QMAKE_PATH_PREFIX}' >> $qtconf

So this is interesting. Whilst this is the most obvious fix, I think this 
indicates a deeper issue may be present. The directory isn't there because the 
eSDK works differently than the standard SDK for which this class was 
obviously designed - it has an OE-style sysroot that appears under tmp/ within 
the SDK, not at the location this is writing to, so I'm not sure this will 
work as desired. Have you tried installing and using the SDK after building it 
successfully?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-devel mailing list