Working on the C/C++ `check` backend and ran into ...
# development
Working on the C/C++
backend and ran into a mild quandry. I have the following folder structure in most/all of my projects:
Copy code

Inside of app/main.cpp, I have something like:
Copy code
#include "mylibrary/foo.h"
#include "bar.h"
As of today's dependency inference, the
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
pass or fail. If I run
on my sample repos, they'll fail - because the dependency inference can't presume the additional
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
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
(just a thought)
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
As mentioned, as of today, I can already write a custom BUILD file to make this work, but I can happily leverage the
flag for gcc, if there was a nice, clean way to add it
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
pick them up?
the convention could be to infer
as base directories for dependency inference; no
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
👍 1
Excellent. this is a good place to build from. Thanks!
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
@fast-nail-55400 @enough-analyst-54434 Any samples of doing this in the existing codebase? Most of the dep_inferences grab files against their
- but I don't see examples specifically related to empty source roots as a directory. Unless I would need to create some sort of
type of thing from
? I'm assuming there is already a better way?
🤦‍♂️ nvm - thought I was doing it wrong, but turns out I had a case sensitivity error - everything is compiling nicely now!
👍 1