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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cover Linux build by GitHub Actions #31
Cover Linux build by GitHub Actions #31
Changes from all commits
83613b5
786cd44
0ee6971
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's not just
all
because it doesn't cover the "no threads" version, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's why I have two targets
all build/libaxc-nt.a
up there 😄There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if i understand the makefile right, this way the tests only run against the installed dependency, not the
libsignal
compiled form the submodule. correct?what do you think about building + testing the static targets without the dependency installed in one step, and then installing it to build and test the shared lib in the next step? ("step" does not necessarily mean a github action step)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I confirm:
(Notice the
.o
suffix in that line. That's where the Makefile stores the ELF executable at the moment.)I agree that it would be nice to have the build system be flexible enough to do things like that. There are two reasons why I'd rather not change anything about that yet in this very pull request: The mission of the pull request mostly is detecting breakage in what we already have; re-placing the low-level Makefile with high-level CMake is something that I will investigate further, which would make prior non-critical build system changes a potential waste of time. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, i don't mean changing anything about the build system. afaict the test is either run against the static or dynamic build depending on whether the system package is installed:
axc/Makefile
Line 135 in 1d4454e
so my suggestion was:
libsignal-protocol-c
packagei agree that seems a bit silly, and just an easy workaround until there's a proper way to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gkdr I see, I did indeed misunderstand you then. Rather than doing all of that in one linear run, I'd split that in two halves an use the GitHub Action Matrix to with a single parameter for system-wide or self-built libsignal-protocol-c. It's not hard to do with regard to GitHub Actions:
Problem is: The self-build half of things is broken, and so we won't get a green CI before fixing the build system further this way. The symptom (full build log) is…
… and the cause is that
$(AX_PATH)
is missing at some places but also needs to be fully conditional, to not interfere with the build against the system-wide library (e.g. when someone does have the Git submodule initialized)… I would personally not want us to fix that in here, because it's not a hard dependency (plus potential upcoming build system re-write).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gkdr I guess someone had to fix the build anyway, so I have added the matrix and a dedicated commit to fix the build for the case of self-built libsignal-protocol-c now.