Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000433mercuryBugpublic2017-03-23 15:042018-03-13 14:38
Reporterpbone 
Assigned Topbone 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusacknowledgedResolutionopen 
Platformamd64OSLinux MintOS Version
Product Version 
Target VersionFixed in Version 
Summary0000433: mmc --make calls programs without full path
Descriptionif you have multiple installations of Mercury then calling tools like mkinit without the full path can lead to problems.
Steps To Reproduce
I have two installations of Mercury. In /usr I have 14.01.1 (this is the one I'm filing the bug against). And I have a recent ROTD in /usr/local (linked there by stow, stow is cool, check it out). But /usr/local is earlier in my path than /usr so that I can override my system's tools.

$ which mmc
/usr/local/bin/mmc

If I invoke the version in /usr it breaks.

$ /usr/bin/mmc --make hello
Making Mercury/int3s/hello.int3
Making Mercury/ints/hello.int
Making Mercury/cs/hello.c
Making Mercury/os/hello.o
** Error making `hello'.
Mercury/cs/hello_init.c: In function ‘mercury_init’:
Mercury/cs/hello_init.c:1736:29: error: ‘ML_std_library_init’ undeclared (first use in this function)
Mercury/cs/hello_init.c:1736:29: note: each undeclared identifier is reported only once for each function it appears in
Mercury/cs/hello_init.c:1737:27: error: ‘ML_std_library_finalize’ undeclared (first use in this function)
Mercury/cs/hello_init.c: At top level:
Mercury/cs/hello_init.c:1866:1: error: expected identifier or ‘(’ before ‘/’ token

It appears to be excuting the first mkinit it finds in my $PATH, which is incompatible. If I override $PATH, then it works without a problem.
Additional InformationI intend to fix this bug in the immediate future, I'm filing it now so that I can have a URL to point to it.
TagsNo tags attached.
Relationships
Attached Files

Notes
(0000946)
pbone   
2017-04-05 11:02   
I've been looking at this issue.

I'd like to store the full path to each of these tools (mkinit, mgnuc etc) in the configuration. scripts/Mercury.config.in seems like the best place to do that, and a similar change will need to be made for Mmake.

It's also desirable to use the libexec directory, and in particular allow ./configure to set these directories rather than creating them ourselves, ignoring ./configure. However that may make it a little tricker to "move" a mercury installation, but that too should be solvable.

Does anyone else seen any potential problems we may create by encoding the full paths in Mercury.config and allowing these files to be installed in different locations via ./configure's parameters?

Thanks.
(0000947)
wangp   
2017-04-05 11:24   
I think using full paths is the correct thing to do.

Allowing configure to adjust locations may get in the way of a different goal. I would like to see mmc --make and mmake use absolute paths built at runtime relative to a top-level directory either (1) deduced automatically based on the full path to mmc or mmake, or (2) manually overridden. This would allow moving the Mercury installation without touching any files. It would be especially useful for making prebuilt binary packages that could run immediately out of any user's home directory. (C compiler differences may still hamper that.)
(0000948)
pbone   
2017-04-05 11:40   
We can already move an installation by editing/rebuilding Mercury.config (and maybe another file). This change would make it more difficult to move an installation, there's just be more to edit within Mercury.config since it wouldn't build paths at runtime.

There's another option. Rather than either writing (in Mercury.config) the path to each tool/library, or writing the prefix and building paths at runtime, we could write the path to @bindir@ and @libexecdir@ and build paths from those at runtime. It'd be a little easier to move an installation, but give full flexibility to autoconf/building packages for distros.

I think either this, or writing the path to each tool in Mercury.config is the correct thing to do. There may be other ways to move an installation, such as by providing a simpler Mercury.config file that is based on most Linux distros' defaults with only one variable for the prefix.
(0000949)
wangp   
2017-04-05 12:01   
You can edit Mercury.config, but it is too difficult. Using Mercury on any (recent) Linux distribution should be as easy as tar xf mercury-bindist-xxxx.tar.gz

I'm wary of introducing a variable syntax to Mercury.config. Which locations need customisation? I don't think anyone would object to libexec. If I remember, we had agreement to move most scripts out of bin.
(0000950)
juliensf   
2017-04-05 12:03   
Files containing paths are:

   lib/mercury/conf/Mercury.config
   lib/mercury/mdb/mdbrc
   lib/mercury/mmake/Mmake.vars

as well as a bunch of scripts in the bin directory.

Also, macOS you won't just be able to shift an installation without rewriting all of the install_names in the dylibs.

@wangp: C compiler differences will definitely hamper that! In principle, we could build information about
known C compilers into the system, so that by setting --cc, --c-compile-type and --fullarch appropriately
it would select the correct set of flags. (I think I posted something to the developers list about this several years ago.) Of course, you will still have a problem with new C compiler versions that the Mercury compiler doesn't know about.
(0000977)
pbone   
2018-03-13 14:38   
Unassigned things from me.

Issue History
Date ModifiedUsernameFieldChange
2017-03-23 15:04pboneNew Issue
2017-03-23 15:04pboneStatusnew => assigned
2017-03-23 15:04pboneAssigned To => pbone
2017-04-05 11:02pboneNote Added: 0000946
2017-04-05 11:24wangpNote Added: 0000947
2017-04-05 11:40pboneNote Added: 0000948
2017-04-05 12:01wangpNote Added: 0000949
2017-04-05 12:03juliensfNote Added: 0000950
2018-03-13 14:38pboneStatusassigned => acknowledged
2018-03-13 14:38pboneNote Added: 0000977