bfd/docs building on Cygwin

[Jan Beulich]

On 08.02.2021 17:57, Nick Clifton wrote:
>> The problem is with "cp -p" trying to preserve ownership:
>> With the sources living on a Samba share I observe this
>> failing with "Permission denied". Looking at the purpose of
>> the copying I wonder why copies are being made in the first
>> place. 
> 
> I think that the copy is there so that move-if-change invocation
> on the next line of the rule will work.  I think that script
> requires both files to be present...

Right - a property that's equally fulfilled with a real copy
or a symlink.

>> Would the change below 
> 
>> -	test -e aoutx.texi || test ! -f $(srcdir)/aoutx.texi || cp -p $(srcdir)/aoutx.texi .
>> +	test -e aoutx.texi || test ! -f $(srcdir)/aoutx.texi || $(LN_S) $(srcdir)/aoutx.texi .
> 
> I think that this will fail if the source and build directories
> are on different file systems.

Why? I'm talking about a symbolic link, not a hard link here.
Plus LN_S falls back to "cp -pR" when symlinks aren't available.
(Also in the case I've described source and build tree are
indeed on different file systems - the source tree is remote,
while the build tree is on the local hard drive.)

>> (Seeing the not insignificant amou of redundancy here:
>> Isn't the binutils build system implying GNU make anyway,
>> for vpath support? If so, is there a reason all these
>> individual rules couldn't be consolidated into a few
>> pattern rules?)
> 
> None that I can think of.  I would certainly be happy to
> review such a patch.  It would be especially good if the
> patch replaced "cp -p" with something like "$(COPY)" which
> could then be set to "cp -p" for most hosts but something
> else for situations like yours...

Yet I understand that would involve configure adjustments,
which - to be honest - I'd rather keep my fingers off of. But
I can see about making a consolidation patch as outlined; may
take a little while, though.

Jan