[QBS] How to run a command and get the output

Oswald Buddenhagen oswald.buddenhagen at nokia.com
Tue Feb 21 13:50:43 CET 2012


On Tue, Feb 21, 2012 at 11:07:16AM +0100, ext Joerg Bornemann wrote:
> Ideally, the Qt module files would reside in Qt's build directory / be 
> generated by Qt's configure, containing the right settings and having 
> only those Qt modules present that have been built and adding the right 
> platform dependent libraries.
> 
> Not having the ideal situation we could do two things:
> 1) put platform information into the Qt modules. That is for your case 
> adding
>      cpp.dynamicLibraries: {
>          if (qbs.targetOS == 'android')
>              return ['egl', 'gles']
>      }
> to the the Qt OpenGL module. Very ugly.
> 
that's actually pretty ok. once the qt module files are generated by the
build of qt itself, they will hardcode the platform specific
information, based on code executed during their build. as we don't have
that mechanism yet, it is ok to defer the execution of that code to the
time when the modules are actually used.

> 2) Have a set of own Qt modules files, tailored to your needs, that come 
> with the Qt for Android SDK and adjust the module search path.
> 
i'd recommend against that. in a project which is changing as fast as
qbs, forking anything is a safe bet to go stale.

fwiw, the *really* right solution is encapsulating the platform
libraries into modules. at some point, these modules will be extended by
configure checks which verify that the requested libraries are actually
there.
then, to use it, something like that would be done:

DynamicLibrary {
	name: "QtOpenGL"
	property enum { GLDesktop, GLES2, ... } glType: (qbs.targetOS == 'android') ? GLES2 : GLDesktop // arbitrary default
	Depends {
		condition: glType == GLES2
		name: "GLES2"
	}
	Depends {
		condition: glType == GLDesktop
		name: "GL"
	}
	...
	cpp.extraDefines: (glType == GLES2) ? [ "HAVE_GLES2" ] : [ "HAVE_DESKTOP_GL" ]
	...
}




More information about the Qbs mailing list