Has anyone worked on integration with OpenEmbedded?

[ricardo...@gmail.com]

OpenEmbedded is a build system widely adopted (the core of Yocto Project). Today most of the Board Support Packages come in form of an OpenEmbedded Layer.

I was wondering if anyone has ever integrated bazel into OpenEmbedded. If not, which would be the most up to date documentation for cross compiling using bazel.

Thanks!

[Ricardo Ribalda Delgado]

Just as a reference. This is how meson and cmake are implemented in OE:

https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/classes/meson.bbclass
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/cmake.bbclass

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "bazel-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bazel-dev/H9bHVX-LC6c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> bazel-dev+...@googlegroups.com.
> To post to this group, send email to baze...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bazel-dev/b0161898-c686-4c2c-bf2c-51eb549aaed1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Ricardo Ribalda

[László Csomor]

Hi,

This is the first time I hear about OE, so thank you for making me aware of it.
As far as I know, we didn't yet look into creating a layer for Bazel.

As for the cross-compilation question, +hlopko could say more.


--
László Csomor | Software Engineer | laszlo...@google.com

Google Germany GmbH | Erika-Mann-Str. 33 | 80636 München | Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

> You received this message because you are subscribed to the Google Groups "bazel-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.

> To post to this group, send email to baze...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/CAPybu_2W_kw4GKNOE5b4t7jRbWmSB%3DJBMCCyVmM1zUVi33LCJw%40mail.gmail.com.

[Marcel Hlopko]

Hi Ricardo,

