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

[Peter Wang]

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.

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

Peter