-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
[shiftmedia-gnutls] new port (Windows fork of GnuTLS) #18029
Conversation
I would prefer when one port would use only one particular set of sources and patches, so that I can build for different target triplets without worrying about the state of the port's sources in the buildtrees folder. |
I'm sorry, I am not sure what you expect here. All of the portfiles which use ShiftMediaProject forks to provide Windows support behave like this. |
I know that a lot of ports do different patching for different triplet, but this is the first time I note different sources.
|
See e.g. gmp, nettle for comparison.
I am not sure I follow, again. Sources are downloaded into separate folders with unique names, usually consisting of a version/revision number and a hash sum. Since sources for Windows and *nix are different in those portfiles, they get downloaded into separate folders and patches are applied respectively. This behavior is no different from building a different (older) port version on demand. |
I see, and you refering to unpacking indeed. So I only need to worry about some patches which are not applied uniformly. Anyway, I find it confusing to have different sources. I admit I'm biased, with experience in building RPMS and DEBs. |
I don't think there's anything to worry at all. Those Windows-specific patches will only be applied on top of ShiftMediaProject source code, which, in turn, is only used for Windows build.
These are definitely exceptions. ShiftMediaProject has whole bunch of MSVC-compatible forks, which are very convenient to use. I even discussed a possibility of pushing those changes upstream, but as you can imagine, it's a voluntary work on all fronts: |
efa69b7
to
31e8d62
Compare
I have a question here, why do you use different repo in different platforms? Also I noticed there was a new version 3.16.6. Why do you not use the latest? |
Please ping me if this is ready for review. @wrobelda |
Hi @wrobelda Is work still being done for this PR? Seems there is no any progress for a long time. |
I am going to return to it as soon as all of my |
2df822d
to
88a4936
Compare
b408751
to
9f070f6
Compare
@NancyLi1013 this is now ready for a review |
80041b5
to
9f070f6
Compare
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.
This approval is contingent on:
- Another vcpkg maintainer signing off on the multiple-upstreams thing
- The 'supports' expression being fixed.
- The additional quotes in
file(RENAME
added.
All other review comments are nitpicks.
Thanks for your contribution!
RELEASE_CONFIGURATION ${CONFIGURATION_RELEASE} | ||
DEBUG_CONFIGURATION ${CONFIGURATION_DEBUG} | ||
SKIP_CLEAN | ||
OPTIONS /p:YasmPath="${YASM}" /p:OutDir=..\\msvc |
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'm very sad to see another thing depending on yasm given how full of flaky memory corruption bugs it has turned out to be :(. No change requested.
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 agree. Eventually I hope we can get a vanilla version of this to compile with clang-cl, similarly to the ongoing #26424.
Co-authored-by: Billy O'Neal <bion@microsoft.com>
7fffc6f
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.
This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!
PRs must add only one version and must not modify any published versions
When making any changes to a library, the version or port-version in vcpkg.json
or CONTROL
must be modified.
error: checked-in files for shiftmedia-libgnutls have changed but the version was not updated
version: 3.7.6
old SHA: 1de8a6097b77f987022f00eeeebacb163a4820ee
new SHA: 35797029a653421f3d04186ef00bc126b4d3ada1
Did you remember to update the version or port version?
Use --overwrite-version to bypass this check
***No files were updated***
Co-authored-by: Billy O'Neal <bion@microsoft.com>
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.
This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!
PRs must add only one version and must not modify any published versions
When making any changes to a library, the version or port-version in vcpkg.json
or CONTROL
must be modified.
error: checked-in files for shiftmedia-libgnutls have changed but the version was not updated
version: 3.7.6
old SHA: 1de8a6097b77f987022f00eeeebacb163a4820ee
new SHA: 2151242268c29f3642323e0a97034a4a9c52fa09
Did you remember to update the version or port version?
Use --overwrite-version to bypass this check
***No files were updated***
df31fc4
to
603e364
Compare
603e364
to
1d1ccd3
Compare
9eb18bb
to
d0b9f5d
Compare
To be fair, this is only required because |
Thanks! |
Describe the pull request
Uses SMP fork of GnuTLS to add a new fork, based on the suggestion from @BillyONeal (#18029 (comment))
What does your PR fix?
Adds support for Windows build for gnutls. Depends on [libtasn1] Add Windows support, update to 4.17 #16953
Which triplets are supported/not supported? Have you updated the CI baseline?
All Windows triplets
Does your PR follow the maintainer guide?
Yes
If you have added/updated a port: Have you run
./vcpkg x-add-version --all
and committed the result?Yes