C++ global options

[kram...@gmail.com]

All -

I am interested in using C++14 for compiling my entire C++ code base. How do I enable this gcc/clang option --std=c++14 globally in bazel 0.2.3/bazel 0.3.0?

Would appreciate if somebody can respond. Thanks

cheers
/karthik

[Brian Silverman]

The easy way is with --copt. You can put "build --copt=--std=c++14" in your tools/bazel.rc to add it by default. If you have C code too, you'll want --cxxopt instead (and maybe --conlyopt for similar settings for the C code).

You could also create a custom CROSSTOOL, but that's going to more work to set up and maintain without any benefit if you're just setting a few flags.

/karthik

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/0edf51b1-f0f8-4ce9-865c-0a7d0cdbcf00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Karthik Ramada my]

Thanks for the suggestion - it worked.

Sent from my iPhone

[bre...@gmail.com]

Hi Brian,

I am wondering what is the version of your bazel?

I tried adding `build --copt=-std=c++14` in tools/bazel.rc, but bazel build is still complaining about not having it ...

[harn...@gmail.com]

Same here: I added the option in tools/bazel.rc with no luck; upon building the compiler still complains about C++14-only constructs.
Debugging, it seems that Bazel issues this huge command, where the C++14 option is present together with another for C++0x (and presumably the latter is winning):

/usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '--std=c++14' '-std=c++0x' -MD -MF bazel-out/local-fastbuild/bin/test/util/_objs/traits/test/util/traits.pic.d '-frandom-seed=bazel-out/local-fastbuild/bin/test/util/_objs/traits/test/util/traits.pic.o' -fPIC -iquote . -iquote bazel-out/local-fastbuild/genfiles -iquote external/gtest -iquote bazel-out/local-fastbuild/genfiles/external/gtest -iquote external/bazel_tools -iquote bazel-out/local-fastbuild/genfiles/external/bazel_tools -isystem external/bazel_tools/tools/cpp/gcc3 -Iexternal/gtest/googletest/include/ -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c test/util/traits.cpp -o bazel-out/local-fastbuild/bin/test/util/_objs/traits/test/util/traits.pic.o)

How can I tell Bazel NOT to put the --std=c++0x option?

[Irina Iancu]

+Marcel

--
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-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/419ff3b4-6ba8-4dda-b386-66ad4ebfb60c%40googlegroups.com.

[Marcel Hlopko]

Bad news, Bazel uses --std=c++0x unconditionally at the moment. I might be able to change this, there are multiple options with varying level of sanity, but it will take some time. What you could do right now is to build something, then take the generated crosstool and the corresponding BUILD file from the output_base (bazel info will tell you where it is), copy it to your workspace, fix it, and then add --crosstool_top flag into your bazel.rc so Bazel will start using it instead of the builtin one. Would that work for you? It's true that you'll have to maintain the crosstool, but the generated crosstool is so simple that Bazel patches it with all the new stuff anyway. So you'll rarely need to touch it. But no promises :)

Did this help?

On Mon, Jul 3, 2017 at 2:07 PM Irina Iancu <elena...@google.com> wrote:

+Marcel

On Sun, Jul 2, 2017 at 1:25 AM, <harn...@gmail.com> wrote:

Same here: I added the option in tools/bazel.rc with no luck; upon building the compiler still complains about C++14-only constructs.
Debugging, it seems that Bazel issues this huge command, where the C++14 option is present together with another for C++0x (and presumably the latter is winning):

/usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '--std=c++14' '-std=c++0x' -MD -MF bazel-out/local-fastbuild/bin/test/util/_objs/traits/test/util/traits.pic.d '-frandom-seed=bazel-out/local-fastbuild/bin/test/util/_objs/traits/test/util/traits.pic.o' -fPIC -iquote . -iquote bazel-out/local-fastbuild/genfiles -iquote external/gtest -iquote bazel-out/local-fastbuild/genfiles/external/gtest -iquote external/bazel_tools -iquote bazel-out/local-fastbuild/genfiles/external/bazel_tools -isystem external/bazel_tools/tools/cpp/gcc3 -Iexternal/gtest/googletest/include/ -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c test/util/traits.cpp -o bazel-out/local-fastbuild/bin/test/util/_objs/traits/test/util/traits.pic.o)

