Being able to know whether UTF-8 is supported or not is a valid concern. How about adding this information to what "make --version" shows?
I think this is a great idea, despite the fact that I expect most build environments to actually have a resource compiler (either windres or the msvc one) and therefore build with UTF-8. It certainly doesn't hurt to have this information output by Make itself - I can only see this being useful, even if the answer is UTF-8 most of the time. One comment about having it as part of --version is that it probably won't be easy to parse the used encoding out of the --version output, say, if a script wants to query for the encoding and pass a UTF-8 Makefile conditional on Make actually supporting UTF-8. Whether we want to care for this scenario or not is a different question though. If we decide to do this, it should simply be a call to the Windows GetACP() function - it will return 65001 if Make has been built with the UTF-8 manifest, or the identifier of the legacy system encoding otherwise. Actually, it will return 65001 (the UTF-8 identifier) in a couple other scenarios, even if Make hadn't been built with the manifest: 1) The user embedded the manifest manually using mt.exe This is officially documented and can very well happen. 2) The user has switched Windows to use UTF-8 as the active code page globally, for the entire OS. This is possible to do with a checkbox that is marked as "beta" by MS. So having Make return the output of GetACP would be useful because it would capture all these scenarios, including it having been built with the manifest of course. This is an example from ninja doing the same thing: https://github.com/ninja-build/ninja/pull/1918 They did it by adding a new flag, so not part of --version. I like putting it in --version better because this does sound like the type of information one would expect to see there, the only problem being that it may not be easy to parse, unless we add it in a standard easy-to-parse format, like in a line of its own as: <--version output> ... Encoding: 65001 or Encoding: 1252 ... But it isn't "full UTF-8", as we have established during the discussions. MS-Windows is not yet ready for that, even in its latest versions. Yes, well, I guess what I really meant was "to the extent that Make itself can affect things". We can't do anything about Windows limitations anyway. I think there should be no problems at all if Make is linked against UCRT, and I hope that we won't hit many functions in MSVCRT that are not UTF-8-aware, but we couldn't do anything about these anyway. > That is, I am more inclined to make the configure version also error > out if windres was not found, than to make build_w32.bat optional. I'm of the opposite opinion. Sure, it shouldn't be hard to change build_w32.bat to make it optional. There is no precedent of such behavior in that batch file, as far as I can tell, so I'd have to come up with something like: if HAVE_WINDRES compile resource file else just skip resource file with no error, and don't try to link it end Then this is a non-issue: the error will not happen except in some situations we cannot imagine. That's what I think, but I could be wrong since I really can't imagine all the build environments people might be using, and, as I learned from this thread, there are quite a few ways to build so it's hard to anticipate for every possible scenario. Maybe it is best to just make compilation of the resource file optional, but, very importantly, with the addition of your suggestion about printing the encoding used in --version. That way, everyone will manage to build as they currently do with no surprises about this, and they will also be able to query Make any time for its encoding. I'd like to avoid annoying users with requests to install something they did well without previously. Some would consider this a regression. Makes sense, see above response. On Tue, 28 Mar 2023 at 12:22, Eli Zaretskii <e...@gnu.org> wrote: > > From: Costas Argyris <costas.argy...@gmail.com> > > Date: Mon, 27 Mar 2023 23:04:52 +0100 > > Cc: bug-make@gnu.org > > > > > Should we fail here? Or should we build without UTF-8 support since we > > > don't have a resource compiler? I think that's what the configure > > > version does, right? > > > > You are right, that was an inconsistency on my part, sorry about that. > > It's true that the configure version is optional on this, whereas > > build_w32.bat errors out. > > > > I think the answer depends on what is going to be the policy regarding > > Make on Windows and UTF-8. If we want to claim that Make on Windows > > has gone UTF-8, matching fully the Unix-based platforms, then it has to > > be an error if it can't be built as such. My personal opinion is that > this > > is the way forward, because it may be confusing if we end up in a > > situation where some users have a UTF-8 version of Make and some > > others don't. > > Being able to know whether UTF-8 is supported or not is a valid > concern. How about adding this information to what "make --version" > shows? > > > I think just go full UTF-8 like the other systems. > > But it isn't "full UTF-8", as we have established during the > discussions. MS-Windows is not yet ready for that, even in its latest > versions. > > > Of course, users on versions of Windows earlier than the target version > > that supports this feature still won't get UTF-8, but that would be > because > > of their version of Windows, not because of the way Make was built. > > Right. > > > That is, I am more inclined to make the configure version also error > > out if windres was not found, than to make build_w32.bat optional. > > I'm of the opposite opinion. > > > This is mostly based on the fact that windres is part of binutils which > is > > pretty much ubiquitous because gcc itself relies on its tools (most > > notably the assembler and linker). So if someone is building with > > gcc, they will almost certainly already have windres. For building > > with MSVC that's a non-issue because MSVC comes bundled with its > > own resource compiler, so it is always going to be there. > > Then this is a non-issue: the error will not happen except in some > situations we cannot imagine. > > > So I think it is reasonable to expect that there is always going to be a > > resource compiler available. Even if not, say, when building with tcc, > > it is always possible to error out with a message saying to install > binutils. > > I'd like to avoid annoying users with requests to install something > they did well without previously. Some would consider this a > regression. >
