[m-rev.] for review: start on replacing --intermod-directories and related options

Zoltan Somogyi zoltan.somogyi at runbox.com
Wed Nov 13 23:41:46 AEDT 2024


On 2024-11-13 21:56 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>> 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?
> 
> Every program I work on, other than the Mercury implementation itself, uses
> either (1) installed libraries or (2) just uses source file mapping to build
> all of the program from a single build directory.  The main use case I would
> have for using non-installed libraries like the above is for testing
> libraries
> I have written in situ. For that case the above assumptions are justifiable.

Thanks. That matches my intuition.

>> 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?
> 
> Conceivably, there may have been some notion of finding clauses for
> intermodule
> inlining in the source files installed in those directories (i.e. rather
> than
> putting them directly in .opt and .trans_opt files).  Regardless, it does
> not
> seem to be a useful behaviour *now*.

Then I will next look into undoing it.

> That looks fine otherwise.

Thanks. I followed your other suggestions.

Zoltan.


More information about the reviews mailing list