Hello everybody,
I need to write bitbake recipes for applications that rely on code generation
as a part of their build. The generator is an Eclipse RCP application that is
available as a pre-built binary. The latter can also be built from the source
code with Maven. The pre-built binary is self-contained and includes
executable launchers for several platforms including linux-x86_64 and linux-x86
as well as .jar files. The launchers only depend on JRE that must be installed
on the build host.
So far I was able to create working bitbake recipes for application build
scripts that are based on either autotools or CMake and expect the generator to
be reachable through the PATH. In order to make sure that the generator is
available on the build host, the recipes add 'generator-native' to the value of
their DEPENDS variables. The recipe generator-native includes the line
'inherit native', fetches pre-built binaries and installs them into ${D}.
The above works as long as (a) the build host has a right version of the JRE
installed and (b) the required version of the pre-built generator binaries is
available. Now my questions are:
1) What would be the recommended way to make sure that (a) is fulfilled?
Should the generator-native recipe test the presence of the right JRE version
on the build host and just fail if this pre-requisite is not fulfilled? Or
should it rather install the JRE (e.g., by using meta-java or meta-java-oracle)?
2) Would it be feasible/sane to support building the generator as a part of
bitbake build? This would help to fulfill (b) through building the generator
from sources, which would also be handy during the generator development. This
would require that the build host also includes Maven, but I was unable to find
an existing native recipe for it. I also wonder how well a Maven build can be
contained by the bitbake build environment. Any hints on what is involved in
making this work would be appreciated.
Thanks,
--Pavel Konopelko
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
