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

Julien Fischer jfischer at opturion.com
Tue Jul 23 16:49:31 AEST 2024


On Tue, 23 Jul 2024 at 16:41, Peter Wang <novalazy at gmail.com> wrote:
>
> On Tue, 23 Jul 2024 16:03:19 +1000 Julien Fischer <jfischer at opturion.com> wrote:
> > On Tue, 23 Jul 2024 at 15:35, Peter Wang <novalazy at gmail.com> wrote:
> > >
> > > On Tue, 23 Jul 2024 15:15:23 +1000 Julien Fischer <jfischer at opturion.com> wrote:
> > > > Hi Peter,
> > > >
> > > > On Tue, 23 Jul 2024 at 14:33, Peter Wang <novalazy at gmail.com> wrote:
> > > > >
> > > > > Put .mh files into Mercury/mhs subdirectory.
> > > > >
> > > > > Put .mh files into a Mercury/mhs subdirectory when --use-subdirs
> > > > > or --use-grade-subdirs is used.
> > > >
> > > > My guess is that samples/c_interface/standalone_c and possibly some
> > > > of the other examples in samples/c_interface are going to require updating
> > > > as well.
> > >
> > > You're right. How does this look to you? mhs_subdir is surely an
> > > implementation detail, but I don't know if it's worth trying
> > > to avoid using it in these examples.
> >
> > This specific example was set up to avoid having to install the
> > example Mercury library.
> > Maybe we could extend --output-c-include-dir-flags to include
> > -IMercury/mhs, or add
> > a separate option, --output-local-c-include-dir-flags?
>
> --output-c-include-dir-flags already responds to --use-subdirs
> or --use-grade-subdirs, but if the user ran mmake --use-subdirs,
> the Mmakefile would need to pass --use-subdirs to the mmc call.

--output-c-include-dir-flag was never intended to work with mmake.

> The other problem is when the Mmakefile expresses dependencies
> explicitly, as in:
>
>     main.o: $(mhs_subdir)mercury_lib.mh
>
> --output-c-include-dir-flags doesn't help with that.

I think that if users want to use mmake (which is *not* what we recommend),
then they need to sort the details of finding the .mh files out themselves.

> > I don't really like the idea of users having to be aware of the
> > structure of the Mercury
> > subdirectory.
>
> Then we have to drop this change.

Perhaps, I should have said minimise a user's required awareness of
the structure of the Mercury subdirectory.  I'm fine with this change in
principle.

Julien.


More information about the reviews mailing list