How can I tell Bazel NOT to put the --std=c++0x option?

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/419ff3b4-6ba8-4dda-b386-66ad4ebfb60c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 

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

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

[harn...@gmail.com]

Thanks a lot Marcel!!!
Your suggestion worked, with the additional fix of replacing "osx_cc_wrapper.sh" with the direct clang path. Useless to say, I think that supporting newer version of the standard would be an important feature for future releases of Bazel :)

[Marcel Hlopko]

Glad it worked. Yeah I'll take a look at that once I have a free afternoon. The problem is that we reached a point where our autoconfiguration (which was born as a quick hack) is complicated enough that it needs a more principled solution. I'm not sure how it will look like yet.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/cb0f454e-e2a8-49fc-8de9-1a0b8e67f75c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Giorgio Audrito]

Bad news... your suggestions helped but didn't solve the problem completely: now the "build" phase works while the "test" phase fails. My best guess is that I shouldn't have bypassed the osx_cc_wrapper: however, the wrapper is not copied into the sandbox during build (that is why I bypassed it) even if I copy it in my tools/cpp directory. How can I tell Bazel to include it?

Many thanks in advance!

(and sorry to bother you again, but I hope this conversation might help some other people in the future!)

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/cb0f454e-e2a8-49fc-8de9-1a0b8e67f75c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Marcel Hlopko]

Oh, is it just bazel complaining that it cannot find some of the wrapper scripts? Or what do you mean by bypassing osx_cc_wrapper? Removing it from cc_toolchain rule in the BUILD file and from the tools section in the CROSSTOOL? What error do you see?

In any case, in the BUILD file you'll see bunch of cc_toolchain rules, one of them is the one you are using. Here make sure you include all the additional files in the all_files, compiler_files, and linker_files (you can just create filegroup for all wrapper scripts and pass that into these attributes).

Also, are you building on mac? In that case we have 2 crosstools, one in tools/cpp/CROSSTOOL, and one in tools/osx/CROSSTOOL. First one is C++ only, when bazel doesn't find Xcode installed, the second one is C++ + ObjC, and is used when you do have Xcode installed.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/cb0f454e-e2a8-49fc-8de9-1a0b8e67f75c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 

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

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

[Giorgio Audrito]

Hi Marcel, thanks again for spending your time to answer my questions. I'll try to specify as clearly as I can my whole situation:

• the project consist of a C++-only library;
• I am building the project both on my macbook (macOS sierra) and on an ubuntu virtual machine (vagrant+virtualbox);

the best partial fix that I came up with using your suggestions (including your last one) is:

• copy the files tools/cpp/{CROSSTOOL,BUILD} from the bazel-generated tool folder bazel-projectname/external/bazel_tools/...
• find/replace every occurrence of c++0x with c++14 in CROSSTOOL
• replace every occurrence of osx_cc_wrapper.sh in CROSSTOOL with the absolute path to the same file

With these "dirty fixes", building and testing of my files works both on macOS and on the ubuntu virtual machine. However, bazel build //... fails while building //tools/cpp, since it cannot find some files referenced in BUILD (which actually makes sense since I only copied the CROSSTOOL file). To "sanitize" things I also tried to:

• include the osx_cc_wrapper.sh as filegroup in the cc_compiler_darwin toolchain, but it ended up complaining that link_dynamic_library.sh was failing
  
  
• copy every other file which might be needed, including the tools/{cpp,build_defs} directory but it was still complaining of missing stuff (a docker repository...)

