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.
As requested by @sapphonie and other users in the SM discord, this PR aims at enabling ambuild 2.2 support for the buildscripts in this repository. Fix #11 and #10
Going over each file change :
AMBuildScript
This file follows a complete rewrite, I've mostly copied the buildscript i use in my own repositories. E.g ServerTools
The build script itself was mostly copied from SM repository, so there shouldn't be anything alien.
BreakpadSymbols
I've taken your work from SM repo, and pretty much backported it. The only thing I did not backport is
upload_symbols.py
as I simply look for it and execute it.connect/buildbot/BreakpadSymbols
Line 4 in 2824a30
I'm assuming this is alright, as extensions themselves can sometimes break compilation against newer SM codebase. So depending on a 3rd party buildscript should be fine ? Though if not desired, I'll simply bring it over in another commit.
PackageScript
I tried to limit the amount of changes I did to this file. Most of it is the same as before but I streamlined it.
Versioning
Mostly copied from SM repo, but changed so it generates the include files your extension looks for.
I also have no idea how a Mercurial repository looks like, I'm too young, so I do not which file I've to make AMBuild depend upon so it triggers a regeneration of the version header, if the user switch commit/does change locally.If the repo is instead
git
based, then it depends on the head file, much like Sourcemod.generate_header.py
- new fileI wrote this file by mixing the one from SM repo, and the python code I removed in
Versioning
so that it still generates in the same format the version file your extension requires. On that note, I also made it hybrid, so that whether the extension is built from the Mercurial repository, or the git repository, it still outputs something meaningful.configure.py
Not much to say there, this is pretty much the standard configure python file every extension out there has. However do note the presence of
--enable-auto-versioning
, this a param I added so if someone attempts to build the extension, they by default will construct an extension with "Manual" as the version string.AMBuilder
Pretty much the same file all extensions on the SM repo have, but instead with your extension source files.
product.version
I think this warrants a version bump 😄
The CI :
As requested by @asherkin, also added workflow that will build the extension for all the pull requests made on master. And if a push is made on the currently non existing
action
branch, the workflow uploads new releases ofconnect
to https://builds.limetech.io/?p=connectThis was field tested on the private commits
https://github.com/Kenzzer/connect/actions/runs/4267733732/jobs/7429642982 & https://github.com/Kenzzer/connect/actions/runs/4267733732/jobs/7429643048
This requires the repo to setup two secret variables,
USERNAME
&PASSWORD
which will be used for release uploads.