Comment author: meyer

Command line options that have different meaning or don't exist in both versions of the compiler should not be supplied directly to ocamlbuild. The usual way of making ocamlbuild to use different set of command line options based on the compiler chosen is to use tags. Your example could be:

myocamlbuild.ml:
flag ["ocaml"; "compile"; "native"] (A "-S");;

While I agree that we could have `s' tag to do it, and maybe also -optflag option, here normally at the moment I can't see any immediate gain of doing that in the core of ocamlbuild, but I am open for any suggestions.

Comment author: DanGrayson

Thanks! But I can't make it work. And the reference manual mentions myocamlbuild.ml in just one non-useful place.

$ ocamlbuild -I src -I src/tactics -lflags -g -yaccflag -v -menhir 'menhir --explain --error-recovery' -use-menhir -cflags -g,-annot,-w,@8 src/checker.native
/Users/dan/src/coq-builder/bin/ocamlopt.opt -I /Users/dan/src/coq-builder/lib/ocaml/ocamlbuild unix.cmxa /Users/dan/src/coq-builder/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa myocamlbuild.ml /Users/dan/src/coq-builder/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild

• /Users/dan/src/coq-builder/bin/ocamlopt.opt -I /Users/dan/src/coq-builder/lib/ocaml/ocamlbuild unix.cmxa /Users/dan/src/coq-builder/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa myocamlbuild.ml /Users/dan/src/coq-builder/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
  File "myocamlbuild.ml", line 1, characters 0-4:
  Error: Unbound value flag

Comment author: DanGrayson

PS: Simpler than fixing ocamlbuild to filter -S from the command line so ocamlc doesn't get it would be to make ocamlc accept -S and do nothing.

Comment author: meyer

You have to open Ocamlbuild_plugin.

Comment author: DanGrayson

Thanks, opening Ocamlbuild_plugin worked.

It might be a good idea to add information about myocamlbuild to the reference manual.

Comment author: meyer

Actually, it might be going to be good to add -optflag command line option.

Comment author: @gasche

Wojciech, I'm assigning you the bug because you've be very helpful with the OCamlbuild development in the past, so I assume you may be interested in tackling this one as well. Feel free to de-assign if you're overloaded.

The problem is also present with all other flags that ocamlopt supports but ocamlc doesn't, such as -inline.

I'm not sure however that -optflags is the right way to go. In some sense the distinction between ocamlc and ocamlopt is orthogonal to the distinction between compilation and linking (as those compilers are also invoked for linking). Assuming we may have options supported by ocamlopt but not ocamlc for linking as well as compilation, splitting flags between -cflags, -lflags and -optflags seems awkward.

We could have -optcflags and -optlflags. But wouldn't be simpler if ocamlbuild took care of checking which flags can be passed to ocamlc (and ocamldep, etc.) and not pass the other?

The behavior I would expect is:

• have "ocamlbuild -cflags -inline,999 foo.native" work out of the box
• (optionally) have "ocamlbuild -cflags -inline,999 foo.byte" warn me about -inline not being meaningful in this context

Finally, in the specific case of the -S option, I'm not sure what's the best interface from ocamlbuild. I would rather have expected "ocamlbuild foo.s" to produce the assembly file, rather than "ocamlbuild -cflags -S foo.native". This could suggest having new targets for -S, and also possibly other temporary output (I would appreciate a .cmm target for example).
This is fairly orthogonal and I think we want both (because the target feature has smaller self-discoverability, so we should expect our users to try "-clfags -S" first and support that). Do you think that needs a separate bugtracker item?

Comment author: meyer

Gabriel, thanks for looking into that.

I'm not sure however that -optflags is the right way to go. In some
sense the distinction between ocamlc and ocamlopt is orthogonal to
the distinction between compilation and linking (as those compilers
are also invoked for linking). Assuming we may have options supported
by ocamlopt but not ocamlc for linking as well as compilation,
splitting flags between -cflags, -lflags and -optflags seems awkward.

I agree.

We could have -optcflags and -optlflags. But wouldn't be simpler if
ocamlbuild took care of checking which flags can be passed to ocamlc
(and ocamldep, etc.) and not pass the other?

That makes sense, however then ocamlbuild will not be anymore agnostic, and just substitute the options. To solve this problem, options should just create the right flags for tags. Maybe we then should have more generic -- dynamic way of specifying options -- but I suppose the best would be to keep the backward compatibility.

The behavior I would expect is:

• have "ocamlbuild -cflags -inline,999 foo.native" work out of the box
• (optionally) have "ocamlbuild -cflags -inline,999 foo.byte" warn me about -inline not being meaningful in this context

Finally, in the specific case of the -S option, I'm not sure what's
the best interface from ocamlbuild. I would rather have expected
"ocamlbuild foo.s" to produce the assembly file, rather than
"ocamlbuild -cflags -S foo.native". This could suggest having new
targets for -S, and also possibly other temporary output (I would
appreciate a .cmm target for example).

Makes sense.

So we have two pieces to improve ocamlbuild:

• drop mutable options and do as much as possible using standard ocamlbuild interface. And make people aware of that when using options inside plugins.
• support more targets (.s, .cmm, .lambda, etc.)

This is fairly orthogonal and I think we want both (because the target
feature has smaller self-discoverability, so we should expect our
users to try "-clfags -S" first and support that). Do you think that
needs a separate bugtracker item?

No, no need separate issue, at the moment, but perhaps your opinion matters here about the implementation detail I highlighted above.

Comment author: @gasche

I'm not sure how your suggestion for options would work. Are you suggesting, for example, to map "-cflag g -lflag -g" into setting the "debug" tag compilation-wide?
How does that relate to #5549 ?

Another cheap option would be to change ocamlc to accept flags only supported by ocamlopt, and ignore them with a warning instead of failing. It's a bit quick&dirty, but it could also be useful in other scenarios: sometimes I want to replace "ocamlopt" by "ocamlc" in a command-line for a quick test, and I'm annoyed when it fails because I used -inline.

Comment author: meyer

I'm not sure how your suggestion for options would work. Are you suggesting,
for example, to map "-cflag g -lflag -g" into setting the "debug" tag
compilation-wide?

No. Almost, it would just set S("-g") for the right set of tags:

let g_option_handler = fun () => flag ["compile"] (S("-g"); flag ["link"] (S("-g")

and I think treating options as flags is most consistent way. I'd prefer not doing too much logic using custom ocaml code. Just don't implement it as a simple concatenation of the sequence of flags for the compiler.

Comment author: meyer

How does that relate to #5549 [^] ?

It looks that we've drawn the same implementation specific conclusions, I've missed this bug report, sorry.

Comment author: meyer

So the way how it's implemented at the moment, is that Options module collect the options. Then Ocaml_specific sets appropriate compilation environment based on that.

The way I'd like to see is to reduce options to bare minimum of options that the compilation doesn't dependent on. Then use is consistently in the API. So Ocaml_specific would add options and flags, but will not run any conditional code. Maybe just making the user aware about tags_with_option is also another good idea which we could consider in the end.

Comment author: meyer

Changed target release to 4.01, especially latest comments are valid, making the flags work with tags nicer.

Comment author: @damiendoligez

ocamlbuild is now a separate project that lives on GitHub.
PR transferred to ocaml/ocamlbuild#161