The CROSSTOOL file (e.g. https://github.com/bazelbuild/bazel/blob/master/tools/cpp/CROSSTOOL) is where we define C++ toolchains. Bazel options such as --cpu or --compiler then control which toolchain is selected. Let me know if you want to know more, I'm just giving a short answer that will enable you to do some googling :)

--

-- 

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

[Ricardo Ribalda Delgado]

Hi Marcel

Thanks for your response, It seems that my google search superpowers
are not in their best shape these days. I have been messing around for
a couple of days now with no good results (besides a terrible headache
:) .

Let me explain a bit better what do OpenEmbedded provides:

A folder with all the requirements to cross-build a binary under:

/home/ricardo/curro/qt5022/build-qt5022-pyro/build/tmp/work/bobcat_64-poky-linux/bazel-cpp-tutorial/git-r0/recipe-sysroot/
and
/home/ricardo/curro/qt5022/build-qt5022-pyro/build/tmp/work/bobcat_64-poky-linux/bazel-cpp-tutorial/git-r0/recipe-sysroot-native/

This includes EVERYTHING: cross-compiler, libraries, tools.... It also
sets the CC, CFLAGS et al variables:
CC=x86_64-poky-linux-gcc -m64 -march=btver1 -mtune=btver1
--sysroot=/home/ricardo/curro/qt5022/build-qt5022-pyro/build/tmp/work/bobcat_64-poky-linux/bazel-cpp-tutorial/git-r0/recipe-sysroot
CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
-fdebug-prefix-map=/home/ricardo/curro/qt5022/build-qt5022-pyro/build/tmp/work/bobcat_64-poky-linux/bazel-cpp-tutorial/git-r0=/usr/src/debug/bazel-cpp-tutorial/git-r0
-fdebug-prefix-map=/home/ricardo/curro/qt5022/build-qt5022-pyro/build/tmp/work/bobcat_64-poky-linux/bazel-cpp-tutorial/git-r0/recipe-sysroot-native=
-fdebug-prefix-map=/home/ricardo/curro/qt5022/build-qt5022-pyro/build/tmp/work/bobcat_64-poky-linux/bazel-cpp-tutorial/git-r0/recipe-sysroot=

it also modifies LD_PRELOAD to add some logic to detect host
cross-contaminations:
LD_PRELOAD=libpseudo.so

I have prepared (now manually, later automated) a CROSSTOOL file that
makes use of OE sysroot (attached). I have not been able to find
documentation for all the fields of that file, so I have done my best.

But apparently this is not enough. I also have to prepare a BUILD file
and wrappers for the binary (is this right?)

bazel --output_user_root=./bazel_out build --cpu=oe-target
--verbose_failures main/hello-world
WARNING: ignoring LD_PRELOAD in environment.
ERROR: No toolchain found for cpu 'oe-target'. Valid cpus are: [
k8,
armeabi-v7a,
x64_windows_msvc,
x64_windows_msys,
s390x,
ios_x86_64,
].
INFO: Elapsed time: 0.240s

All this seems like a lot of work for what it my head sounds much
more simple. Am I misunderstanding something? Cant there be a bazel
cpu that is just respect all the standard variables (CFLAGS, CC, CXX,
CXXFLAGS, LDFLAGS.....)?


Regards!

--
Ricardo Ribalda

[Marcel Hlopko]

Hi Ricardo,

Oh you already went quite far, very cool! Yes you do need a BUILD file, to tell Bazel where is the crosstool and what other files it depends on. You only need wrappers if you need to do more than just calling the compiler/linker (e.g. setting LD_PRELOAD).

The best (and only :) documentation for crosstool is in its source: https://github.com/bazelbuild/bazel/blob/1a06cb90e8a5bfd6134ed0a00f86cf73eb4cb60f/src/main/protobuf/crosstool_config.proto

For the cc_toolchain_suite and cc_toolchain rules you can just imitate what crosstool distributed with bazel does: https://github.com/bazelbuild/bazel/blob/master/tools/cpp/BUILD.tpl

If you already have everything prepared in environment variables, the easiest might be to autogenerate crosstool from those variables. We actually do the same, we inspect the host system and try to guess which compiler, linker,flags ... to use. There was a blog post describing the approach (although it's a bit dated now): https://blog.bazel.build/2016/03/31/autoconfiguration.html

Take a look at https://github.com/bazelbuild/bazel/blob/master/tools/cpp/cc_configure.bzl and https://github.com/bazelbuild/bazel/blob/master/tools/cpp/unix_cc_configure.bzl and just teach it to understand CFLAGS, CC, CXX, CXXFLAGS, LDFLAGS etc. 

cc_configure.bzl right now is honestly just a quick hack for the meantime, we are going to implement something more powerful, and that something will very likely understand standard env vars out of the box. We're not there yet though.

--cpu, --compiler, and --glibc are flags that control which toolchain gets selected from the crosstool. Toolchains in the crosstool need to specify those fields correctly, and also the cc_toolchain_suite must set them precisely. The selection logic is implemented here: https://github.com/bazelbuild/bazel/blob/98dbe037d7b6f2e815af1036373717e28d950698/src/main/java/com/google/devtools/build/lib/rules/cpp/CrosstoolConfigurationLoader.java

Sorry we have no docs other that the implementation for this, we first need to clean this up, make it more usable for people outside of google. Then we'll focus on docs. Feel free to ask more, I'll do my best to answer.

Cheers

[Ricardo Ribalda Delgado]

Hi Marcel

Just had an stupid idea, please tell me what do you think.

what about making a bazel toolchain that calls wrappers that use the
standard variables (LD, AR, CC, OBJDUMP, OBJCOPY....)

That toolchain will be able to work with all the cross-compiler tools
(OpenEmbedded, ptxdist, debian autobuilder, even crosstool). It is
MUCH easier to set environmental variables than creating and editing
files.

Any reason why I should not implement it? Any reason why it is not
available already?


Thanks for your promptly response

PS:

> https://groups.google.com/d/msgid/bazel-dev/CAFuL9GmuT1iTGSN_YyLQ-p2fLT2CtnPPqTpiooRJH7gm-%3D%3DS0Q%40mail.gmail.com.

[Marcel Hlopko]

Hi Ricardo,

it's not a stupid idea at all, actually I had plans to do that too, just didn't have time yet. Right now bazel's crosstool is generated from some environment variables (e.g. CC). The entry point is here: https://github.com/bazelbuild/bazel/blob/master/tools/cpp/cc_configure.bzl

We'll definitely accept contributions to the autogeneration script that will make it work with standard variables. I'd prefer if they worked on both unix and darwin. Windows is a special flake :)

Thanks for the interest!