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/

Hey! Here is a minimal reproducible example, where the compile_commands.json file generated by the tool compdb looks like:

[
    {
        "command": "/usr/bin/g++ -c -I . main.cc --std=c++11 -g3 -pipe -DDEBUG -Wall -Werror -fPIC",
        "directory": "<project_dir>/plz-out/gen",
        "file": "<project_dir>/main.cc"
    }
]

There are currently two issues:

Issue 1

In command, the path to the cc file is a relative one (main.cc in this case). This path, however, expands to <project_dir>/plz-out/gen/main.cc, which does not exist. If you run Clang tools such as clang-tidy against the source file, you'll get an error like:

clang-tidy main.cc               
Error while processing <project_dir>/main.cc.
error: no input files [clang-diagnostic-error]
error: no such file or directory: 'main.cc' [clang-diagnostic-error]
error: unable to handle compilation, expected exactly one compiler job in '' [clang-diagnostic-error]
Found compiler error(s).

IIUC this is due to please by design compiling each translation unit in a temporary directory plz-out/tmp/... using the source file copied into it, instead of the one in the source tree.

Issue 2

This command string is missing include paths. I would expect it to contain -isystem lib/include. Without it Clang tools won't work.

What I also noticed was that the query result from plz query graph (see attached file) is already missing include paths.
plz_query_graph.json

Is there already any workaround to mitigate this issue? If not, I would be happy to contribute.

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]

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.

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.

Flagged by @sdtqb on Gitter

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!

Hello, I've been trying to get a minimal C++ project working with please.

I want to be able to run googletest tests and hit the following build error when using cc_test

❯ plz build
Build stopped after 10.26s. 1 target failed:
    //src:my_test
Error building target //src:my_test: exit status 1
ld: unknown options: -noall_load 
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I made a fork of this repository, changed the flag -all_load to -force_load and removed the -noall_load flags from build_defs/cc.build_defs. I can build and run the test with that change.

However, the GitHub actions for this repository are failing.
I'm not convinced they are failing due to this change, though, as other pull requests have them failing in the same way.

I'm opening this issue as a means of communication.
I'd be happy to help address this however I can.

Here is a minimal set of files to reproduce this issue:

contents of .plzconfig

[please]
version = 17.7.0

[parse]
preloadsubincludes = ///cc//build_defs:cc

[Plugin "cc"]
Target = //plugins:cc

contents of plugins/cc/BUILD

plugin_repo(
  name = "cc",
  revision = "v0.4.0",
  plugin = "cc-rules",
  owner = "please-build",
)

contents of third_party/cc/BUILD

github_repo(
    name = "gtest",
    bazel_compat = True,
    repo = "google/googletest",
    revision = "release-1.8.1",
)

cc_library(
    name = "main",
    deps = [
        "///third_party/cc/gtest//:gtest_main",
    ],
    visibility = ["PUBLIC"],
)

contents of src/BUILD

subinclude("///cc//build_defs:c")
package(cc = {
    "test_main": "//third_party/cc:main",
})

cc_test(
    name = "my_test",
    srcs = ["test.cc"],
)

contents of src/test.cc

#include "gtest/gtest.h"

TEST(GTest, Number1) {
  int a = 5;
  int b = 7;
  EXPECT_EQ(12, a + b);
}

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).