"Repository not defined" error when trying to use an external library.

[Fædon Jóhannes Sinis]

I've forked an external library (geometry-central) in order to add Bazel build rules to make it easier to reuse in my own programs:

https://github.com/phaedon/geometry-central/blob/master/WORKSPACE

This works wonderfully when simply cloning this repo and building it in the cloned directory as:

bazel build --cxxopt=-std=c++17 ...

In this WORKSPACE file, I've pulled in an external dependency on happly so that it is self-contained without reliance on git submodules. The symbol @happly is therefore defined in the context of the geometry-central clone.

Now: when in my own program, I try to use this repo as follows:

git_repository(

    name = "geometry-central",

    branch = "master",

    recursive_init_submodules = 0,

    remote = "https://github.com/phaedon/geometry-central.git",

)

and add it to a cc_library rule, I get compilation errors such as the following:

no such package '@happly//': The repository '@happly' could not be resolved: Repository '@happly' is not defined and referenced by '@geometry-central//:pointcloud' 

What have I done wrong here?  Is there a flag I need to set in order to say "always make all symbols defined in the external repo available to that external repo"? Otherwise it feels like I've exposed an internal implementation detail (geometry-central's reliance on happly) to clients of geometry-central.

[David Turner]

The WORKSPACE file of external repositories is always ignored by Bazel. The file must exist to indicate that this is a workspace top-level directory, but that's it.

I know this is confusing :-) Note that very often, a third-party project's WORKSPACE file will include tons of dependencies that are only used for its own development / testing, while also providing .bzl file that contains a Starlark function that can be called from your own WORKSPACE file to load non-dev dependencies.

For example, bazel-skylib provides the bazel_skylib_workspace() function from @bazel_skylib//:workspace.bzl, hence a project WORKSPACE that uses it should have a section that looks like:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "bazel_skylib",
    sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz",
        "https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz",
    ],
)

load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
bazel_skylib_workspace()

I recommend you provide a workspace.bzl file with a geometry_central_workspace() function that loads @eigen and @happly, and call that from your workspace too.

--
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/72bae484-96c4-438f-82d9-6f73f684693fn%40googlegroups.com.

[Xudong Yang]

Beyond what David said above, I'd also recommend trying out Bzlmod. The MODULE.bazel files of your transitive dependencies _are_ taken into account, as opposed to WORKSPACE Files.

"  YÁNG Xùdōng (杨旭东)

#  SURNAME Givenname

=  Software Engineer

@  Google New York

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CACnJMqoF6un%3DuWi5DAvxO410HCe3X_8RuSCcGRpURnoZQgc6Cg%40mail.gmail.com.

[Fædon Jóhannes Sinis]

Thanks for this pointer! Just a style question, as I'd like to start adding modules to https://github.com/bazelbuild/bazel-central-registry/tree/main/modules : I'd like to contribute a set of rules for commonly used libraries in graphics / ray tracing / image processing / computational geometry. Is it preferred to create one module for the whole domain, or one module per external library?

[Xudong Yang]

Normally, one module per external library would be best. Unless some libraries are *always* used together, it wouldn't make sense to bundle them.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/79e0d79c-dafd-443d-9989-c84ce4d922b4n%40googlegroups.com.