https://pantsbuild.org/ logo
#development
Title
# development
w

wide-midnight-78598

08/01/2022, 5:18 PM
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:
Copy code
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:
Copy code
#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?
1
b

bitter-ability-32190

08/01/2022, 5:24 PM
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)
w

wide-midnight-78598

08/01/2022, 5:28 PM
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
-I
flag for gcc, if there was a nice, clean way to add it
e

enough-analyst-54434

08/01/2022, 5:30 PM
A list of include dirs feels exactly like a list of source roots to me.
3
b

bitter-ability-32190

08/01/2022, 5:31 PM
I really think theres a sane set of defaults to use that'll cover the 90% case
w

wide-midnight-78598

08/01/2022, 5:31 PM
So, would that involve putting a BUILD in each source root and have the
pants.toml
pick them up?
f

fast-nail-55400

08/01/2022, 5:31 PM
the convention could be to infer
SOURCE_ROOT/include
or
SOURCE_ROOT/includes
as base directories for dependency inference; no
BUILD
file necessary
1
w

wide-midnight-78598

08/01/2022, 5:32 PM
@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?
f

fast-nail-55400

08/01/2022, 5:33 PM
making it configurable with a reasonable default sounds good to me
w

wide-midnight-78598

08/01/2022, 5:33 PM
Common ones: include, includes, public, pub, inc, and a few more
👍 1
Excellent. this is a good place to build from. Thanks!
b

bitter-ability-32190

08/01/2022, 5:37 PM
No, thank you 🙏
w

wide-midnight-78598

08/01/2022, 5:39 PM
🙂 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
sources
- but I don't see examples specifically related to empty source roots as a directory. Unless I would need to create some sort of
AllCCSourceRoots
type of thing from
AllSourceRoots
? 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