[m-dev.] mmc --generate-dependencies and foreign import modules

[Keri Harris]

Hi.

I was curious to see whether I could get to the bottom on this. Would
the following would be sufficient to address this issue?


diff --git a/compiler/module_deps_graph.m
b/compiler/module_deps_graph.m
index c916c4cce..1c5dba2f2 100644
--- a/compiler/module_deps_graph.m
+++ b/compiler/module_deps_graph.m
@@ -41,6 +41,8 @@
 
 :- implementation.
 
+:- import_module parse_tree.prog_data_foreign.
+
 :- import_module set.
 
 :- type deps_graph_key == digraph_key(module_name).
@@ -108,9 +110,13 @@ add_imp_deps(ModuleKey, ModuleImports, !DepsGraph)
:-
     % The implementation dependencies are a superset of the
     % interface dependencies, so first we add the interface deps, ...
     add_int_deps(ModuleKey, ModuleImports, !DepsGraph),
-    % ... and then we add the impl deps.
+    % ... and then we add the impl deps, ...
     module_and_imports_get_imp_deps_set(ModuleImports, ImpDeps),
-    set.foldl(add_dep(ModuleKey), ImpDeps, !DepsGraph).
+    set.foldl(add_dep(ModuleKey), ImpDeps, !DepsGraph),
+    % ... and then add foreign import deps.
+    module_and_imports_get_c_j_cs_e_fims(ModuleImports, CJCsEFIMs),
+    ForeignModules = get_all_foreign_import_modules(CJCsEFIMs),
+    set.foldl(add_dep(ModuleKey), ForeignModules, !DepsGraph).
 
     % Add parent implementation dependencies for the given Parent
module
     % to the implementation deps graph values for the given ModuleKey.


The hard_coded/foreign_import_module test passes with the above change,
but I'm not sure whether the above patch introduces other problems.


Thanks

Keri

On 27/03/2020 14:11, Julien Fischer wrote:
> Hi Keri,
> 
> Apologies for the belated response.
> 
> On Mon, 23 Mar 2020, Keri Harris wrote:
> 
> 
> I've noticed that with mercury 20.01.1 the
> hard_coded/foreign_import_module unit test is failing:
> 
>   mmc --generate-dependencies foreign_import_module
>   mmc --compile-to-c foreign_import_module
>   mgnuc -- -c foreign_import_module.c -o foreign_import_module.o
>   foreign_import_module.c:40.10: fatal error:
>    foreign_import_module_2.mh: No such file or directory
>   compilation terminated.
> 
> It also fails with the most recent ROTD, but only when I run the test
> manually, e.g.
> 
>      $ mmake foreign_import_module.depend
>      $ mmake foreign_import_module.runtest
> 
> OTOH, doing a mmake runtest in the tests/hard_coded directory works
> fine.
> 
> 
> It appears that the 'mmc --generate-dependencies' step is generating
> a
> '.d' file which is missing .mh dependencies:
> 
>   $ mmc --generate-dependencies foreign_import_module
> 
>   $ grep -A4 "foreign_import_module\.\$O" foreign_import_module.d
>     foreign_import_module.$O : \
>                     builtin.mh \
>                     int.mh \
>                     io.mh \
>                     private_builtin.mh
> 
> What exactly --generate-dependencies *does* do has been the subject
> of
> some discussion on the reviews lists recently ;-)
> 
> 
> After the subsequent call to 'mmc --compile-to-c' the '.d' file does
> contain all dependencies:
> 
>   $ mmc --compile-to-c foreign_import_module
> 
>   $ grep -A7 "foreign_import_module\.\$O" foreign_import_module.d
>     foreign_import_module.$O : \
>                     array.mh \
>                     bitmap.mh \
>                     foreign_import_module.mh \
>                     foreign_import_module_2.mh \
>                     io.mh \
>                     string.mh \
>                     time.mh
> 
> Running 'mmc --make foreign_import_module' works, but the unit tests
> 
> mmc --make use a different chunk of code do compute file depenencies.
> 
> 
> rely on 'mmc --generate-dependencies' generating a correct dependency
> graph. Is this a known issue?
> 
> It is now - thanks for reporting it.
> 
> Julien.
>