[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