-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
[gettext] msgfmt (and other gettext bin tools) missing on macOS & Windows #13518
Comments
I just realized that the "CASCADE" status effectively means "SKIPPED because of missing dependency". IMHO a build should fail in such case, since the ports I modified were not built at all. Anyhow, the issue still stands – these tools are missing on macOS. |
agree with CASCADE status. It already misled me few times... |
Please note we have the same issue on Windows; I updated the title accordingly. |
We may need to fix windows build instead of add it to |
I tried building it on macOS and it failed, too. My ports depend on it so I added it for the time being, but I agree it would be best to include those execs in the gettext itself. |
@strega-nil can you please re-open this? Unfortunately this issue wasn't fixed by #11776. Please see #13532 for ongoing discussion. |
|
I think what kf5i18n needs is a host-dependency on |
@dg0yt No, it doesn't work, I already checked that. |
@JackBoosY Perhaps |
@dg0yt Because not only our port, but also the custom project will call the configuration file of kf5i18n, so I think we should do some magic on its cmake configuration file. |
IIUC the gettext port's cmake wrapper is installed for |
This has been stale for a while and still a blocker for a whole bunch of the libraries I have lined up for inclusion into vcpkg. I understand that the latest is that that |
WRT to the headline, the tools are no longer missing. (They even build on Linux if you want.) But...
Basically, this is a recurring issue, not just affecting gettext[tools]. I suppose at least |
OK, so as you noticed yourself, this is actually same recurring issue I commented on before and you already linked to. Good job at summarizing everything in #17607. Let's hope that this is picked up by the core team eventually. |
#18159 was merged, so maybe this resolved? |
Ping @wrobelda for response. |
Okay, please reopen this issue if it's not resolved. |
If I leave the default installation and integration active gettext tools are built and placed in Edit: Adding |
without taking away any importance to #17607, maybe we can write specifically for this case a wrapper that finds the executables in the positions that we already know and then launches the real find_package. In this way, find_program calls will already find cache variables set up and work, without any requirements on upstream cmake modules |
While we don't have a vcpkg wrapper (which would need to be in the target system), we do have a vcpkg config file (which is applied when using a host dependency on My PR #18159 which added the config file was initially submitted with a gettext wrapper installed in the target system. But this concept didn't convicnce the reviewers: installing a wrapper for the target triplet which relies on tools installed for the host triplet. |
Describe the bug
macOS nor Windows come with gettext by default. There is a gettext port in vcpkg, but it doesn't ship the \bin tools. The
vcpkg_find_acquire_program()
does not offer it, either. Because of that reason, ports that require msgfmt binary tools (e.g.kf5i18n
) fail to build on macOS and Windows.What's even more puzzling, though, is that the vcpkg OS X Azure Pipeline builds it just fine, despite that gettext is not one of the home-brew prerequisites installed by vagrant.EDIT: these pipeline builds were in fact false-positives and were never actually executed.Environment
To Reproduce
Steps to reproduce the behavior:
vcpkg install kf5i18
Expected behavior
vcpkg_find_acquire_program()
should include gettext toolsAlternatively, the way that OS X Azure Pipeline delivers a functioning set of gettext tools should be explicitly documented.as explained above, this was a false-positive.Failure logs
The text was updated successfully, but these errors were encountered: