I'm trying to find a name for a new backend that will go under

pants.backends.experimental

. Which of these backend names look best? • 1️⃣

native_libs

• 2️⃣

native_shared_library_deps

• 3️⃣

native_deps

• 4️⃣

native_lib_links

• 5️⃣

shared_lib_deps

• 6️⃣

native_lib_deps

• 7️⃣

native_linked_libraries

• 8️⃣

native_linked_libs

Background: https://github.com/pantsbuild/pants/discussions/22396 Rejected names: •

bindeps

•

binary_deps

IMHO

binary

can be confused with

pex_binary

, so I would choose between

native

variants 2, 3 or 6

Oh right. Good point about how

_binary

is used in target names. I edited the options and added a few to replace the ones with

binary

.

What is this for?

I think

deps

have the same problem as

binary

because

dependencies

have a settled meaning in pants targets

What about

native_lib_needs

? It plays off of

NEEDED

, the term for dependencies in elf binaries +

.so

shared objects. Other formats do not use the term `NEEDED`: Mach-O

.dylib

format uses the term "load command" or

LC_LOAD_DYLIB

. And PE

.dll

format records DLL "imports" in the

.idata

section.

I read the background link, and I'll have to admit I don't entirely understand it, but I looked up some of the associated tooling. Does this create those libs? One of the comparables seems like it "discovers" system libraries? Or is it any library from any location? Would this backend compile/create those libraries? All of those terms are generic enough that I wouldn't know what they're doing at a glance, and by default, I would assume they have to do with a C/C++/Rust compilation step

> Is this backend an "inspection" type tool? > That's a good description. In a way, it is a linter for binary artifacts, with the potential to add some fixer features as well. The backend would do more than just wrap one of these tools. I'm using nfpm (via the nfpm backend) to make system packages (rpm, deb), but it does not provide the auto-deps feature that native packagers provide (ie rpmbuild runs elfdeps when building rpms to extract a list of required SONAMEs and dpkg runs something similar, mapping the detected SONAME to a deb installed on the host system). Ultimately, I'm trying to replace the auto-deps functionality from rpmbuild and dpkg when using nfpm. Also, I don't want to find the .so deps on the host system (unlike dpkg). So, I wrote some logic that queries the online Debian or Ubuntu package search sites to find which package provides the SONAME dep. Some of the tools that detect lib deps can also modify binaries to change or to bundle the lib so that a package-level dep is no longer required. I don't intend to write that for now, but I want to leave room to add that later if someone needs it.

Then is that something that should currently live in the nfpm backend until it's used in more places?

Hmm. That's an interesting thought. I'll play with putting it under the nfpm backend.