C++/C#: Move the Windows autobuilder into a subfolder in ql/csharp.
#16487
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a necessary preparation for moving the C# dependency management to `paket`, which in turn is a necessary preparation for moving the C# build to bazel. As we discovered in #16376, `paket` tries to restore all projects recursively from the root folder. If we support building C# code under both `ql/csharp` and `ql/cpp`, we need to have a single lockfile under `ql`, as both codebases share the same set of dependencies (and utilities from `ql/csharp/extractor`). Then, `paket` will also try to restore things that look like "C# projects" in other languages' folders, which is not what we want. Therefore, we address this by moving all C# code into a common root directory, `ql/csharp`. This needs an internal PR to adjust the buildsystem to look for the autobuilder in the new location.
criemen
force-pushed
the
criemen/move-win-autobuilder
branch
from
18930cc
to
869bf8a
Compare
criemen
added
the
depends on internal PR
|
As discussed in the other PR, waiting for explicit approval from @github/codeql-c-extractor , who are currently at an offsite. |
jketema
reviewed
May 14, 2024
There was a problem hiding this comment.
Change-wise this LGTM, just one little comment.
Before approving this I'd like to understand two things related to releases:
- Will the C++ Windows autobuilder still be included?
- Will the C++ Windows autobuilder still be included in such a way that it is correctly picked up when attempting autobuild of a C/C++ project on Windows?
Co-authored-by: Jeroen Ketema <93738568+jketema@users.noreply.github.com>
|
Re releases: The internal PR changes the path where we're looking for the autobuilder, so that it's still correctly included in the released bundle. I verified that manually with a bundle build. The invocation of the autobuilder doesn't change at all by the moving of the directories. |
jketema
approved these changes
May 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a necessary preparation for moving the C# dependency management to
paket, which in turn is a necessary preparation for moving the C# build to bazel.As we discovered in #16376,
pakettries to restore all projects recursively from the root folder. If we support building C# code under bothql/csharpandql/cpp, we need to have a single lockfile underql, as both codebases share the same set of dependencies (and utilities fromql/csharp/extractor).Then,
paketwill also try to restore things that look like "C# projects" in other languages' folders, which is not what we want.Therefore, we address this by moving all C# code into a common root directory,
ql/csharp.This needs an internal PR to adjust the buildsystem to look for the autobuilder in the new location.