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".
In the mgnuc script, do not use the name of the C compiler to determine its
type since on OS X with Xcode 5 the executable "gcc" is actually clang.
Instead use the value of C_COMPILER_TYPE determined by the configure script to
set C compiler type, as elsewhere in the Mercury system.
Incorrectly identifying the C compiler type was resulting in lots of
compilation warnings because we were using the warning flags intended for GCC
with clang. Further warnings were being generated because GCC-only
optimization flags would also be passed to clang.
scripts/mgnuc.in:
As above.
Fix some problems that were preventing the system from compiling properly with
MSVC.
(1) Visual Studio 2013 no longer includes the files NtWin32.Mak and Win32.Mak
which are required for building the Boehm GC with MSVC. (This appears to be an
issue with upstream Boehm as well.) The workaround here is to reference the
copies of this files included with the Windows 7 SDK. (This appears to be the
official Microsoft workaround for dealing with this problem for now.)
(2) Disable support for `--c-debug' when using MSVC. Using this option causes
MSVC to emit .pdb (Program Data Base), that contain the symbol information for
an object files. This causes a variety of problems:
(i) parallel builds are contending for the vc*.pdb file shared by all the
object files in a directory causing compilation to abort. (Compiling with
the -FS option is another solution to this -- it causes the compiler to
serialize access to the .pdb file -- but at the cost of slowing down
compilation.)
(ii) .pdb files are not cleaned up by realclean; compilation will abort
if a pdb file generated by a different version of MSVC is encountered.
(iii) we don't install the .pdb files alongside the libraries anyway.
This can be a source of linker warnings. (And shutting up the Microsoft
linker seems to be very difficult indeed ...)
(iv) compiling with -Zi (apparently) inhibits some C compiler optimizations.
Compiling with the older -Z7 (MSVC 7 style debugging info) option is another
alternative. Using that option causes MSVC to include symbol information in
the object files, instead of in a separate file.
For now (i.e. the 14.01 release), disabling `--c-debug' for MSVC is the
simplest way of addressing the above issues.
README.MS-VisualC:
Describe the problem with NtWin32.Mak and Visual Studio 2013 and
provide two possible workarounds.
Mention that `--c-debug' is not currently supported with MSVC and how
to re-enable it.
Simplify some of the instructions for setting up the build environment.
configure.ac:
scripts/mgnuc.in:
Disable `--c-debug' with MSVC.
scripts/prepare_install_dir.in:
Copy all makefile fragments for nmake into the boehm_gc directory for
the library grade installation. (This is in case the user copies
NtWin32.Mak etc into the boehm_gc directory as per the second of
the workarounds in README.MS-VisualC.)
slice/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
slice/Mmakefile:
Clean up any .pdb files. Note that one is generated for each
executable (regardless of whether -Zi is given to cl or not).
In addition, if -Zi is given to cl, there will be file named
vc<version>.pdb generated (where <version> is the version of MSVC being
used.)
We encounter internal errors in GCC 4.8.2 on i686 Linux when compiling
runtime/mercury_ho_call.c in grades that use global registers when -fpic is
enabled. Compile that module at -O0 in the above circumstances; doing so
avoids tickling the bug.
scripts/mgnuc.in:
As above.
scripts/Mercury.config.in:
scripts/Mercury.config.boostrap.in:
Add the environment variable MERCURY_TARGET_ARCH, which allows
the compiler's target architecture to be overridden in the
environment.
compiler/options.m:
Add the option --target-arch as a synonym (and eventually, replacement)
for the --fullarch option.
A number of patterns and filenames where missing from .gitignore files,
especially in the tests/ directory.
.gitignore:
boehm_gc/.gitignore:
boehm_gc/libatomic_ops/pkgconfig/.gitignore:
runtime/.gitignore:
scripts/.gitignore:
tests/.gitignore:
tests/analysis/table/.gitignore:
tests/analysis/trail/.gitignore:
tests/benchmarks/.gitignore:
tests/debugger/.gitignore:
tests/invalid/.gitignore:
tests/mmc_make/.gitignore:
tests/mmc_make/lib/.gitignore:
Add new patterns to .gitignore files.
Remove some patterns that are implicit because they're in a parent
directory's file.
tests/analysis/.gitignore:
After removing superfluous patterns this file was empty. I've deleted
it.
Use -R instead of -r with cp by default.
Fix some documentation errors.
compiler/options.m:
Enable library grade detection by default.
Document the --no-detect-libgrades option.
Make the default install command dir option, -R,
rather than -r. The former is more portable.
scripts/Mercury.config.in:
Do not hardcode the set of library grades at configuration time.
compiler/mercury_compile.m:
Do not clear the library grade set before adding any detected
grades since doing so also prevents additional grades being
specified via the LIBGRADES variable.
doc/user_guide.texi:
Document --no-detect-libgrades.
Replace some uses of `:' as a module qualifier.
Fix a typo: s/outut/output/.
On Solaris, the 'which' utility does not return a non-zero exit status
to indicate that the program (in this case, "mfiltercc") was not found,
so we ended up treating its error message output as a path.
scripts/mgnuc.in:
Don't use 'which'. Simply try to run any copy of mfiltercc on
the PATH, with empty input.
Add a `pregen' grade component and associated option `--pregenerated-dist',
intended for use in the pre-generated C files in the source distribution
ONLY.
Traditionally, by forcing the use of 2 tag bits and boxed floats, we
could provide one set of pre-generated C files, nominally targeting
32-bit platforms but also working on 64-bit platforms.
This became insufficient after I made two data representation changes.
The same constructor may have different layouts of its arguments
for --bits-per-word=32 and --bits-per-word=64:
- double-precision `float' arguments can be stored across two
words on 32-bit, whereas only one word is required on 64-bit;
- consecutive enum arguments can be packed into a single word
but the number of arguments that can be packed differs.
As a result, data structures created in a user module could be
misinterpreted when passed to a pre-generated standard library module,
and vice versa. (The enum case probably does not occur in practice.)
The solution adopted here is to allow configure to detect normal 64-bit
settings (3 tag bits, unboxed floats) irrespective of whether a usable
Mercury installation already exists. When present, the `pregen' grade
component causes the compiler and scripts to override the configuration
and enforce settings for portable C source files. The source
distribution should supply C source files from a `pregen' grade.
During installation, if required, the pre-generated C source files are
used to build and install a Mercury compiler _in a .pregen grade_.
Then it is used to install the libraries _in non-.pregen grades_,
so that configured settings have their usual effect.
Another benefit is that a user on a 64-bit system will get the "optimal"
installation using 3 tag bits and unboxed floats without additional
effort.
A small disadvantage is that a minimal installation of Mercury takes
slightly longer, as the default library grade no longer comes from the
pre-generated C source files.
compiler/options.m:
Add `--pregenerated-dist' option (same as `pregen' grade component).
Add `--arg-pack-bits <n>' internal option.
`--allow-argument-packing' is obsolete.
Add `--allow-double-word-fields' internal option.
compiler/handle_options.m:
Add `pregen' grade component. `pregen' implies boxed floats and
`spf' (single-prec float) implies unboxed floats, so we consider
them incompatible. There should be no need to use both at once.
In `pregen' grades, override settings to create portable C
source files.
Handle the internal `--arg-pack-bits <n>' option.
compiler/make_hlds_passes.m:
Pack only as many consecutive arguments as will fit into the
number of bits specified by `--arg-pack-bits', rather than into
the number of word bits. `pregen' implies --arg-pack-bits=32
Use `--allow-double-word-fields' to decide whether to store
floats across two words. `pregen' disables it.
compiler/compile_target_code.m:
Define MR_PREGENERATED_DIST when compiling C files in a `pregen'
grade.
compiler/c_util.m:
Write PREGENERATED_DIST={yes,no} into the grade info header at
the top of C files. This is checked by configure.
runtime/mercury_conf_param.h:
Make MR_PREGENERATED_DIST force the same settings as the
`--pregenerated-dist' option.
runtime/mercury_grade.h:
Add "_pregen" to the MR_GRADE macro so that `pregen' and
non-`pregen' object files are not accidentally mixed.
configure.ac:
As above, do NOT force 2 tag bits and unboxed floats when there
is no usable Mercury compiler installed.
BOOTSTRAP_GRADE is now a grade containing `.pregen'.
Make a minimal installation install $BEST_GRADE_FOR_COMPILER as
the default grade, not the grade that the compiler happens to be
built in, which might be a `pregen' grade.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/parse_grade_options.sh-subr:
Support `pregen' grade component and `--pregenerated-dist'
in shell scripts.
tools/test_mercury:
Add a note.
As discussed in the recent Mercury meeting, remove support for the GCC backend.
It was very much out of date and supporting it proprerly would means having to
track changes to GCC's internals. Furthermore, its presence complicates
building the compiler.
The main thing this change does not address is the fact that we invoke
the compiler through C code, e.g. main.c in the top-level of the source
tree. This was required by the GCC backend and can now be removed, but
I will do that as a separate change.
configure.ac:
Mmake.common.in:
scripts/Mmake.rules:
compiler/Mercury.options:
compiler/Mmakefile:
compiler/gcc.m:
compiler/maybe_mlds_to_gcc.pp:
compiler/mlds_to_gcc.m:
Delete the files containing the GCC backend.
compiler/options.m:
compiler/handle_options.m:
Delete support for `--target asm' and `--pic'.
(The latter was only used by the GCC backend.)
compiler/*.m:
doc/user_guide.texi:
compiler/notes/comiler_design.html:
compiler/notes/work_in_progress.m:
Conform to the above change.
README.gcc-backend.m:
Delete this file.
configure.in:
Rename this to configure.ac which is what current versions
of autotools expect and also doesn't cause warnings to be
emitted by aclocal.
Mmakefile:
scripts/ml.in:
Conform to the above change.
Delete the empty lazy_evaluation directory from extras.
*/.cvsignore:
Make this into .gitignore files.
(Update them where necessary.)
extra/lazy_evalution:
Delete this directory; its former contents were moved
elsewhere some time ago.
Estimated hours taken: 2
Branches: main, 12.08
Sign the all the assemblies in the csharp grade.
mercury.snk:
The strong name key used for signing.
analysis/ANALYSIS_FLAGS.in:
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Pass the signing key to the c# compiler.
scripts/prepare_install_dir.in:
Copy mercury.snk to the install dir.
Estimated hours taken: 4
Branches: main
Upgrade to version 7.2 of the boehm gc.
This upgrade was done as 7.2 alpha 4 doesn't compile cleanly under Solaris 10.
Branches: main, 11.07
Fix further problems with building the csharp grade on Cygwin using the
Microsoft compiler. There were two main problems:
(1) Mercury.config.bootstrap had not been updated so the environment
and csharp compiler types for the stage 1 compiler were incorrect.
(2) The '/' in Microsoft style /OPTIONS was sometimes being treated
as a path separator for the purposes of path conversion.
scripts/Mercury.config.bootstrap.in:
Bring this file back into sync with Mercury.config.
compiler/compile_target_code.m:
Use - style options with the csharp compiler rather than / style
ones.
(In addition to causing the above problem, the use of / also tends
to cause trouble with POSIX style shells in general - we already avoid
the use of / style options with MSVC for the same reason.)
Break some overlong lines.
compiler/handle_options.m:
Break an overlong line.
Branches: main, 11.07
Set the host and target environment types at configuration time. By default,
they were both set to "posix" but that is no longer compatible with building
the csharp grade using the Microsoft compiler.
configure.in:
Set the environment type to "cygwin" on Cygwin, to "msys" on MinGW
and to "posix" otherwise. (For Mercury installations that work with
the Windows command interpreter, it will need to be manually set to
"windows".)
scripts/Mercury.config.in:
Set the environment type. (We set the target and host separately
so that is easier for installers to automatically modify this file.)
README.MS-VisualC:
Conform to the above change.
Estimated hours taken: 4
Branches: main, 11.07
The Microsoft C# compiler only accepts paths in the Windows format, so
add code to format file names depending on which host environment we are
compiling and which C# compiler we are using.
compiler/compile_target_code.m:
Convert to file names to use windows paths when required.
compiler/globals.m:
compiler/handle_options.m:
compiler/mercury_compile.m:
compiler/options.m:
doc/user_guide.texi:
m4/mercury.m4:
scripts/Mercury.config.in:
Add code to determine the C# compiler type and pass it to the compiler.
library/Mmakefile:
We no longer need to detect if we are using csc as the compiler
will fix the posix path as part of mmc --make.
Branches: main
Don't make the choice of whether MR_THREAD_SAFE is defined in parallel grades
in the configure script. There's no reason to do so and handling it
differently from the other grade component macros is just confusing.
compiler/compile_target_code.m:
scripts/mgnuc.in:
If we are in a parallel grade then define MR_THREAD_SAFE.
configure.in:
Don't include -DMR_THREAD_SAFE in the value of CFLAGS_FOR_THREADS.
Branches: main, 11.07
Add a new GC grade for the .ll_debug Mercury grade.
Previously the .ll_debug grade used the usual "gc" GC grade. This was a
problem, because it meant that installing a .ll_debug grade would overwrite the
libgc library with the unoptimised .ll_debug version, resulting in a severe
performance loss for applications even if they weren't built in the .ll_debug
grade.
compiler/compile_target_code.m:
Link against the ll_debug GC library if low-level debugging
is enabled.
scripts/ml.in:
Use the new ll_debug GC grade for the .ll_debug Mercury
grades.
Branches: 11.07, main
Improve and update documentation of the MSVC port.
Add batch files for invoking mdb and mprof; avoid problem with mercury.bat.
README.MS-VisualC:
Rewrite this file, it was very much out-of-date.
The major changes are:
+ we now describe how to set up a Cygwin or MSYS shell
with MSVC available.
+ the source distribution now works with MSVC.
+ a list of the limitations of the MSVC port has been added.
+ a description of how to set up the compiler so that it
works from the Windows command prompt has been added.
scripts/mercury/mercury.bat.in:
Delete support for the MERCURY_COMPILER and MERCURY_CONFIG_DIR
enviorment variables; the handling of them in this batch file
doesn't appear to be portable across different versions of
Windows and it's more important that this file work in the
normal case. (Keeping it simple is the way to ensure this.)
scripts/mdb.bat.in:
scripts/mprof.bat.in:
Templates for invoking mdb and mprof on Windows.
(I'm not sure how to reproduce all the functionality of the mdb
script in a batch file, so the command line options provided by
the mdb script aren't currently replicated here.)
configure.in:
scripts/Mmakefile:
Add the new batch files.
scripts/Mercury.config.in:
Use the Windows-style installation prefix on Cygwin systems.
browser/util.m:
Use the conventional name for the I/O state.
Use don't-care variables for the I/O state in foreign procs.
This avoids suprious warnings from MSVC.
reviews.
The configure script now supports the --without-hwloc option to disable the use
of hwloc, even if it is installed.
configure.in:
Allow the use of libhwloc to be disabled with the --without-hwloc option.
Distribute the autoconf macros for pkg-config with Mercury.
This allows mercury to be compiled from CVS on hosts that don't have these
macros in their autoconf installation.
acinclude.m4:
m4/mercury.m4:
Moved acinclude.m4 to m4/mercury.m4. This file contains mercury-specific
macros.
m4/pkg.m4:
Copied pkg.m4 from the autoconf installation on taura. This file contains
pkg-config macros.
INSTALL_CVS:
Mmakefile:
tools/test_mercury:
When calling aclocal pass the -I m4 option.
tools/bootcheck:
Create a link to the m4 directory when setting up stage directories.
Fix static linking with mmc --make and hwloc.
compiler/compile_target_code.m:
Conform to changes in scripts/ml.in (where static linking and hwloc is
already handled correctly).
compiler/options.m:
Create new options so that Mercury.config can tell mmc what options are
needed for linking to hwloc.
scripts/Mercury.config:
Pass hwloc linking options to the compiler.
