-
Notifications
You must be signed in to change notification settings - Fork 312
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
CI:add MinGW builds #991
CI:add MinGW builds #991
Conversation
86015a3
to
937816c
Compare
the zip.txt describes one zip file, which will include all of mingw, VS 2019, VS2022 in separate directories.
When I look at the actual artifacts (and previous releases) - there are three separate zip files, that don't include the alternatives, and are not structured like the Which is 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.
LGTM with the already proposed changes...
937816c
to
d2155b8
Compare
@rgetz, for these changes, I was following the latest version when we had MinGW builds (v0.21) |
What is "argument 4"? |
d2155b8
to
138a8ab
Compare
138a8ab
to
f7e3268
Compare
I'm not sure I understand - when I look at the Windows zip file for 0.21 it includes a directory structure that looks like:
I get, and agree with dropping 32-bit - no problem with that. when I look at the artifacts from this PR I see three different and unique zip files (one for minGW, one for MS64 2019, one for MS64 MS2022). There is no single zipfile which contains all. |
So if you are looking to CI/azure/prepare_assets.sh lines 34-47, there is defined a zip file that will have the structure described on README.txt, this is the one that will be for the GitHub release. |
@ccraluca, the snprintf() format fix is actually invalid. On Linux x86_64, Knowing that on Windows "long" is always 32-bit, then we can deduce that this field will always be 32-bit, and therefore the best way to address the warning is to use |
Thanks - that's what I was missing. Is there a way in the PR to see the resulting file, so we can give some feedback on it, or we need to do a pre-release? |
Yes, a pre-release or if it's ok to push a test tag, that way we would check before merging to master. |
Either way - what ever is easier for you. However - you need to address @pcercuei 's flag first.
|
f757ae2
to
8c814b1
Compare
Modification added. |
A test-tag was pushed and artifacts can be checked. Once everything is ok, I will need to modify conditions on YAML file back for v-tags. |
68bb90b
to
351da8d
Compare
Fixed the structure of Windows.zip on GitHub release |
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.
Looks great now - thanks for the effort.
213fc80
to
9cbd142
Compare
9cbd142
to
5cac1f1
Compare
5cac1f1
to
2a7761f
Compare
CI/azure/macos_tar_fixup.sh
Outdated
rm "../${tarname}" | ||
tar -czf "../${tarname}" . | ||
cd .. | ||
rm -rf temp |
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.
Missing end-of-line character
2a7761f
to
a7399f2
Compare
MinGW build fail on unsigned int argument because long unsigned int is expected. Signed-off-by: Raluca Groza <raluca.groza@analog.com>
Add MinGW build and modify related files to add artifacts to SwDownloads and GitHub release. Signed-off-by: Raluca Groza <raluca.groza@analog.com>
Signed-off-by: Travis F. Collins <travis.collins@analog.com>
a7399f2
to
af19492
Compare
Add MinGW build and modify related files to add MinGW binaries to SWDownloads and release.