Re: Cygwin targetting mingw 32-bit

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

Below, I'm going to round out an email exchange from a year ago based on 
something I've just found.

On 27/09/2022 06:28, Vibhu Mohindra wrote:
> On 27/09/2022 01:59, Bruno Haible wrote:
>> Vibhu Mohindra wrote:
>>> System: Windows 10 64-bit, 6 GB RAM
>>> Processor: Intel Xeon X5647, x64-based processor
>>> Cygwin (64-bit) targetting mingw 32-bit
>>> clisp revision: f1aa42219433f019c05e707220538b3634bc233c
>>> I've used the instructions in INSTALL.windows.
>>>
>>> ----
>>> 1. LN_S
>>>
>>> The Makefile has a variable LN_S that is chosen to be some platform
>>> dependent value.
>>
>> src/makemake.in says that valid values for this variable include
>> 'ln -s', 'ln', and 'cp -p'.
>>
>>> The reason is that build-aux is a directory, and hard linking
>>> directories is not supported.
>>
>> I don't think it's good for the Makefile to copy an entire build-aux
>> directory. We should look into how to avoid that. Where is this
>> happening?
> 
> Oh right. If LN_S is never meant to be applied to directories, then that's 
> OK, and it's simply a matter of identifying where all it's used for 
> directories.
> 
> The top level Makefile in the build directory (from one of my 
> configurations) has this for the build-aux target.
> 
> build-aux : ../src/build-aux
>      -$(RM) build-aux
>      -$(LN_S) ../src/build-aux build-aux
> 
> A quick check with grep doesn't reveal any other places where LN_S is used 
> for directories. Anyway, now that I know the intention, if I come across it 
> being used anywhere else for directories, I'll fix that specific instance 
> and write in, rather than trying to change the definition of LN_S itself.
> 
> If build-aux gets fixed in GitLab, I'll immediately pull that down.
> 
>>> Does "cp -a" seem a reasonable choice?
>>
>> Yes, if directories need to be copied as well, then 'ln' and 'cp -p'
>> won't work and 'cp -a' is better.

I'm sorry, my ln -s woes seem to have been because I had the clisp tree on 
a network drive mapped to Z:, which doesn't support hard links and whose 
soft links are impenetrable to ld. With the tree on a local drive (C:), I 
don't seem to need to change anything related to LN_S from its defaults in 
Git. Terribly sorry about the LN_S report. (Other notes I've written are 
all still valid.)

Vibhu