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

ocamlbuild _tag equivalent to "-open M" #6584

Closed
vicuna opened this issue Sep 26, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link

commented Sep 26, 2014

Original bug ID: 6584
Reporter: @hcarty
Assigned to: @gasche
Status: closed (set by @xavierleroy on 2016-12-07T10:36:45Z)
Resolution: fixed
Priority: normal
Severity: feature
Version: 4.02.0+beta1 / +rc1
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Monitored by: @ygrek @hcarty

Bug description

It would be nice to have a matching flag to set in _tags to match the functionality of the new-in-4.02.0 "-open" command line argument. Something similar to:

_tags:

true: open(M)

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 26, 2014

Comment author: @gasche

As a matter of fact, the exact syntax you use is supported right now in 4.02.0: there is an open parametrized tag that does what you want.

However, what open() does not do is marking the module passed as a dependency of the modules to which it is applied. This means that using open() with a name of a module developed in the same project may not work, if ocamlbuild has no way to guess that this is a dependency. Consider for example:

a.ml:
let x = 1

b.ml:
let () = print_int x; print_newline ()

Then just using

_tags:
<b.*>: open(A)

will not work as-is because ocamldep (and thus ocamlbuild) will not magically guess that b.ml depends on a.cm{i,o}, and compilation will fail. However

let y = A.x (* or anything that creates an explicit dependency *)
let () = print_int x; print_newline ()

would work, and, without changing the original b.ml:

myocamlbuild.ml:

open Ocamlbuild_plugin;;

let _ = dispatch begin function
| After_rules ->
pdep ["ocaml"; "compile"] "depends"
(fun param -> [String.uncapitalize param ^ ".cmo"]);
pdep ["ocaml"; "link"] "depends"
(fun param -> [String.uncapitalize param ^ ".cmo"]);
| _ -> ()
end;;

_tags:
<b.*>: depends(A), open(A)

also works.

I think we might want consider this a bug report indicating that
ocamlbuild should try to automatically add a dependency to the open()
argument. But we have a risk of getting this wrong (while the current
semantics is very simple and predictable).

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 26, 2014

Comment author: @hcarty

Ah, I had not tried it. "ocamlbuild -documentation |grep open" doesn't show the flag.

Documenting the dependency limitation and including "depends" or its equivalent out of the box would be a nice.

Finally - with this new feature, would it make sense to include an implicit "-open Ocamlbuild_plugin" when myocamlbuild.ml is compiled?

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 26, 2014

Comment author: @gasche

"ocamlbuild -documentation |grep open" doesn't show the flag.

Yes, this is unfortunate. -documentation doesn't say anything about parametrized flags, because it's unclear what could be said. (One idea would be to call them with dummy string values and sort of see what happens, but that's an idea I find rather doubtful).

Documenting the dependency limitation and including "depends" or its equivalent out of the box would be a nice.

There is a bugfix release coming. If there is a simple way to fix the limitation, we should definitely go for it.

"depends" is useful in isolation but we would need something more complete to include (above it only handles compilation and linking). Would you open another PR for this?

Finally - with this new feature, would it make sense to include an implicit "-open Ocamlbuild_plugin" when myocamlbuild.ml is compiled?

I personally think "-open" is going in the wrong direction: we should take back control of the semantics of our program from the command-line, rather than give it more power over our code. It was included to be used in very specific use-cases (large-scale -no-alias-deps mapping files) and we lack experience to see where it is nice and where it hurts. I think that's too early.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 29, 2014

Comment author: @hcarty

Submitted as #6589 (#6589)

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 3, 2014

Comment author: @gasche

The underlying dependency-computation issue is now resolved in 4.02 and trunk, by adding support for the "-open M" flag in ocamldep itself (and then simply having ocamlbuild pass this flag to ocamldep). This should help other ocamldep-relying systems as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.