[m-rev.] for review: Put .mh files into Mercury/mhs subdirectory.

Peter Wang novalazy at gmail.com
Tue Jul 23 16:29:26 AEST 2024


On Tue, 23 Jul 2024 07:34:19 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Tue, 23 Jul 2024 14:32:47 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > compiler/file_names.m:
> >     Replace ext_cur_mh with a new option in a new category,
> >     ext_cur_ngs_max_cur_mh.
> 
> This wording implies that ext_cur_ngs_cur_mh is the name of the
> new category, which it is not. I would say "Replace ext_cur_mh
> with ext_cur_ngs_max_cur_mh, in the new category ext_cur_ngs_max_cur".

Fixed.

> > compiler/write_deps_file.m:
> >     Add $(mhs_subdir) prefix before %.mh patterns.
> > 
> >     Create a Mercury/mhs -> .. symlink when installing.
> 
> Do NOT do this, ever. It makes it impossible to back up
> the resulting directory, because the cp command will copy
> Mercury/mhs to the target location in an infinite loop.
> In this case, it is too late, because this problem already exists
> for other suffixes, but in other projects ....
> 

I'm not sure what action to take. The Mercury/<ext>s -> .. symlinks
are ugly, but expected by mmc --make and mmake --use-subdirs.

Note that mmc --make happens to work without the Mercury/mhs symlink
(from a quick test), but it's needed for mmake --use-subdirs.

(It's not impossible to back up the directory, but of course you can't
dereference the symlinks when doing so.)

> However, this diff also raises a question. When I completely redesigned
> file_names.m, I left the handling of each extension as it was before,
> even when it did not make sense. There are a bunch of XXXs in that file
> noting extensions whose old handling (which we have so far preserved)
> seems wrong. The intention was always to fix these together, because
> for users, a single big change is preferable to a drip-feed of smaller changes.
> The question is: should we start this process now?

This change will mainly affect users who produce Mercury libraries to be
consumed via a C interface, which I guess would not be too many.
Looking through in file_names.m, the only XXX that looks user facing to
me would be moving .prof files into a grade-specific subdir.
I don't think there is any hurry.

Peter


More information about the reviews mailing list