[m-rev.] for review: start on replacing --intermod-directories and related options
Zoltan Somogyi
zoltan.somogyi at runbox.com
Tue Nov 12 15:54:14 AEDT 2024
For review by anyone.
This diff does not include user-facing documentation of the
new options, but it does describe how they are intended to operate
in the code. Once there is agreement on the approach, I will
- implement the approach to replace the related options, such as
--search-directories, and
- add user-facing documentation of the new options, both in
compiler/options.m and doc/user_guide.texi.
The questions I am seeking particular feedback on are these.
First, this diff classifies directories in search paths into three categories:
(a) workspace directories that share the same subdir setting, i.e they use
the same values of --use-subdirs and --use-grade-subdirs, (b) workspace
directories that may use a different subdir setting, and (c) installed library
directories. The current code assumes that all directories in category (a)
come before all directories in categories (b) and (c), and all directories
in category (b) come before all directories in category (c). This is always
true in the compiler and in all the other Mercury programs I have worked on,
but you guys work on a wider variety of programs. Is this assumption
justifiable, or should I switch to an approach that does not make any
such assumptions?
Second, can anyone think of better names for the new options?
Is the use of "same", "indep" and "install" to describe the above three
categories understandable (once documented), or does anyone
know a better naming scheme?
Third, the code of the get_ext_opt_deps and get_plain_trans_opt_deps
predicates in write_deps_file search for source files in directories named
by the --intermodule-directories option, when their caller passes them
look_for_src. I do not see any documentation of what the intention behind
this arrangement is. If and when the code finds the source file, it does nothing
with it; it just stops looking for that module's .opt or .trans_opt file.
This behavior was introduced by Simon in a commit on 6 nov 1996,
but the log message is not informative, and we don't even have mailing list
archives from that far back. So my question is: does anyone have any idea
of what that code is doing or why it is doing it, and what would be the
impact of deleting that search?
Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.isp
Type: application/octet-stream
Size: 2036 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20241112/e82ca693/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.isp
Type: application/octet-stream
Size: 46451 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20241112/e82ca693/attachment-0003.obj>
More information about the reviews
mailing list