Working on the C/C++

check

backend and ran into a mild quandry. I have the following folder structure in most/all of my projects:

mylibrary/include/mylibrary/foo.h
mylibrary/src/foo.c

app/bar.h
app/bar.c
app/main.cpp

Inside of app/main.cpp, I have something like:

#include "mylibrary/foo.h"
#include "bar.h"

As of today's dependency inference, the

mylibrary

header may or may not be picked up depending on where the BUILD files are located and how they were generated (e.g. 111, recursive globs, etc). I can design a set of build files to make this pass or fail, or I can modify my header include to make

check

pass or fail. If I run

tailor

on my sample repos, they'll fail - because the dependency inference can't presume the additional

include

folder with no additional information, so they expect the headers to be filename only. If I put a build file with a recursive glob in the "include" folder, it works perfectly. In CMake (or other tools), it's pretty trivial to provide a list of include directories for compilation, but that doesn't feel very pants-y and almost feels like it's circumventing dep inference and BUILD files. I'm creating a

cc_library

target which will export headers + a shared/static library, but they will still run into the issue of how to lay out BUILD files in order to ensure the namespace is what I want. I, personally, have no problem creating BUILD files to that effect, but again, not very Pants-y, or automatic. Thoughts?

I think its worth some time thinking of how we can teach Pants about your (editorial "your", not "SJ your") layout/schema/convention, and that way people aren't locked in because of Pants but we also minimize boilerplate. It can start as just the one use-case you have and be expanded later

Yeah, I was thinking about that, but I was hoping that we already had some provision for this - it's a commonly weird enough use case. Also blurs the lines of convention vs configuration - which can be a double edged sword. Like, simply put, if I ever had to change a project format/layout for a build tool, that's about 95% reason not to change it. However, being able to configure, or writing configuration in a way to support my repo? No big deal, happens all the time. In the case of CMake, I'm already dropping hundreds of lines of boilerplate with this semi-functional backend - but I'm never going to change production code to support a build tool

A list of include dirs feels exactly like a list of source roots to me.

I really think theres a sane set of defaults to use that'll cover the 90% case

So, would that involve putting a BUILD in each source root and have the

pants.toml

pick them up?

the convention could be to infer

SOURCE_ROOT/include

or

SOURCE_ROOT/includes

as base directories for dependency inference; no

BUILD

file necessary

@fast-nail-55400 And this would be configurable, I guess, as part of the language backend? i've seen 3-4 different names in the wild, or would it be configurable with a list of commonly used ones as defaults?

making it configurable with a reasonable default sounds good to me

Common ones: include, includes, public, pub, inc, and a few more

No, thank you 🙏

🙂 Still a long road to go to a usable backend - but for my purposes, it's actually pretty close. I don't often use 3rd party code in my C++ stuff, so my first-party solution covers a shockingly large amount of my codebase Cough... except tests... Cough