please-build/cc-rules

C and C++ rules for the Please build system

cc-rules's Issues

GCC 10 not available on `macos-latest` GHA runner image

macos-latest is now an alias for macos-13, which includes GCC 11 and 12. GitHub actions on macOS will fail until .plzconfig.gcc is updated. We should make sure GCC 11 and/or 12 are also available on ubuntu-latest before choosing one, because Ubuntu and macOS share the same configuration (or we could split them).

`-fmodules-ts` is deprecated since clang16

I got the error when running test for the main please repo:

$ plz test --profile=alpine --exclude=py3 --exclude=python3 --exclude=no-musl --exclude=x86 --exclude=gold --exclude=py2 --exclude=java --exclude=e2e --log_file plz-out/log/test_build.log --log_file_level 4 --trace_file plz-out/log/trace.json

Build stopped after 150ms. 1 target failed:
    //test/cc_rules/clang/modules:_f1#interface
Error building target //test/cc_rules/clang/modules:_f1#interface: exit status 1
clang-16: error: the '-fmodules-ts' flag is deprecated and it will be removed in Clang 17; use '-std=c++20' or higher to use standard C++ modules instead [-Werror,-Wdeprecated-module-ts]

Consider restructuring the various cflag options

Right now we have four; dbg/opt and c/c++. The only way to override them is in their entirety which often means you have to repeat two (or all four) of them in order to change one thing (e.g. say you use --std=c++17 globally but you have one package with some third-party code that needs --std=c++03).

I wonder if this should get broken out to different areas, e.g. release/debug specific (-O3 vs. -g3 etc), the language standard, and additional flags (mostly warnings/errors usually). We'd need two of the first (dbg/opt) and of the second (c/c++) and just one of the latter, so it doesn't actually increase the number of options much, but would make it quite a bit more flexible and less repetitive.

Make `-fPIC` optional.

I am using please to handle the building of STM32 projects and most of the required flags and tools are possible to implement by defining them within a .plzconfig file.
However, it looks like please always adds the -fPIC flag to the compiler flags.
It is possible to override this by defining -fno-pic in the compiler_flags section of the c/cc build rules, however this is no longer a project-wide solution as defining all the flags in .plzconfig.

The code is being compiled by arm-none-eabi-g++ instead of the default tool and the inclusion of the -fPIC flag forces the definition of a global offset table in the STM provided linker scripts, as well as potentially adding some extra overhead that isn't necessary.

I realize embedded is not necessarily the goal of the cc-rules, but I have grown to really like please and would like to use it to build all my projects, including embedded code. It's certainly versatile enough to do so!

cc_test fails with stricter compiler flags

When running cc_test on a project that specifies stricter compiler arguments such as -Werror=suggest-override, cc_test will fail as it uses unittest-pp which fails to compile with that flag.

`cc_binary`, `cc_library`, and others missing `labels` argument

Flagged by @sdtqb on Gitter

Shared libraries with binaries

So usually if I build a binary that needs a shared library (which is not installed in the system) I can do something like add a directory structure:

bin
  |-- my_ _bin
lib
  |-- shared_lib.so

And then when linking in the shared lib set the rpath as $ORIGIN/../lib/ which helps discover the shared libs.
How do I do this with the cc_rules? I can see that the shared lib never makes it to the plz-out/bin so setting something relative seems hard.

Even if I add an additional lib to the output directory using the optional_outs it still does not make it to the plz-out/bin directory which makes running things which need a shared library hard with plz run //path/to/executable. Any suggestions/help with this would be nice.

Currently I have something like:

linker_flags = ["--rpath=$ORIGIN/../../gen/path/to/mylib/"]

Which is pretty nasty (and not very scalable sadly)
Ideally this should be just --rpath=$ORIGIN/../path/to/mylib/