[m-dev.] sourcing foreign code

[Peter Wang]

On Wed, 26 Feb 2014 13:25:34 +1100 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi Peter,
> 
> On Wed, 26 Feb 2014, Peter Wang wrote:
> 
> > Hi,
> >
> > Writing foreign code inside foreign_code is a bit painful (no syntax
> > highlighting, need to escape quotes and backslashes).
> > When the amount of foreign code is significant, I would like to keep
> > it in a separate file and reference it from the Mercury file.  This is
> > possible using the C preprocessor but not ideal:
> >
> >    * mmc --make does not know about the dependency so you must manually
> >      touch the relevant .m file.  Imagine if you switch branches in a
> >      workspace and the .c file is touched but not the .m file.
> >
> >    * you must tell the C compiler where to find the .c file,
> >      e.g. with --c-include-dir in Mercury.options
> >
> >    * only works for C backends
> >
> > A solution might be to extend pragma foreign_decl/foreign_code like so:
> >
> >    :- pragma foreign_code("C", source_file("<path>")).
> >
> > where <path> is _relative to the .m file_, or else an absolute path.
> 
> <path> is the (possibly directory qualified) name of the .c file to
> include?

Yes.

> > I have not looked into how much work it would be to modify mmc --make,
> > but what do you think?
> 
> In principle it seems like a worthwhile addition.  I wonder if
> include_file might not be a better name than source_file.  Also,
> if the .c file has some supporting header files associated with
> it how would you handle them in terms of dependencies?

This feature is limited to allowing you to lift out what you would have
written in a pragma foreign_decl/foreign_code into another file.

I don't think we really want to start parsing the included file for
dependencies, or adding new ways to declare dependencies in the .m or
mmc options.

Peter