cc: split up rules for building c and c++ code [BUILD-560]

[jungleraptor]

Splits up our swift_cc* wrappers into two sets of functions for building c and c++ code separately

Design Notes

We use the swift wrappers to enforce that (among other options), we set the following flags consistently across our codebase:

• -fno-exceptions
• -fno-rtti
• -std=c++14
• -std=c99

Unfortunately bazel cc* rules don't support distinguishing between options for the c compiler and options for the c++ compiler:

cc_library(
    name = "gnss_converters",
    srcs = [
        "src/common.c", # c file
        "src/time_truth.cc", # c++ file
    ],
    hdrs = [
       ...
    ],
    copts = [ # copts applies to both .c and .cc files
       "-fno-exceptions", # Warning when applied to c file
       "-Werror", # Warning is promoted to an error
    ]
)

The solution proposed here is to split up building c and c++ code into two functions so the problematic flags can be applied separately.

Usage

Examples, see related PR's for actual implementations:

swift_c_library(
    name = "time_truth",
    srcs = [
        "src/time_truth.c",
    ],
    extensions = True, # enables GNU extensions; -std=gnu
    standard = 11, # sets the c11 standard
    ...
)

swift_cc_library(
    name = "time_truth_v2",
    exceptions = True, # build with -fexceptions
    rtti = True, # build with -frtti
    standard = 17, # build with c++17 standard
    srcs = [
        "src/time_truth_v2.cc",
    ],
    ...
)

swift_c_library(
    name = "gnss_converters",
    deps = [
        ":time_truth",
        ":time_truth_v2",
    ],
)

Also adds flags for enabling exceptions and rtti globally:

bazel build --@rules_swiftnav//cc:enable_exceptions=true //...

bazel build --@rules_swiftnav//cc:enable_rtti=true //...

Also adds a flag for overriding the default c++ standard:

bazel build --@rules_swiftnav//:cc:cxx_standard=17 //...

Testing

New features were tested in the following PR's:

• https://github.com/swift-nav/gnss-converters-private/pull/1468
• https://github.com/swift-nav/starling-core/pull/237

Related PR's:

This PR cannot be merged in standalone without breaking a whole bunch of builds.
We'll need to first merge empty stub functions across the codebase, then come back and merge this one:

• cc: add c stubs [BUILD-560] #51

[jungleraptor]

cc @woodfell @RReichert thought it'd be good to tag you two for review. This essentially wraps up the API for the swift_cc rules wrappers.

[RReichert]

@isaactorz the one area that I see that might have issues with this is gnss_converters where were have C/C++ code in a single library, maybe some of the tests as well might face some issues.

[jungleraptor]

@isaactorz the one area that I see that might have issues with this is gnss_converters where were have C/C++ code in a single library, maybe some of the tests as well might face some issues.

Check out this PR where I've tested: https://github.com/swift-nav/gnss-converters-private/pull/1468

But basically getting gnss-converters built correctly is what this PR addresses, since it's pretty much the only place in the codebase where we've been mixing languages.

[krisukox]

I tested it locally with gnss_converters, and it worked well. LGTM.