Currently, the compiler's top-level module is the module 'top_level'. This
means that the executable (or Java archive, or assembly) we generate is named
after that. However, the rest of the system requires that the compiler
executable be named 'mercury_compile', so we currently rename it after it is
generated. (At least, we do in C grades, in non-C grades the compiler
"executable" currently has the "wrong" name.) Making this scheme work across
multiple backends and platforms leads to quite a bit of complication in the
build system. This change simplifies matters by repurposing the
'mercury_compile' module to be the new top-level module; this means that the
executable is generated with the correct name to begin with.
compiler/mercury_compile.m:
Shift the existing contents of this module to new module,
mercury_compile_main.
Shift this module out of the top_level package and export main/2 from it.
compiler/mercury_compile_main.m:
New module that contains the old contents of mercury_compile.m.
compiler/top_level.m:
Conform to the above changes.
Delete the definition of main/2 from this module.
compiler/make.m:
compiler/make.module_target.m:
Conform to the above changes.
compiler/Mmakefile:
Conform to the change in the name of the top-level module.
Delete the rule for renaming the compiler executable.
Mmakefile:
Update the dep_compiler target.
compiler/notes/compiler_design.html:
Update this document.
scripts/mercury_compile.sh-csharp:
scripts/mercury_compile.sh-java:
Update these scripts.
compiler/.gitignore:
Conform to the above changes and generally update
this file.
configure.ac:
tools/binary_step:
tools/bootcheck:
Update the top-level module.
scripts/mercury_compile.sh-java:
Bump up the stack size to 32M since the default is too low to build the
Mercury compiler.
configure.ac:
Workaround a problem that causes the configure check for an installed
Mercury compiler to fail if the installed Mercury compiler is built in
a non-C grade, specifically the non-C backends do not provide an equivalent
of MR_RTTI_VERSION.
Make it possible to run the installed Java version of the compiler by
installing versions of the wrapper scripts for 'mercury_compile' and
'mfilterjavac' that have the CLASSPATH set to point to the installed versions
of the standard library Java archives.
The wrapper script generated in the compiler directory is not suitable for this
because as generated it sets the CLASSPATH relative to the compiler directory,
not the installation directory. Modifying that file is not a good idea since
that will mean that then the compiler cannot be executed in situ. Instead we
provide a handwritten version of the wrapper script in the scripts directory
that is installed in place of the generated one. Ditto for mfilterjavac.
While this does create a small maintenance problem, I think that any other
approach, for example, modifying the generation of wrapper scripts to account
for this, is going to be a larger maintenance problem.
TODO:
- handle batch file launchers for Windows.
- handle other executables in the Mercury system (although most of these
are not so important in this context).
compiler/Mmakefile:
mfilterjavac/Mmakefile:
Do not install generated wrapper scripts from these directories in the Java
grade.
scripts/mercury_compile.sh-java:
scripts/mfilterjavac.sh-java:
Java wrappers scripts for the installed versions of the compiler
and mfilterjavac.
scripts/Mmakefile:
In the Java grade install the wrapper scripts for the compiler and
mfilterjavac from this directory.
