Default copts

920 views
Skip to first unread message

sneak...@gmail.com

unread,
Apr 8, 2015, 3:49:00 PM4/8/15
to bazel-...@googlegroups.com
Suppose I want all cc_binary/cc_library/cc_test rules (e.g. in a given package, or in a given workspace) to be built with the same set of copts. How could I do this? I can think of a couple of places to start, but they seem unsatisfactory:

1. Create a .bazelrc in the workspace root with the line "blaze build --copts=FOO"

This overrides the .bazelrc in my home directory (which has a pointer to the tools directory in my clone of the bazel repository). This is also not package-specific.

2. Copy the tools directory from the bazel repository to my workspace, and then figure out how to add an option to the CROSSTOOL specification.

This is not documented and will cause some merge headaches as I pull new bazel updates and have to update the tools directory, though I suppose it will make my build more hermetic (though this is not a goal of mine particularly).

Thanks
Matt

Ulf Adams

unread,
Apr 8, 2015, 4:24:14 PM4/8/15
to sneak...@gmail.com, bazel-...@googlegroups.com
That sounds like a pretty good summary to me. I don't think we currently have a third option. (I think option 2 is pretty straightforward, but you're right that there's a potential for merge conflicts.)

We do have infrastructure for project files, which can be used to specify a set of options and targets, but it's marked experimental and there's no bazel implementation right now. We've also considered supporting rules specifying options for their dependencies, but it's both difficult to implement, and difficult to ensure it doesn't exponentially explode the amount of work bazel has to do.


--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/4f62d7c2-d4ea-4ef9-982c-4b95b85347fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Han-Wen Nienhuys

unread,
Apr 9, 2015, 3:58:07 AM4/9/15
to sneak...@gmail.com, bazel-...@googlegroups.com
One option is to create a skylark macro that invokes native.cc_binary
with your preferred set of options, and use that throughout.

On Wed, Apr 8, 2015 at 9:48 PM, <sneak...@gmail.com> wrote:
> --
> You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
> To post to this group, send email to bazel-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/4f62d7c2-d4ea-4ef9-982c-4b95b85347fa%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Han-Wen Nienhuys
Google Munich
han...@google.com

marcelo...@gmail.com

unread,
Mar 13, 2016, 1:23:18 AM3/13/16
to bazel-discuss, sneak...@gmail.com
Loading variables from a .bzl file seems to work just fine:

cc_opts.bzl:
COPTS = [
"-I/usr/local/include",

]

BUILD:
load("//…:cc_opts.bzl", "COPTS")

cc_binary(

copts = COPTS,

)

Brian Silverman

unread,
Mar 13, 2016, 1:25:27 AM3/13/16
to marcelo...@gmail.com, bazel-discuss, sneak...@gmail.com
Also, creating a tools/bazel.rc is now an option. That file works like a .bazelrc, except it doesn't override a local .bazelrc.

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

marcelo...@gmail.com

unread,
Mar 13, 2016, 1:53:28 AM3/13/16
to bazel-discuss, marcelo...@gmail.com, sneak...@gmail.com
That's better; thanks!

Slightly annoyed that I had to add nocopts = "-std=c\+\+0x" to every cc_binary/cc_library in order to avoid --copt=-std=c++1z getting clobbered. Will we see a --nocopts in future? Or is there another way to solve this now? I know I can drag in and tweak the base cpp package, but that seems to be overkill, given that I only want to override a few default settings, and I don't want to have to watch for changes to the base package as bazel evolves.
Reply all
Reply to author
Forward
0 new messages