This PR introduces a `codeql_pack_rule` that does the heavy lifting
of extracting arch- and common zip files for production dist building.
It also factors out the installer targets for individual packs,
as well as pack groups.
This changes the contract between the internal build system and the pack
definition significantly, which is why an accompanying internal PR is required.
No backwards compatibility layer is provided, as the PR as complex enough as-is.
The individual `codeql_pack` rules are now much simpler,
as they mostly stuff their inputs into a new `_CodeQLPackInfo` provider,
and let the installer and `codeql_pack_group` rules do the heavy lifting.
For working in the external repo with self-contained packs,
the per-pack installer targets are still available.
Internally, we'll only use the new `codeql_pack_group` targets
going forward, both for defining intree-dists and for building
the production zip files.
This encapsulate arch specific logic, local installation and separation
of zip files into generic and arch-specific parts as required by the
internal build.
The test sdk that we were prebuilding to run ql tests is actually not
needed, as the `resource-dir` we package for cross-version compatibility
is enough for running qltests as well.
The bazel -> cmake generator is currently not capable of handling
separate included generated cmake files making use of common C/C++
dependencies.
To work around this limitation, a single generated cmake is now in
place. Long-term, we should either:
* make the cmake generator handle common dependencies gracefully, or
* make the cmake generation aspect travel up `pkg_` rules `srcs`
attributes
so to avoid having to list the targets to be generated in the top-level
`BUILD` file.
Other things fixed:
* removed some warning spam about redefined `BAZEL_CURRENT_REPOSITORY`
* fixed the final link step, that was failing because `libswiftCore.so`
was not being linked.
This is in preparation for the extractor to use shared libraries
packaged alongside it.
We could probably also move the `CODEQL_EXTRACTOR_SWIFT_RUN_UNDER` logic
in it, where it would be simpler and more robust.
The information that was contained in `schema.yml` is now in
`swift/schema.py`, which allows a more integrated IDE experience
for writing and navigating it.
Another minor change is that `schema.Class` now has a `str` `group`
field instead of a `pathlib.Path` `dir` one.
Python code was simplified, and now a `--generate` option can be used
to drive what can be generated.
The extractor pack creation now will use an internally generated
dbscheme. This should be the same as the checked in one, but doing so
allows `bazel run create-extractor-pack` and `bazel run codegen` to be
run independently from one another, while previously the former had to
follow the latter in case of a schema change. This is the change that
triggered the above simplification, as in order for the two dbscheme
files to be identical, the first `// generated` line had to state the
same generator script.
Providing `--dynamic_mode=fully` (for example setting it in
`local.bazelrc`) will now work.
All runfiles are now copied in the extractor pack: in dynamic mode,
those will be the executable and the dynamic libraries, while in static
mode only the executable will be part of the runfiles.
Setting the correct `LD_LIBRARY_PATH` in `qltest.sh` then allows to
run tests with this pakcage. If we need something more, we can switch to
a wrapper script in place of `extractor` in the future.
Notice that `LD_LIBRARY_PATH` is also set in static mode, but that has
no consequence.
This checks in the trapgen script generating trap entries in C++.
The codegen suite has been slightly reorganized, moving the templates
directory up one level and chopping everything into smaller bazel
packages. Running tests is now done via
```
bazel run //swift/codegen/test
```
With respect to the PoC, the nested `codeql::trap` namespace has been
dropped in favour of a `Trap` prefix (or suffix in case of entries)
within the `codeql` namespace. Also, generated C++ code is not checked
in in git any more, and generated during build. Finally, labels get
printed in hex in the trap file.
`TrapLabel` is for the moment only default-constructible, so only one
single label is possible. `TrapArena`, that is responsible for creating
disjoint labels will come in a later commit.
* fixed 5.0.0 as bazel version
* made dependencies better loadable
* moved `//swift/install` to `//swift:create-extractor-pack` (following
the clearer ruby naming)
* renamed `extractor_pack` to `extractor-pack` for consistency with Ruby
This adds a first dummy extractor for swift.
Running `bazel run //swift:install` will create an `extractor_pack`
directory in `swift`. From that moment providing `--search-path=swift`
will pick up the extractor.
