Previously we maintained three types of builds: a fully internal BUCK build, a
CMake build with modifications to use things from an internal toolchain, and an
open source CMake build.
As far as I'm concerned the intermediate build is not useful because our source
is readily available in both an internal and external form. Use cases as
follows:
1. BUCK build for distributing widely.
2. BUCK build for getting a static binary that can be run on any machine.
3. CMake build for primary development.
4. CMake build for external CI.
With the internal update to CentOS Stream 9 an unmodified CMake build now works
readily. This change patches up some things that were relying on system headers
that should have been vendored and cleans up drgn dependencies.
Test plan:
- It builds.
- TODO: Document CentOS 9 installation.
Summary:
oilgen: migrate to source parsing
Using debug information generated from partial source (that is, not the final
binary) has been insufficient to generally generate OIL code.
A particular example is pointers to templates:
```cpp
#include <oi/oi.h>
template <typename T>
struct Foo {
T t;
};
template <typename T>
struct Bar {
Foo<T>& f;
};
void foo(const Bar<int>& b) {
oi::introspect(b);
}
```
The pointer/reference to `Foo<int>` appears in DWARF with
`DW_AT_declaration(true)` because it could be specialised before its usage.
However, with OIL, we are creating an implicit usage site in the
`oi::introspect` call that the compiler is unable to see.
This change reworks OILGen to work from a Clang command line rather than debug
information. We setup and run a compiler on the source, giving us access to an
AST and Semantic Analyser. We then:
- Find the `oi::introspect` template.
- Iterate through each of its callsites for their type.
- Run `ClangTypeParser::parse` on each type.
- Run codegen.
- Compile into an object file.
Having access to the semantic analyser allows us to forcefully complete a type,
as it would be if it was used in the initial code.
Test Plan:
hope
`buck2 run fbcode//mode/opt fbcode//object-introspection/oil/examples/compile-time:compile-time`
Reviewed By: tyroguru
Differential Revision: D51854477
Pulled By: JakeHillion
Adds the range-v3 library which supports features that otherwise wouldn't be
available until C++23 or C++26. I caught a couple of uses that suit it but this
will allow us to use more in future.
Test Plan:
- CI
Summary:
Spin around our open/closed source checks. Previously we defined `OSS_ENABLE` in open source builds. This change defines `OI_META_INTERNAL` instead. This is nicer, as external users don't have to do anything special to get a working build.
Use this new macro to define a boolean constant in a new header `Portability.h`. This is inspired by Folly, and makes the internal build easier - definitions in Buck2 have to propagate up from a dependency instead of down from one. Annoyingly we can't use `if constexpr` for a lot of the previous `#ifdef` blocks as we conditionally include the headers. Longer term we could fix this by exposing a header interface but no source, allowing these to build but not be compiled in. For now I did something weird: I defined a function style macro in `Portability.h` based on the compile time macro. This forces you to have included `Portability.h` before using it to ensure the definition is everywhere. Open to feedback as I haven't seen anyone else do this.
Reviewed By: tyroguru
Differential Revision: D50000454
Summary:
Previously OID/OIL required exactly one configuration file. This change makes it so you can supply 0 or more configuration files. 0 is useful if you have pre-generated the cache or use some sort of remote generation system. 1 is useful for the common case, where you have a configuration file that describes your entire source and use just that. More are useful if you have supplemental bits of config you wish to apply/override - see the changes to the integration test framework where we do exactly this.
Test Plan:
This isn't super well tested. It works for the test cases which add features via the config or enable `codegen.ignore`.
- CI
Reviewed By: ajor
Differential Revision: D49758032
Pulled By: JakeHillion
Github is currently extremely slow to load for me for some reason.
Due to that, I first thought that `cmake` is hung up, but tracing
that I realized it's waiting for minutes to download the sources
for tomlplusplus via FetchContent.
This patch enables progress reporting for FetchContent to make it
more obvious what's going on here.
Summary:
Update to clang-15 compiler and libraries as clang-12 is ancient.
The changes to oilgen are necessary because the new internal toolchain is being more picky about linking PIC to PIC. In certain modes we build with PIC, but try to link a non-PIC oilgen artifact. Add the ability to build the oilgen artifacts with PIC which sorts this.
Reviewed By: ttreyer
Differential Revision: D46220858
With the previous method of enabling them on a target-by-target basis,
it was very easy to accidentally miss a target. This had happened in a
number of instances, e.g. "codegen" and "symbol_service".
Previously we had an `R"(` string in `OITraceCode.cpp` which allowed us
to include the file as a string. Instead, keep `OITraceCode.cpp` a fully
formed C++ file and utilise the build system to turn it into a string.
This will be used for more header files that are needed both as valid
headers and as strings for JIT compilation in the Typed TreeBuilder
work.
To help with the transition to type-graph based CodeGen, we need to
reduce dependencies on legacy CodeGen from other parts of OI.
Pieces of CodeGen referenced by other files, but which only return
drgn data have been moved into a new "drgn_utils" target, allowing
us to remove CodeGen dependencies for these functions.
The new "symbol_service" build target can be used in the future by
other files only needing access to symbol information and not full
CodeGen.
Add CODE_COVERAGE option to enable coverage instrumentation in builds.
Add new CI job to upload coverage reports to CodeCov.io.
Reports can be found by navigating the codecov.io UI, or by going to
the URL printed at the end of the "Code Coverage" CI job. More CodeCov
integration could be set up later once we have coverage reporting on the
main branch.
