Discussion of these changes can be found on the Mercury developers
mailing list archives from June 2018.
COPYING.LIB:
Add a special linking exception to the LGPL.
*:
Update references to COPYING.LIB.
Clean up some minor errors that have accumulated in copyright
messages.
Add a new internal grade component corresponding to the use of 64-bit integers.
configure.ac:
Test whether we can use unboxed 64-bit integers.
Extend the check for whether previously built C files are compatible with
configure determined settings to cover whether 64-bit integer are boxed
or not.
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
Set the compiler flag for unboxed 64-bit integers if configure determines
they can be used.
runtime/mercury_grade.h:
Add the "ubi64" grade component
About a week ago, Julien added targets to */Mmakefile to build .cs files.
These referred to undefined mmake variables of the form "program_name.css".
compiler/write_deps_file.m:
Add rules to generate definitions for "program_name.css".
Following the pattern of similar definitions such as program_name.javas,
these refer to other mmake variables css_subdir and cs_date_subdir.
scripts/Mmake.vars.in:
Add definitions for css_subdir and cs_date_subdir.
... by eliminating the grade component that calls for the use of gcc nested
functions.
runtime/mercury_grade.h:
compiler/compute_grade.m:
Delete the gcc_nested_functions grade component, and the C macro
that specifies its presence, MR_USE_GCC_NESTED_FUNCTIONS.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/parse_grade_options.sh-subr:
Delete the code that parses the deleted grade component,
and delete the code that signals its absence in other grades.
compiler/options.m:
Delete the gcc_nested_functions grade option.
Delete also the gcc_local_labels option, since it was useful
only if gcc_nested_functions was set.
configure.ac:
Delete the code that sometimes added hl*_nest grades to the list of grades
to be installed.
Fix a bunch of comments.
compiler/compile_target_code.m:
compiler/handle_options.m:
compiler/mercury_compile_mlds_back_end.m:
compiler/ml_args_util.m:
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_gen_info.m:
compiler/mlds_to_c.m:
library/backjump.m:
library/exception.m:
runtime/mercury_hlc_types.h:
runtime/mercury_tabling.c:
runtime/mercury_tabling.h:
Delete code that was active only in grades with the deleted grade
component.
compiler/ml_accurate_gc.m:
compiler/notes/grade_library.html:
runtime/mercury_conf_param.h:
Delete mentions of the deleted grade component.
compiler/ml_code_gen.m:
Delete mentions of the deleted grade component, and a bunch of other
obsolete comments.
doc/user_guide.texi:
Fix a line break.
browser/browse.m:
Add save_and_browse_browser_term_web to be called when
"browse --web" is entered at the mdb prompt.
Add browser_term_to_html_flat_string, a helper predicate for
term_to_html.
Make portray_flat_write_browser_term work take a stream parameter
instead of writing to the current output stream. It is called by
browser_term_to_html_flat_string, writing to a string builder
stream.
browser/browser_info.m:
Add web_browser_cmd field to browser_persistent_state.
browser/mdb.m:
browser/term_to_html.m:
Add new module to generate an HTML document. The document contains a
JavaScript represention of a Mercury term.
(The JavaScript string escaping code is adapted from Julien's
mercury-json project.)
browser/percent_encoding.m:
Add new module to perform percent-encoding.
scripts/mdb_term_browser.css:
scripts/mdb_term_browser.js:
Add JavaScript and CSS files referenced by the generated HTML file
to create a tree view of a Mercury term using jstree.
scripts/32px.png:
scripts/40px.png:
scripts/throbber.gif:
scripts/jstree.min.js:
scripts/jstree.style.min.css:
Add local copy of jstree files <https://www.jstree.com/>
scripts/jquery.slim.min.js:
Add local copy of jquery <https://jquery.com/>
scripts/Mmakefile:
Install the new files into the same directory as mdbrc and other
mdb-related files.
trace/mercury_trace_browse.c:
trace/mercury_trace_browse.h:
trace/mercury_trace_cmd_browsing.c:
trace/mercury_trace_cmd_parameter.c:
trace/mercury_trace_cmd_parameter.h:
trace/mercury_trace_internal.c:
Add "browse --web" and "web_browser_cmd" commands.
doc/user_guide.texi:
Document "browse --web" and "web_browser_cmd" commands.
configure.ac:
scripts/mdbrc.in:
Set a reasonable default command to launch a web browser from mdb.
(Only tested on Linux.)
NEWS:
Announce the new feature.
.README.in:
Mention jquery and jstree licensing.
tests/debugger/Mmakefile:
tests/debugger/completion.exp:
tests/debugger/mdb_command_test.inp:
tests/debugger/save.exp2:
Update debugger tests for new commands.
Install the documentation, including info and man pages but not the mdb
docs, into the paths selected by ./configure. This also makes Mercury more
up-to-date with respect to Linux Distros' file locations, using share/doc/
rather than doc/
Doing the same for other files, such as binaries, libraries and the mdb
documentation, requires more working with autoconf than I'm happy to do
right now.
scripts/Mmake.vars.in:
As above.
configure.ac:
Add configure option --enable-sanitizers.
Mmake.common.in:
scripts/Mercury.config.in:
Add variables to be set when --enable-sanitizers is used.
scripts/mgnuc.in:
scripts/ml.in:
Pass sanitizer options to the C compiler and the linker.
compiler/options.m:
Add options --cflags-for-sanitizers and --linker-sanitizer-flags
for receiving the configuration.
Set --linker-trace-flags and --shlib-linker-trace-flags default
values to empty instead of "-g" (likely copy error).
compiler/compile_target_code.m:
Pass sanitizer options to the C compiler, and the linker when
building an executable or shared library.
runtime/Mmakefile:
trace/Mmakefile:
Pass sanitizer options to linker when building shared libraries.
README.sanitizers:
Add instructions.
Add a predicate that retrieves the number of processors available to this
process if known.
library/thread.m:
As above.
runtime/mercury_context.c:
The existing code that determines the number of processors was only used
on thread safe low-level C grades. Make it also available for thread
safe high-level C grades.
Add a fall back (less accurate) method of determining the number of
processors.
Remove an out-of-date comment.
runtime/mercury_context.h:
Export the number of available processors.
scripts/ml.in:
Link to libhwloc (if configured) on thread safe high and low-level C
grades.
NEWS:
Announce new predicate.
configure.ac:
Update a --help message.
scripts/prepare_install_dir.in:
tools/bootcheck:
Copy all of the MSVC makefiles variants for the Boehm GC into the
grade build directory / stage 2 directory.
For picreg, this is only the first half of the change; it deletes code
that generates references to this grade component. When this diff has been
installed on all our machines, will come the second half, which will delete
the code that understands references to picreg. The delay is needed because
your current installed compiler is still generating such references.
runtime/mercury_grade.h:
Remove both regparm and picreg as grade components.
doc/user_guide.texi:
Remove the (commented out) documentation of picreg; regparm had
no documentation to delete.
runtime/mercury_std.h:
Remove the small bit of code that implemented regparm.
runtime/mercury_conf_param.h:
Don't define MR_PIC_REG.
runtime/machdeps/i386_regs.h:
runtime/mercury_conf_bootstrap.h:
Remove references to picreg.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/parse_grade_options.sh-subr:
Keep in place the code that accepts picreg grade components,
but make them do nothing. Mark such do-nothing code so that
it can be deleted when this first-half diff has been bootstrapped.
configure.ac:
Delete the autoconfigured variable EXT_FOR_LINK_WITH_PIC_OBJECTS,
which could be set to either 'lpic_o' or just 'o', because it is now
*always* the latter.
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
Remove code that transmitted the value of EXT_FOR_LINK_WITH_PIC_OBJECTS
to the compiler via the --link-with-pic-object-file-extension option.
compiler/options.m:
Keep the --link-with-pic-object-file-extension and --pic-reg options,
but mark them for deletion in the second half of this change.
compiler/compile_target_code.m:
Change the code that dealt with the value of the
--link-with-pic-object-file-extension and --pic-reg options to assume
that the former is always the same as the non-pic file extension,
and that --pic-reg is never needed. The former means that we don't need
to handle link_with_pic as a separate category of object files from
just plain non_pic.
compiler/compute_grade.m:
Keep accepting picreg grades, but mark the code that does this
for deletion.
compiler/make.program_target.m:
compiler/make.module_target.m:
compiler/make.program_target.m:
compiler/make.util.m:
Conform to the changes above.
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-csharp:
Add a script script that runs an installed compiler built in the C#
grade using Mono. As with compilers built in the Java grade, the
wrapper script we generate in the compiler directory only works
in situ and we require a separate script for the installed version.
XXX TODO: we will need to handle .NET differently, probably by simply
renaming top_level.exe -> mercury_compile.exe.
scripts/Mmakefile:
Install the new script if the compiler was built in the C# grade.
Lots of Mercury types have a name that is also the name of one of the type's
function symbols, like this:
:- type allow_lco
---> do_not_allow_lco
; allow_lco.
When jumping to a tag that has two definitions, the type name and one of that
type's function symbols, it doesn't really matter which one we jump to, since
they are next to each other. It is therefore annoying having vim ask us
to *choose* which one we want to jump to.
A while ago, I added code to mtags to fix this annoyance, but it worked
only when the functor had no arguments.
scripts/mtags.in:
Make the fix work even when the functor has arguments, by making the
test work on a version of the tag AFTER, not BEFORE, the argument list
following non-zero-arity function symbols is stripped off.
Feedback of the upgrade of Boehm GC indicated that including the
libatomic_ops submodule in the top-level was inconvenient, and I agree.
This change, along with a corresponding change to the boehm_gc repository,
will instead included it as a nested submodule of boehm_gc.
.gitmodules:
libatomic_ops:
Remove libatomic_ops submodule.
boehm_gc
Update to the most recent revision that adds a libatomic_ops submodule.
prepare.sh:
Update submodules recursively.
Mmakefile:
scripts/prepare_install_dir.in:
tools/bootcheck:
Remove code in build tools that links or copies the libatomic_ops
directory from Mercury's top-level,
tools/build_srcdist:
De-initialise the git submodules prior to building the source
distribution. They are then setup again, with clean working
directories, by the call to ./prepare.sh.
Mmakefile:
Handle the the new location of libatomic_opss in the "tar" target.
scripts/prepare_install_dir.in:
Handle both usage in the source distribution where
boehm_gc/libatomic_ops is a directory, and usage in a development
workspace where boehm_gc/libatomic_ops is a symlink.
This is the 7.4.2 release plus some bug fixes, such as fixes for the TSX
bug.
.gitmodules:
Update to the release-7_4 branch
boehm_gc:
libatomic_ops:
Update submodules.
compiler/notes/upgrade_boehm_gc.html:
Update documentation.
scripts/prepare_install_dir.in:
Conform to changes in the boehm_gc repository.
GC_stackbottom, GC_gc_no and GC_dont_gc are now deprecated. These changes
use new options in the API where possible.
Update scripts to copy the boehm_gc and libatomic_ops directories correctly.
Pass Boehm GC the correct flags for thread support
Update documentation regarding the version of Boehm GC.
runtime/mercury_wrapper.c:
Don't use the deprecated GC_dont_gc variable.
library/benchmarking.m:
Use GC_get_stackbottom() to get the bottom of stack and GC_get_gc_no()
to get the number of collections so far.
util/mkinit.c:
Do not explicitly set GC_stackbottom anymore, except on AIX where it
cannot be found automatically.
scripts/prepare_install_dir.in:
tools/bootcheck:
tools/build_srcdist:
Add some missing files present in Boehm GC 7.4.2 that wern't present
earlier and remove some old ones.
Coby and link the libatomic_ops directory correctly.
.README.in:
bindist/bindist.README:
Update documentation regarding the version of Boehm GC.
configure.ac:
Something in Boehm GC's build system has changed and we must now pass
-DGC_THREADS whenever building threadsafe versions of BOehm GC. This is now
done using the BOEHM_MISC_CFLAGS_FOR_THREADS autoconf variable, which has
been renamed to BOEHM_CFLAGS_FOR_THREADS now that it is more generally used.
Boehm GC no longer (or perhaps never did) require developers to specify the
type of threading to use, eg -DGC_LINUX_THREADS rather than -DGC_THREADS.
With the exception of win32-pthreads. We now pass -DGC_THREADS whereever
possible.
Mmake.common.in:
Rename BOEHM_MISC_CFLAGS_FOR_THREADS.
Lots of Mercury types have a name that is also the name of one of the type's
function symbols, like this:
:- type allow_lco
---> do_not_allow_lco
; allow_lco.
When jumping to a tag that has two definitions, the type name and one of that
type's function symbols, it doesn't really matter which one we jump to, since
they are next to each other. It is therefore annoying having vim ask us
to *choose* which one we want to jump to.
scripts/mtags.in:
Avoid this annoyance by not generating a tag file entry for function
symbols whose name is the same as the name of their containing type.
compiler/mlds_to_il.m:
compiler/mlds_to_ilasm.m:
compiler/mlds_to_managed.m:
compiler/il_peephole.m:
compiler/ilasm.m:
compiler/ilds.m:
Delete the modules making up the MLDS->IL code generator.
compiler/globals.m:
compiler/prog_data.m:
Delete IL as a target and foreign language.
compiler/prog_io_pragma.m:
Delete the max_stack_size/1 foreign proc attribute. This was only
ever required by the IL backend.
compiler/options.m
Delete options used for the IL backend.
compiler/write_deps_file.m:
Don't generate mmake targets for .il files etc.
compiler/*.m:
Conform to the above changes.
compiler/notes/compiler_design.html
compiler/notes/work_in_progress.html
Conform to the above changes.
library/*.m:
Delete IL foreign_proc and foreign_export pragmas.
README.DotNet:
Delete this file.
browser/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mdbcomp/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
runtime/Mmakefile:
slice/Mmakefile:
Conform the above changes.
configure.ac:
Don't check that IL is a supported foreign language when performing the
up-to-date check.
Delete the '--enable-dotnet-grades' option.
scripts/Mmake.vars.in:
Delete variables used for the IL backend (and in on case by the Aditi
backend).
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
scripts/Mmake.rules:
scripts/canonical_grade.sh-subr:
tools/bootcheck:
Delete stuff related to the 'il' and 'ilc' grades.
doc/reference_manual.texi:
Delete the documentation of the 'max_stack_size' option.
doc/user_guide.texi:
Delete stuff related to the IL backend.
tests/hard_coded/csharp_test.{m,exp}:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/valid/csharp_hello.m:
Delete these tests: they are no longer relevant.
tests/hard_coded/equality_pred_which_requires_boxing.m:
tests/hard_coded/foreign_import_module.m:
tests/hard_coded/foreign_import_module_2.m:
tests/hard_coded/foreign_type.m:
tests/hard_coded/foreign_type2.m:
tests/hard_coded/foreign_type3.m:
tests/hard_coded/intermod_foreign_type2.m:
tests/hard_coded/lp.m:
tests/hard_coded/user_compare.m:
tests/invalid/foreign_type_2.m:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/invalid/foreign_type_visibility.m:
tests/invalid/illtyped_compare.{m,err_exp}:
tests/submodules/external_unification_pred.m
tests/valid/big_foreign_type.m
tests/valid/solver_type_bug.m
tests/valid_seq/foreign_type_spec.m
tests/valid_seq/intermod_impure2.m
Delete IL foreign_procs where necessary.
tests/hard_coded/Mmakefile
tests/invalid/Mercury.options
tests/invalid/Mmakefile
tests/submodules/Mmakefile
tests/valid/Mercury.options
tests/valid/Mmake.valid.common
tests/valid/Mmakefile
tests/valid_seq/Mmakefile
tests/valid_seq/Mercury.options
Conform to the above changes.
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.
scripts/final_grade_options.sh-subr:
Print an error and exit with a non-zero exit status for
various invalid grade component combinations.
Implicitly disable the .par component for the non-C backends.
This doesn't affect the support for threads in grades that
use these backends.
The default configuration of Mercury on Windows breaks when using the Java
grade due to the argument we pass to the Java compiler's '-J' option, in order
to set the maximum heap size, not being quoted in the @file we pass to the Java
compiler when '--restricted-command-line' is enabled.
What should be placed in the @file is:
-J"-Xmx1024m"
What we currently put in it is:
-J-Xmx1024m
The reason for this is that the setting of JAVAC_FLAGS_FOR_HEAP_SIZE in
scripts/Mercury.config does not escape the double quotes, consequently they do
not get passed through the Mercury compiler to the aforementioned @file. This
problem was already correctly identified and documented in the comments
accompanying the MERCURY_CHECK_JAVAC_HEAP_SIZE macro in m4/mercury.m4, but the
actual behaviour of that macro is incorrect. In particular, it fails to
account for the fact that the value of JAVAC_FLAGS_FOR_HEAP_SIZE should differ
depending on whether mmake or 'mmc --make' is using that value. The current
value will work for mmake but not with 'mmc --make'
(and '--restricted-command-line').
The fix is to separate the handling of the mmake and 'mmc --make' cases and
correctly escape the version that is put in Mercury.config.
configure.ac:
m4/mercury.m4:
Define separate configuration variables for mmake and 'mmc --make' to
set the Java compiler's maximum heap size.
scripts/Mercury.config.in:
scripts/Mercury.config.bootstrap.in:
scripts/Mmake.vars.in:
Conform to the above change.
This file-specific setting will override a default setting of expandtabs
in $HOME/.vimrc.
*/Makefile:
*/Mmakefile:
As above.
tests/hard_coded/.gitignore:
Don't ignore the purity subdir. This ignore must have been left over
from when purity.m was a test in hard_coded, not hard_coded/purity,
and it ignored an executable, not a directory.
It was intended that the C compiler type string for MSVC would eventually have
the form "msvc_<n>" (where <n> is the version number). The configure script is
still generating the older form of string, "cl_<n>"; we want to avoid this
because it's too easy to confuse with clang. Make configure generate the new
kind of C compiler type string.
configure.ac:
Generate the new sort of compiler type strings for MSVC.
scripts/mgnuc.in:
compiler/globals.m:
Do not recognise the old sort any longer.
Drop support for lcc as a C compiler. lcc itself does not seem to have been
updated since around 2010 and Mercury's support for it has not been updated for
quite a while before that.
Derivatives of lcc, for example lcc-win32, would almost certainly need to be
treated separately anyway, so this change doesn't affect them (i.e. they are
already not supported).
configure.ac:
m4/mercury.m4:
Do not recognise lcc as a C compiler.
Unrelated change: remove residual support for a.out executables on Linux.
scripts/mgnuc_file_opts.sh-subr:
Do not define the macros __EXTENSIONS__ and _GNU_SOURCE if the mgnuc script
is invoked with --no-ansi. This was originally done to support lcc on Linux.
Doing so on *all* systems as this code actually does is not a good idea.
(If it becomes necessary to reinstate this behaviour on some system, it
should be controlled from the configure script not here.)
runtime/mercury_wrapper.c:
Delete a workaround for lcc.
scripts/mgnuc.in:
scripts/ml.in:
compiler/compile_target_code.m:
compiler/handle_options.m:
compiler/globals.m:
compiler/ml_code_gen.m:
Delete support for lcc.
README.lcc:
Delete this file.
Passing -ansi to GCC restricts us to the C90 dialect of C and prevents us from
using C99 library features with GCC. Since every version of GCC we support
provides the relevant C99 features there is not much point to imposing this
restriction. As already noted in the configure script the use of -ansi was
also causing problems with the header files on MinGW systems. Finally, I do
think it is reasonable to require users to use the C90 dialect of C in
foreign_proc and foreign_code pragma bodies by default.
NOTE: this is *not* an invitation to start using C99 language features
throughout the runtime and library -- at this point, we (unfortunately) still
maintain compatibility with older versions of MSVC that don't support these
features.
configure.ac:
Do not pass -ansi to GCC. Add an explanation of why.
scripts/mgnuc.in:
Update the description of the what the --no-ansi option does.
(XXX there's _a lot_ of out-of-date stuff in this script.)
As Tomas By's recent emails suggest, this support is doing more harm than good,
by falsely implying to people that MPS is a viable alternative to the Boehm
collector. The MPS collector was only ever experimental, and never performed
as well as Boehm. MPS isn't even in the git repository on git hub. It was
stored in a separate CVS repository on mundula, and (as far as I know)
wasn't carried over to github. The code of MPS was last touched a long time
ago; I would be surprised if it worked on today's systems without changes.
Mmake.common.in:
Mmake.workspace:
RESERVED_MACRO_NAMES:
boehm_gc/Mmakefile:
compiler/add_pragma.m:
compiler/compile_target_code.m:
compiler/globals.m:
compiler/handle_options.m:
compiler/mercury_compile_mlds_back_end.m:
compiler/mlds_to_c.m:
compiler/options.m:
compiler/peephole.m:
doc/user_guide.texi:
library/benchmarking.m:
runtime/Mmakefile.m:
runtime/mercury.h:
runtime/mercury_conf_param.h:
runtime/mercury_grade.h:
runtime/mercury_heap.h:
runtime/mercury_init.h:
runtime/mercury_memory.h:
runtime/mercury_wrapper.[ch]:
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/ml.in:
scripts/parse_grade_options.sh-subr:
util/mkinit.c:
Remove all references to MPS.
IRIX itself is more or less dead and the Mercury support for it has not been
tested for many years.
configure.ac:
compiler/notes/overall_design.m:
doc/user_guide.texi:
scripts/mgnuc.in:
As above.
NEWS:
Announce the above.
configure.ac:
Pass -x to strip when linking an executable against Mercury shared
libraries on Mac OS X.
Make the up-to-date check require {14.01.-beta,rotd}-2014-05-05
or later.
scripts/Mercury.config.in:
Set the default values of --strip-executable-{shared,static}-flags.
Some versions of the MinGW system headers rely on the types off_t and off64_t
being defined, but they will not be defined if -ansi is enabled.
(This seems to affect MinGW systems using GCC 4.8; I haven't checked other
GCC versions yet.)
configure.ac:
scripts/mgnuc.in:
Do not compile with -ansi on MinGW systems.
Currently we use the C89 definitions of MR_STATIC_INLINE and friends with
clang, which is less than ideal in a couple of ways, firstly we might not get
as much inlining as we would like and secondly, for clang, it causes large
numbers of warnings about unused functions to be generated.
Using GNU C style inlining does not work because we enable the -ansi option
when using clang and the (current) behaviour of the -ansi option with clang is
to enforce strict C89 conformance (i.e. disable any GNU C extensions.).
This change avoids all of the above by (1) adding C99 style definitions of
MR_STATIC_INLINE etc for clang and (2) not passing -ansi to clang (i.e. putting
clang into c99, or technically gnu99, mode). We fall back on the C89 style
definitions if the user does something odd like setting -ansi or -std=c89
themselves.
runtime/mercury_std.h:
Define MR_STATIC_INLINE and friends for clang in the case where clang
is in C99 (or equivalent) mode.
configure.ac:
Set CFLAGS_FOR_ANSI for clang to empty. Add an explanation of why
we do this.
scripts/mgnuc.in:
Don't pass -ansi to clang.
We had stopped passing the linker strip flag on Mac OS X because it had
become deprecated and useless there, but we can still strip the binary
with the `strip' tool.
This commit changes compile_target_code.m to do so, but NOT the
`ml' shell script.
compiler/options.m:
doc/user_guide.texi:
Add option --strip-executable-command.
configure.ac:
scripts/Mercury.config.in:
Set --strip-executable-command="strip" on Darwin platforms,
or an empty string elsewhere.
compiler/compile_target_code.m:
Invoke the --strip-executable-command separately after linking
an executable if necessary.
scripts/ml.in:
Fix a bug: use configured value of LD_STRIP_FLAG instead of
assuming "-s".
