Re: Cygwin targetting mingw 32-bit

[Vibhu M. <vi...@ho...>]

On 27/09/2022 00:18, Vibhu Mohindra wrote:
> 1. LN_S

I've got past all "ln -s" related problems locally and will describe my 
understanding of things.

System: Windows 10 64-bit
Cygwin (32-bit) targetting mingw 32-bit


----
I changed my toplevel Makefile's build-aux target to use "cp -a" instead 
of $(LN_S), because LN_S is automatically set to "ln" in this Makefile 
and "ln" doesn't work for directories.


----
There are two more kinds of occurrences of ln -s that need fixing.

1) In Makefiles in subdirectories like build/{gllib,i18n,...}/Makefile
2) clisp-link (and perhaps other scripts) which cause full/* to be symlinks

1)

Here's how LN_S gets its value in the Makefiles. The configure script 
detects in Cygwin that "ln -s" works and sets LN_S to that. It can't 
know that the Windows native clisp that will be produced via mingw won't 
actually be able to handle symlinks. (Presumably no native Windows 
programs can handle symlinks.) However src/makemake.in (near line 1052) 
does know that fact so it replaces LN_S to be "ln". In short, configure 
thinks "ln -s" but makemake.in knows to override that to "ln".

But the subsidiary Makefiles take their LN_S values directly from 
configure not from makemake.in. Thus they get the configure-detected bad 
value "ln -s". I manually changed the LN_S values in these subsidiary 
Makefiles to be "ln". I don't know how the build architecture should 
change so that they don't require manual editing but are instead born 
with the correct value just as the toplevel Makefile is. (Maybe passing 
LN_S=ln as a command-line argument to configure will do the trick. If 
so, then the solution requiring the least work will be to update 
INSTALL.windows to state that. But this hack will still leave the 
build's design flawed -- where there's the appearance that makemake gets 
to have a say when in reality it doesn't consistently.)

2)

I've got "make full" to complete but I couldn't immediately run the 
result. Again, that's because full/* were mostly symlinks. Changing 
lisp.exe and lispinit.mem to instead be hard links of the underlying 
files made "clisp -K full" start up successfully. I think the symlinks 
were created due to clisp-link having "ln -s" in two places. These two 
places (or whichever other scripts caused full/* to be symlinks) should 
be changed.


-- 
Vibhu