meson: Support building on Windows without sh about util-linux HOT 10 OPEN

The testsuite also needs bash.

Using util-linux on Windows without having run the testsuite is not something that seems advisable.

from util-linux.

We need to call the script from autotools, and dependence on Python is overkill in this case.

The script uses .tarball-version as a fallback if there is no git; it might be possible to use the file directly in Meson on platforms where the script cannot be executed.

Or you can write a meson function to replace the script and use it only if the original script cannot be executed.

from util-linux.

Thanks! That sounds good. For reference, I found a related issue mesonbuild/meson#688.

from util-linux.

Did you test that it actually works after replacing the tools/git-version-gen?

There should at least also be issues with tools/all_syscalls and tools/all_errnos as they are using bash.

If bash is fine, maybe tools/git-version-gen can also use it.

from util-linux.

Did you test that it actually works after replacing the tools/git-version-gen?

Nope, I haven't gotten that far yet. This is just the first hurdle, but I'll try to test out how far I get with the project version hard-coded.

There should at least also be issues with tools/all_syscalls and tools/all_errnos as they are using bash.

These should be fine as is since those two tools are just used to generate two header files, which are only used by a couple of executables, lsfd and enosys. There is already an option to disable lsfd, we might just need an option to disable enosys. This assumes that lsfd and enosys shouldn't be built on Windows. If they should still be built on Windows, that will require more work.

If bash is fine, maybe tools/git-version-gen can also use it.

It would be ideal to avoid any extra dependencies on Windows, such as Bash.

from util-linux.

So, I've delved into the details a bit further on this. There's a couple different approaches that could be taken. Unfortunately, the project command isn't very flexible, and I'm not sure how you would manage to run multiple commands via run_command in the argument for version, which seems to be the only way to use commands for the version. It seems like using some sort of external script is necessary to set the project version as is currently done. Meson supports using a file as an argument for version, but this file would then need to be present at all times.

1. Probably the most straightforward approach is to add a Python script equivalent to tools/git-version-gen that is only used by Meson. This doesn't introduce a new dependency since Meson already requires Python and Autotools can continue to use tools/git-version-gen. The downside is that this duplicates code a bit.
2. An alternative approach is to hard-code the project version for the project command or omit it altogether and use a separate variable to hold the project version. The tools/git-version-gen functionality could then be implemented directly in Meson, use a separate Python script to set this variable, or perhaps use Meson's vcs_tag function somehow. The drawback here is that the version for the project command is still important for when util-linux is used as a subproject. Thus, the version would still need to be hard-coded and updated on every release.

from util-linux.

The question is, why do you want to use util-linux if you do not have other essential utilities like bash or coreutils? It sounds like an academic exercise :-)

Note that I do not have a problem with supporting non-Linux platforms, but the support must not negatively impact usability on Linux, as it is our primary audience.

from util-linux.

I'm mostly just ignorant of the current support for Windows, since I know that it is possible to build util-linux on Windows. I wasn't aware of the platform support and requirements, but now it's more apparent that compiling for Windows involves using particular toolchains like MSYS2. Trying to use Meson, I wasn't sure if util-linux needed this environment or if it was just required previously for Autotools.

There was just a Conan package submitted to package gnu-getopt from util-linux and it supports Windows, which made me curious. I'd be fine closing this as wont-fix, now that I understand the situation better. I'd rather not rewrite the entire test suite. 😁 Maybe the requirements for Windows are worth mentioning somewhere or already are mentioned somewhere?

from util-linux.

Does it work on Windows when bash is available during build?

from util-linux.

Does it work on Windows when bash is available during build?

Apparently it should using MSYS and a non-MVSC compiler, but I haven't tested myself.

from util-linux.