Hi and sorry to bother you again. I haven't received any response so I was wondering if there is still interest in doing this.
On Tue, 28 Mar 2023, 17:43 Costas Argyris, <costas.argy...@gmail.com> wrote: > 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. >> >
