> > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote: > > > I agree with the list. As for Basic.mk, we can forget about it > > > from my POV. Paul should make the call, but from my POV that > > > file was unmaintained and therefore unsupported. > > > > Why do we think it's unmaintained / unsupported? > > Because I never use it when building the MinGW port of Make.
I see. I never use MinGW, as I don't have it installed. The Basic.mk model is only useful for systems where you can't run configure and generate a Makefile that way. For systems where configure can't be invoked it provides a makefile framework (versus a bat file) that can be used if you already have a previous GNU Make available (or once you build one once with the bat file). As I have said before, I wasn't successful in getting the Basic.mk approach to work on Windows, as I was getting various errors all over the place. They started with CC being undefined, but even after I defined it to 'gcc' this just took me to various link errors, at which point I thought that this approach is not really maintained. That was in contrast with the other two approaches on Windows host, namely configure and .bat file, both of which worked as expected. So my question now is: Is the Basic.mk approach a mandatory prerequisite for the UTF-8 feature? Do the UTF-8 build changes for Windows host have to be extended over there as well, or can we do without it, and say that a UTF-8 build for Windows works only with the configure and .bat file approaches (assuming there is a resource compiler available, of course). Note that, as agreed, in the latest patch I made the resource compiler (and hence building with UTF-8 manifest) optional, and added this information to --version output. This means that even if Basic.mk doesn't support the UTF-8 feature, the user would still know it by means of --version. That would be the same as if one of the other approaches was used and there was no resource compiler available (gcc or tcc without windres on the path). So, can this feature proceed without changes in Basic.mk? On Sat, 6 May 2023 at 19:54, Paul Smith <psm...@gnu.org> wrote: > On Sun, 2023-04-30 at 17:27 +0300, Eli Zaretskii wrote: > > > From: Paul Smith <psm...@gnu.org> > > > From: Paul Smith <psm...@gnu.org>Date: Sun, 30 Apr 2023 09:55:55 - > > > 0400 > > > > > > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote: > > > > I agree with the list. As for Basic.mk, we can forget about it > > > > from my POV. Paul should make the call, but from my POV that > > > > file was unmaintained and therefore unsupported. > > > > > > Why do we think it's unmaintained / unsupported? > > > > Because I never use it when building the MinGW port of Make. > > I see. I never use MinGW, as I don't have it installed. The Basic.mk > model is only useful for systems where you can't run configure and > generate a Makefile that way. For systems where configure can't be > invoked it provides a makefile framework (versus a bat file) that can > be used if you already have a previous GNU Make available (or once you > build one once with the bat file). >