Is it possible to mix targets build in a different compilation mode? I want to compile external dependencies, which are rarely changed in -c opt, but I want build my internal code in dbg or fastbuild mode
The easiest way to do this is stick -O2 in copts of external dependencies or use --per_file_copts in a .bazelrc file.
On some platforms, --compilation_mode has global implications on position-independence and linking behavior. So, it wouldn't necessarily make sense to switch --compilation_mode for part of a build.
Related
I need to use bazel to manage our the source dependencies such that the final build product is purely a function of the toolchain, a vanishingly small number of files from the linux-distribution, and the source code itself. This means building things like libz, libssl, libcrypto, libcurl...
These dependences depend on each other
They have their own native (mostly autotools based) build systems, based on something like ./configure --prefix=foo && make -j && make install.
It seems to me that Bazel is not well suited to this use case. In particular, we need to manually recreate the make install step for each library, in order to copy make install artifacts out of execroot. It's unclear to me how the next dependency reuses the products. So, for example, when building zlib, we produce libz.a, and a bunch of header files. Then, when building libcrypto.a, we need to modify CPPFLAGS and LDFLAGS to point to the zlib "installation".
This strikes me as so pedantic that it's begging for code generation to generate the BUILD files.
Is there an alternative approach that doesn't require bespoke copying the "make install" logic into a genrule?
Take a look at rules_foreign_cc (https://github.com/bazelbuild/rules_foreign_cc). This contains rules for integrating with foreign build systems (make, autotools+make, cmake, etc.).
I have a Bazel project (the new tcmalloc) I'm trying to integrate into a typical GNU Make project that uses it's own build of compiler/libc++. The goal is to not fork the upstream project.
If I pass all the C++ options correctly to bazel (one set of which is -nostdinc++ -I<path to libc++>), Bazel is uhappy The include path '/home/vlovich/myproject/deps/toolchain/libc++/trunk/include' references a path outside of the execution root. (tcmalloc is a git submodule sibling # deps/tcmalloc). It's possible to get this "working" by giving Bazel a custom script to invoke as the compiler that injects those flags so that Bazel never sees them. However, I'd like to just define a toolchain to work properly.
I've read all the documentation I could find on this topic but it's not clear to me how to glue all these docs together.
Specifically not really clear where I should place the toolchain definition files or how to tell Bazel to find those definitions. Is there a way to give bazel a directory that it uses to find toolchain definitions? Am I expected to create a top-level WORKSPACE # /home/vlovich/myproject & register tcmalloc and my toolchain there, & then invoke bazel from /home/vlovich/myproject instead of /home/vlovich/myproject/deps/tcmalloc?
Toolchain support is rather complicated, and it is hard to understand, if you are not a bazel maintainer.
You can use CC and CXX environment variables to set a different compiler like: CC=your_c_compiler CXX=your_c++_compiler bazel build .... You can write your own custom script wrapper which will act as a normal C++ compiler
That -I<path to libc++> does not work, because all normal include paths have to be defined in srcs attribute or via dependencies indicated by the deps attribute. For system-wide dependencies use -isystem Read more about it https://stackoverflow.com/a/44061589/4638604
I want to build my cc_binary target in a dynamic mode linkstatic=False, but without modifying a target definition.
My use case: I want to build static binaries in the CI, but for development purposes I want to use dynamic linking to speedup incremental builds. Probably some flag in bazel build/test invocation would be the best
Check out the --dynamic_mode flag.
(From https://groups.google.com/d/msg/bazel-discuss/LQfL6c-6Wqg/uinZMCTYCgAJ)
Hi--
Is it possible to use bazel to cross-compile using a toolchain where the compiler flags are not remotely gcc-like?
For example, bazel seems to want/need to use -MD -MF foo.d, but the toolchain I have doesn't support these flags, and I do not know of a way to filter these flags from the compile invocation.
The only thing I can think of is to point the CROSSTOOL at some wrapper scripts to muck with all the arguments.
--Rob
Ideally, CROSSTOOL would encapsulate all the toolchain/platform specific flags and Bazel won't hardcode any flags specific to gcc/linux. We're getting there, although at much slower pace than expected (it's quite painful process).
So you should be able to write your own crosstool (or generate one similarly to how bazel does it) that would not emit -MD -MF foo.d. Since we're in the process of migrating many internal crosstools, Bazel is trying to be smart and will add features that your crosstool is missing. Check CppConfiguration.java and CppLinkActionConfigs.java for these "patches".
And regarding wrapper scripts, that's what bazel has been doing for MSVC builds, translating gcc-like command lines into cl.exe style. We are slowly removing logic from these scripts as crosstool is more powerful (e.g. Bazel#head now doesn't use wrapper scripts for linking at all).
I need to specify the full path to the compiler executable for building with maven-nar.
The aol.properties file seems to only accept certain predefined values for the compiler name.
How do I tell the nar plugin exactly where my compiler and linker executables are. In this case I am trying to compile for ios from macosx.
Looks like the only way is to add the compiler to CppTasks and install the 'hacked' version on your build host.
Here is the version I would use as a starting point: http://duns.github.com/maven-nar-plugin/cpptasks.html
There is starting to be some effort to merge the NAR branches
https://github.com/maven-nar/maven-nar-plugin
Would be worthwhile raising issues there.
For Windows 32/64 bit support different compiler paths where needed if wanting to run maven once without changing environment variables to build both platforms.
There is a work in progress, been using for a while, but not really published it. I'm using windows only and never tried it on mac.
https://github.com/GregDomjan/maven-nar-plugin/tree/multi
I was aiming to merge it with trunk and have not had a chance yet to load the matching cpptasks changes required to allow provision of the path and some other settings.
Unfortunatly there where also a bunch of other changes that may be uncessary around configuration.