-
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
[gexiv2] new port #43600
base: master
Are you sure you want to change the base?
[gexiv2] new port #43600
Conversation
79c98d8
to
3be0379
Compare
e314d3d
to
5393705
Compare
ports/gexiv2/vcpkg.json
Outdated
"description": "A GObject-based Exiv2 wrapper.", | ||
"homepage": "https://gitlab.gnome.org/GNOME/gexiv2/", | ||
"license": "GPL-2.0-or-later", | ||
"supports": "!windows | mingw", |
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.
Really no windows support?
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, I tried and it not compile the lib file. I am not sure why.
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.
supports
must be consistent with the upstream. The upstream supports windows and mingw. If there are triplets that cannot be compiled, please write to ci.baseline.txt. refer to: #35928.
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 added on ci.baseline.txt
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 was able to grab the x64-windows logs before CI was canceled. It built no link lib for the DLL. Well, it simply doesn't seem to support DLLs on windows. Unfortunately I don't know the build result for static linkage.
In addition, I think that ci.baseline.txt
is wrong for ports which don't support a target at all. We had this with octave
: Wasting several hours CI time per week while absolute not supporting 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.
@MonicaLiu0311 upstream state that they support dll on windows, but they lack dllexport/dllimport markup, or .def files.
This is consider a bug from upstream:
https://gitlab.gnome.org/GNOME/gexiv2/-/issues/85#note_2345982
With other words, if we do not support it, it's most likely a bug (wherever, might be even in meson), not intent
Please review it again. Thank you.
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.
As a GIMP developer on Windows I can confirm that gexiv2 supports DLL's on Windows at least when built with gcc or clang supplied by the MSYS2 project.
Sure, but in absence of dllexport/dllimport markup, or .def files, there are no usable link libraries for DLLs with MSVC.
Right. That weirdness. Blast from the past.
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.
IIUC this is the confirmation that the package doesn't support DLLs support with MSVC.
If yes, this PR should be adjusted to build static libs for VCPKG_TARGET_IS_WINDOWS AND NOT VCPKG_TARGET_IS_MINGW
. Unless there are more pitfalls for the MSVC toolchain.
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.
There is a merge request where I try to add support, but Windows honestly is putting up quite some fight getting a compile environment up and running. Also, FOSS isn't a one-way-road, you know. Patches to make things work for your platform are welcome.
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.
Also, FOSS isn't a one-way-road, you know. Patches to make things work for your platform are welcome.
Also, your are talking to voluntary contributors which do upstream patches as appropriate. Some of us only using MSVC in vcpkg CI.
@LilyWangL can you change assing to available reviewer? |
a38f50f
to
814dfdc
Compare
@MonicaLiu0311 I answer you review comments. |
Hi, upstream here. Can you tell me how I test this myself on a windows 11 machine? |
Hi, I am not the maintainer of vcpkg, and my answer is not official.
I also send you logs: |
@MonicaLiu0311 Please comment and tell me your review / changes that need to be made for this PR. |
Since upstream is already adding the |
Are you expect me to add it here as patch? |
It would be awesome if you could test it on my behalf because I cannot get it running on my machine. |
I tested, and it give me an error. I will also share the log:
|
I am testing version 0.14.3. |
I remove this symbol from def: |
814dfdc
to
a3e2ab6
Compare
@MonicaLiu0311 I added upstream PR as a patch. Please review it again. Don't wait few days. |
a3e2ab6
to
4f153c9
Compare
Ah sorry, that was against master and that symbol is indeed newer than 0.14.3 |
find_package
calls are REQUIRED, are satisfied byvcpkg.json
's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.vcpkg.json
matches what upstream says.vcpkg.json
matches what upstream says../vcpkg x-add-version --all
and committing the result.