In the end, I can live with my current situation (building/testing of individual packages works) and avoid to build directly the root (//...). However, it would still be nice if you had some suggestions on "which files to include in the cpp folder" VS "lines to remove in the BUILD file" to obtain a consistent setup.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/cb0f454e-e2a8-49fc-8de9-1a0b8e67f75c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 

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

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

[Giorgio Audrito]

I add a further data: even though build/test is working locally, it does not work on Travis (https://travis-ci.org/Harniver/fcpp).

[Marcel Hlopko]

Hi Giorgio,

I'm going on vacation next week, so maybe somebody else will have time to look at this, or I will when I come back. 

Happy hacking :)

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/cb0f454e-e2a8-49fc-8de9-1a0b8e67f75c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 

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

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

--

-- 

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

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

[Marcel Hlopko]

Hi Giorgio,

it seems https://github.com/Harniver/fcpp/tree/master/tools/cpp doesn't include some of the scripts, like link_dynamic_binary.sh that travis is complaining about?

[ti...@google.com]

Marcel (or anyone) -

Is this thread still the state-of-the-art for changing C++ versions? I'd really like a simple (even not maintainable) process for doing this for the demo I'm giving at CppCon next week, and having to explain crosstools would derail it a bit. Any suggestions would be very welcome.

Cheers,
-Titus

On Wednesday, July 19, 2017 at 4:32:20 AM UTC-4, Marcel Hlopko wrote:
> Hi Giorgio,
>
>
> it seems https://github.com/Harniver/fcpp/tree/master/tools/cpp doesn't include some of the scripts, like link_dynamic_binary.sh that travis is complaining about?
>
>
> On Fri, Jul 7, 2017 at 5:20 PM Marcel Hlopko <hlo...@google.com> wrote:
>
> Hi Giorgio,
> I'm going on vacation next week, so maybe somebody else will have time to look at this, or I will when I come back. 
> Happy hacking :)
>
>
> On Fri, Jul 7, 2017 at 5:12 PM Giorgio Audrito <harn...@gmail.com> wrote:
>
> I add a further data: even though build/test is working locally, it does not work on Travis (https://travis-ci.org/Harniver/fcpp).
>
>
> 2017-07-07 14:45 GMT+02:00 Giorgio Audrito <harn...@gmail.com>:
>
> Hi Marcel, thanks again for spending your time to answer my questions. I'll try to specify as clearly as I can my whole situation:
>
> the project consist of a C++-only library;I am building the project both on my macbook (macOS sierra) and on an ubuntu virtual machine (vagrant+virtualbox);
> the best partial fix that I came up with using your suggestions (including your last one) is:

> copy the files tools/cpp/{CROSSTOOL,BUILD} from the bazel-generated tool folder bazel-projectname/external/bazel_tools/...find/replace every occurrence of c++0x with c++14 in CROSSTOOLreplace every occurrence of osx_cc_wrapper.sh in CROSSTOOL with the absolute path to the same file

[Brian Silverman]

This way still works, and I don't think there's anything better. If you're looking for a way to hide all this, put the toolchain in an external repository (git or http or local or whatever; you don't want the new_* repository rules because all the BUILD files are already there). Then you only need to add it to WORKSPACE and put "build --crosstool_top=@my_toolchain_repository//tools/cpp:toolchain" in tools/bazel.rc to use it in a fresh workspace.

Putting it in another repository also means //... won't pick it up, so if you copy extra targets/files/etc it won't cause problems like some people earlier in this thread earlier were running into.

It's possible somebody has added a simpler way to change just the version since, but I don't see one in tools/cpp/unix_cc_configure.bzl where I would expect it.

[sali...@gmail.com]

Does this method no longer work? Is there another way to do it?

I copied tools from output_base into my workspace. I replaced all occurrences of c++0x in the tools directory with c++11. I then compiled with:
bazel build --crosstool_top=//tools/cpp:toolchain

Yet somehow:
/usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' ....

where is the std=c++0x coming from?

I am on Ubuntu, if that helps

Salil

[rach...@foghorn.io]

Same here.
Anyone know the root cause?

[storf...@gmail.com]

I'm on bazel 0.25.0.

It seems that setting the environment variable BAZEL_CXXOPTS to e.g. -std=c++14 works (in that it replaces the other -std setting). This can also be done in the .bazelrc file via a line

build --action_env=BAZEL_CXXOPTS=-std=c++14