[m-dev.] proposed additions: file copying in stdlib and compiler

[Zoltan Somogyi]

On 2023-11-10 23:05 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>> I think we would want to agree on the semantics first. And for that, we would
>> need to know (a) what the possible set of implementation approaches are
>> for each backend/platform combo,  (b) what their semantics are, and (c) if
>> there is more than one feasible approach for a backend/platform combo,
>> their relative speed.
>>
>> I am familiar with the Unix/C options, but not the others.
> 
> I will post a description of the options separately.

Thanks.

>>> If the target platform provides a more efficient mechanism (e.g
>>> CopyFile() and friends from the Windows API), we would use that in preference.
>>
>> Am I correct in presuming that you would get this info from autoconfigured options?
> 
> We could, but I was intending to simply have a predicate that tests
> whether we are on Windows etc, and dispatches to the appropriate
> implemntation. (Similar to how parts of the standard library currently
> use have_win32/0, have_dotnet/0 etc.)

That's fine.

> Since we don't support symlinks on Windows, we also copy files
> with mmc --make instead of symlinking them. (We should revisit
> this since Windows 11 probably has a workable version of symlinks
> now.)

Since there are still many installs of Win10 out there, we would want
to support that as well, though not Win7; if it has been end-of-lifed
by MS, why would we want to support it?

Zoltan.