Fix order of arguments with -cclib XXX

[lefessan]

I think the current processing of arguments in 4.04 is completely broken.
Here is a patch to fix most of the problems:

• no error when providing both a library and a file to compile with -c and -o
• add an error when -c and -o are used on a C file with -o targetting a different name that the one produced by ocamlc
• shared code between main.ml and optmain.ml moved to compenv.ml
  @damiendoligez

[gasche]

It would be easier to review the change if you had separated the factorization of common code, in one commit, and the changes with respect to the current behavior in the other.

(On the other hand, the extra commit with commit message "xxx" could be squashed into one of those two commits.)

I won't have the time to give this a proper review in the following days. @whitequark, do you have any opinion?

I must say that I'm worried by thpse weird C-compilation-related failures that turn up in the 4.04 branch -- if I was the release manager I would consider reverting the whole change from 4.04.

[gasche]

@damiendoligez we discussed this PR (if I understand correctly) but it's not merged yet.

[lefessan]

@gasche @damiendoligez
This PR is ready now. It could be squashed-committed to remove the extra commits.

What do you think ?

[gasche]

I will let Damien review this.

Note: to squash commits as the author of the pull request, you can just do

git checkout <the-pr-branch>
git rebase -i master # assuming the branch is above master
# squash all commits but the first one
git push -f <your-github-remote>

This will update the pull request. We ask external contributors to do this (instead of squashing on our end) because there are many PRs and few mergers so it's better to spend the time on the sender side.

[alainfrisch]

(instead of squashing on our end)

I'm sure you're already aware of it, but GitHub has added a "Confirm squash and merge" mode for merging in its UI (this does not work in case of conflicts, of course). This would work for instance for this PR.

[damiendoligez]

This is a follow-up to #758.

[damiendoligez]

This error message is not good enough... Either describe the condition precisely, or always trigger the error when both -c and -o are given with a C source file.

[damiendoligez]

Except for the error message, this looks good to me. I'm testing it on OPAM packages. I'll add the approved label tomorrow if all goes well.

[damiendoligez]

Can anyone find a better phrasing for the error? If not, let's squash and merge.

[lefessan]

Maybe the error message can be changed later after the merge, if somebody finds something better...

[gasche]

Please see the discussion in ocaml/opam-repository#7369 : I believe that rejecting combined -c and -o options is wrong, as -o can be used to give a location (and in particular its directory) to the output file.

I must say that I'm now a bit confused by the state of -c and -o options in the OCaml compiler.

The code that is present in 0.9.0 and you say is broken was introduced by OCaml upstream change 1d8e590 back in 4.03.0+dev (before ocamlbuild was split), which was supposed to improve ocamlbuild by using -o to set the name of the output file. (Before I think that ocamlc -c foo/bar.c would build bar.o in the current directory instead of foo/bar.o, and there is an explicit mv bar.o foo/bar.o action in OCamlbuild after the ocamlc call.)

This code was reverted (by you in ocaml/ocamlbuild#51) when OCaml upstream reverted 1d8e590 due to compatibility issues in 4.03. But I thought that the change was finally merged in 4.04 ( #464 ), so the code that was reverted (and was present in 0.9.0) should work after #464 was merged.

If I understand correctly, the part that introduces the incompatibility is "add an error when -c and -o are used on a C file with -o targetting a different name that the one produced by ocamlc" in #761. Was this error actually a good idea? Why should we forbid ocamlc -o foo/bar.o -c foo/bar.c?

I think that both

ocamlc -o dir/foo.cmo foo.ml
ocamlc -o dir/foo.o foo.c

ought to work, and I'm sure that was the intent of the original change #464.

[lefessan]

In 4.04.0+beta1, ocamlc -c test.c -o subdir/test.o does not produce subdir/test.o but test.o. So, from that experience, I added an error message if the file provided was not exactly the same as the one that would be produced (because indeed, there are packages that combine -c and -o, but with the correct names).

[xavierleroy]

Something could still be wrong with the way -c/-o options are handled, see the recent MPR#7677.

@lefessan @gasche @damiendoligez : can we try to agree on the intended behavior and make sure it is implemented properly?

[shindere]

Something could still be wrong with the way -c/-o options are handled, see the recent MPR#7677.

@lefessan @gasche @damiendoligez : can we try to agree on the intended behavior and make sure it is implemented properly?

This should be fixed by #9960.