[m-dev.] include in Mercury.options

[Julien Fischer]

The following is an issue with how include directives work in
Mercury.options files.  It came up as part of change the G12 build system.
For those unfamiliar with it, G12 (currently) consists of around 16
components, primarily implemented in Mercury, most of which are built as
libraries.

We use mmc --make to build each component and the overall process is
controlled by make.  At the top-level of the source tree we have a
Mercury.options file that contains system wide settings.  This is included
by the various Makefiles and Mercury.options files in the various individual
component subdirectories.

To illustrate the issue consider the following directory structure and
Mercury.options files.

 	dir1/foo.options

 		include bar.options

 	dir1/bar.options

 		BAZ_FLAGS=-lbaz

 	dir1/dir2/Mercury.options

 		include ../foo.options
 		MCFLAGS=$(BAZ_FLAGS)

Currently this doesn't work because the compiler doesn't treat includes in
Mercury.options files as being relative to the directory in which the options
file currently being processed is in but rather as being relative to the
directory in which mmc was invoked.  (Incidentally, this is also the
behaviour that GNU make has with similarly structured makefiles.)

I would like to change the way the compiler treats include directives
so that it would include Mercury.options files relative the the .options
file currently being processed.  This seems to be a more useful behaviour.
Can anyone think of any problems with this proposal?

The problem I am trying to address with this change is that we need to split
the G12's global Mercury.options file in two: one part, called
Mercury.options.common, being required to just to build G12 and the other
part, G12.options, being required to both build and use G12.  My intention
is that the former should just include the latter and that all the other
Mercury.options or Makefiles in the source tree should just include
Mercury.options.common (as they do now).

There are, of course, other ways to deal with this but they all seem 
somewhat less elegant.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------