Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Careful library deps #1192

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

jonludlam
Copy link
Member

@jonludlam jonludlam commented Aug 27, 2024

Make sure the set of libraries provided during linking only comes from the dependency libraries of the library being linked.

Also ensure that the modules in the libraries passed are in the normal include path.

Prior to this commit the link phase was only using the include paths coming from
`compile-deps` on the unit being linked. The fix is to use the library dependencies
coming from an external source - META files or dune metadata. We can't simply use
the union of the compile-deps paths from all units as we might still miss some
dependencies due to `--no-alias-deps`.
This ensures all units in the 'library' paths are accessible without
adding the /libname to the reference
@jonludlam jonludlam added the no changelog This pull request does not need a changelog entry label Aug 27, 2024
Copy link
Collaborator

@panglesd panglesd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, carefulness is much better than the over-approximation that did not follow the convention!

@@ -34,11 +34,14 @@ let of_dune_build dir =
let cmtidir =
Fpath.(path / Printf.sprintf ".%s.objs" libname / "byte")
in
let all_lib_deps = Util.StringMap.empty in
(* TODO *)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you intend to implement that for voodoo and dune in this PR too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was putting it off, it's a bit of a PITA, especially for the dune mode!

@@ -43,58 +43,53 @@ let of_packages ~output_dir ~linked_dir ~index_dir (pkgs : Packages.t list) :
in
let index_dir = match index_dir with None -> output_dir | Some dir -> dir in
(* This isn't a hashtable, but a table of hashes! Yay! *)
let hashtable =
let hashtable, lib_dirs =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are using StringMap quite a lot, why not use that instead of an associative list?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's do that

@@ -195,6 +194,7 @@ let of_packages ~output_dir ~linked_dir ~index_dir (pkgs : Packages.t list) :
let name = mld_path |> Fpath.rem_ext |> Fpath.basename |> ( ^ ) "page-" in
let unit =
make_unit ~name ~kind ~rel_dir ~input_file:mld_path ~pkg ~include_dirs
~lib_deps:[]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there anything bigger but still sensible we could use here?

  • We likely cannot add the union of the the lib_deps from the libraries of the package: I think there might be different deps with the same name? (not sure here).

I know we will provide a way to extend this, but having a bigger default would be nice!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the libraries in the package is what we decided before.

@@ -688,6 +688,7 @@ end = struct
current_dir;
}
in
let directories = directories @ List.map ~f:snd lib_roots in
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was about to say that this requires an update to the man for the -L option, but it was actually already saying that!

So whenever we can write {!/libname/Module} we can also write {!Module}.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure whether adding the paths to the include path was the best approach, or whether we should do something else elsewhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no changelog This pull request does not need a changelog entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants