Just checking to see if there is still interest in this feature. On Thu, 18 May 2023 at 17:49, Costas Argyris <costas.argy...@gmail.com> wrote:
> Please find attached the latest patch with everything done so far, > including the inconsistency I mentioned in my previous email. > > This now has all 3 build approaches, namely: > > 1) configure > 2) Basic.mk > 3) build_w32.bat > > treating the resource compiler optionally, and building and > embedding the UTF-8 resource if it is found. This applies > for all supported compilers. > > I think this has everything discussed and agreed so far. > > Please let me know what you think. > > On Thu, 18 May 2023 at 12:38, Costas Argyris <costas.argy...@gmail.com> > wrote: > >> I think this should be added to README.git. Without these >> explanations, the purpose of Basic.mk and its auxiliary files, and of >> their intended usage, is completely unclear. >> >> I believe this was going to Paul. From my side, these explanations >> were really helpful. >> >> On to the Basic.mk patch, please see the latest one attached in this >> email. >> >> After regenerating Basic.mk from .\bootstrap.bat, I tried running it with >> both msvc and gcc values for TOOLCHAIN and they both worked fine. >> >> I also tried the 'no resource compiler' case by temporarily renaming >> 'rc.exe' (msvc) and 'windres.exe' (gcc) to something else so they are >> not found on the Windows path, and the build just went through with >> no errors and produced non-utf8 GNU Make binaries. >> >> As you will see, in mk/Windows32.mk I used: >> >> ifneq (, $(shell where $(RC) 2>nul)) >> >> to tell if a program is on the Windows path. It seems to be working >> fine >> in both cases of 'found' and 'not-found', but I am no GNU Make expert so >> please let me know if this is correct. >> >> A little inconsistency is that in build_w32.bat I didn't implement a check >> for 'rc.exe' because I assumed it's always going to be in the Windows >> path if the compiler 'cl.exe' is, but in mk/Windows32.mk I did implement >> the check even for 'rc.exe' - I can add the check in build_w32.bat to be >> consistent in a next update, it should be easy. >> >> Also just checking - the configury approach, when building for Windows >> host, can't be used with msvc or tcc, right? It needs to find gcc >> targeting Windows, and therefore checking for windres (already >> implemented) should be sufficient, right? >> >> On Thu, 18 May 2023 at 06:31, Eli Zaretskii <e...@gnu.org> wrote: >> >>> > From: Paul Smith <psm...@gnu.org> >>> > Cc: bug-make@gnu.org >>> > Date: Wed, 17 May 2023 18:04:55 -0400 >>> > >>> > To remind: the purpose of these is to provide a makefile-based way to >>> > _develop_ GNU Make itself, on platforms where we can't run ./configure >>> > to get an automake-generated makefile. >>> > >>> > If you need to build GNU Make from scratch there's not much benefit >>> > from using Basic.mk, because it will just rebuild everything every time >>> > just like the build_w32.bat etc. files. You don't save anything. >>> > >>> > But if you're doing ongoing development (edit/build/test cycle) and you >>> > don't want to have to recompile all files every time you change >>> > something, and you can't run ./configure, then you can use an already- >>> > built GNU Make and these makefiles to shorten your development cycle. >>> >>> I think this should be added to README.git. Without these >>> explanations, the purpose of Basic.mk and its auxiliary files, and of >>> their intended usage, is completely unclear. >>> >>
