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

[Julien Fischer]

Hi Zoltan,

On Thu, 9 Nov 2023, Zoltan Somogyi wrote:

> On 2023-11-07 16:32 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:

>> I propose we add the predicates io.file.copy_file and io.file.copy_directory to
>> the standard library.  The actual semantics of these operations (e.g. how they
>> deal with existing files, symbolic links etc) will need to be decided, but I'm
>> intending to replicate what "cp" and "cp" -R do respectively.  (See the second
>> half of this proposal below for why.)
>
> 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.

...

>> 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.)

...

>> I propose to add a new flag to the Mercury compiler, --install-method.
>> This option will accept two values: external and internal.
>
> I don't think those names are descriptive enough, but don't have
> an alternate name to propose.
>
>> With a value of "external", the compiler will use the values of
>> --install-command and --install-command-dir to copy files and directories
>> (just as it does now).
>
> Obviously, that's fine.
>
>> With a value of "internal", the compiler will use the copy_file and
>> copy_directory predicates added to the standard library in the first part of
>> this proposal to copy files and directories (or, if there is not agreement to
>> add those predicates, from a new module in the compiler itself.)
>
> The compiler will use ... for what purpose? For copying X.int.tmp files
> to X.int files, I don't see a reason why we need to let users configure
> what means the compiler should use; the autoconfigured method
> should always be the best method available.

The new options are not for users, they are configuration options that
will be set in the Mercury.config file by the configuration script.
(As a developers, we may need to be able to change them at runtime,
but users shouldn't need to be aware of them.)

> For installs: that task has traditionally been done *outside* the
> compiler, so compiler options can't influence how that is done. Unless
> you are proposing that the compiler should take over the job of
> installation?

For installs using mmake, that task is done outside the compiler. For
installs using mmc --make, it is done *inside* the compiler.
For Mercury installations on Windows, in the absence of MSYS2 or
Cygwin, mmake is not an issue because GNU make won't be present
anyway.

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.)

Julien.