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

the pack action must also pass package(...) options to ocamlfind #272

Closed
gasche opened this issue Mar 26, 2018 · 0 comments
Closed

the pack action must also pass package(...) options to ocamlfind #272

gasche opened this issue Mar 26, 2018 · 0 comments

Comments

@gasche
Copy link
Member

gasche commented Mar 26, 2018

A build failure of nocrypto comes down to the fact that ocamlbuild does not forward -package setting in pack actions, which somehow(?) results in the typer creating subtly-incompatible inferred interfaces for the generated .cmi file. See the diagnosis by @diml in ocaml/opam-repository#11628 (comment).

This is an ocamlbuild bug and I'm creating this issue to track a fix.

gasche added a commit to gasche/ocamlbuild that referenced this issue Mar 26, 2018
Instead of a separate category, "pack" is now another form of linking
like "program", "library", "toplevel" and "output_obj". This fixes the
issue that package(...) tags where not passed at pack-production time,
spotted by Jérémie Dimino in
  <ocaml/opam-repository#11628 (comment)>
  <janestreet/ppx_sexp_conv#20>
More generally, this extends the meaning of all "link" flags to
"pack", which seems to be the correct behavior for all the rules we
inspected.

I tested that this change fixes the original 'nocrypto' issue
(once their _tags is also fixed to provide the right package(..)
option at pack-time).

This is a somewhat invasive change to the behavior of "pack" and
"link" tags, which may affect all user-defined flag declarations. An
alternative to this change would be to just add a specific "package"
rule when the "pack" tag is present, but my understanding is that
linking options quite generally apply to "pack" productions
(that really behave mostly like library-archive production already
under the ("link";"library") regime), so this more invasive change is
more correct: the extra cases where it applies were likely to be small
bugs before.

(I checked that ocb-stubblr is orthogonal to this change and does not
need any update.)
@gasche gasche closed this as completed in 9cb08c6 Apr 6, 2018
gasche added a commit that referenced this issue Apr 6, 2018
add the "link" tag to "pack" actions (fixes #272)
@gasche gasche mentioned this issue Sep 8, 2018
gasche added a commit to gasche/opam-repository that referenced this issue Sep 8, 2018
OCamlbuild 0.13.0 contains new features (`ppopt(..)` and `ppxopt(...)` flags,
ocamlbuild options) and bugfixes (to pack production, for 4.08+dev support).

- ocaml/ocamlbuild#45, ocaml/ocamlbuild#190: add ppopt(arg) and ppxopt(package,arg) when -use-ocamlfind
  (Gabriel Scherer, review by whitequark,
   request by Gabriel Scherer, Gabriel Radanne and Pavel Argentov)

- ocaml/ocamlbuild#268, ocaml/ocamlbuild#269: add flag support for some ocamlmklib options:
  custom, debug, failsafe, linkall, ccopt(..), cclib(..), rpath(..), ldopt(..)
  (Gabriel Scherer, report by Hannes Mehnert, review by whitequark)

* ocaml/ocamlbuild#272: add the "link" tag to "pack" actions
  Instead of a separate category, "pack" is now another form of linking
  like "program", "library", "toplevel" and "output_obj". This fixes
  the issue that package(...) tags where not passed at pack-production
  time, spotted by Jérémie Dimino. More generally, this extends
  the meaning of all "link" flags to "pack", which seems to be the correct
  behavior for all the rules we inspected.
  (Gabriel Scherer, original issue diagnosis by Jérémie Dimino)

- ocaml/ocamlbuild#278: typo fixes in the manual
  (Xinzhe Yang)

- ocaml/ocamlbuild#282: fix compilation with trunk OCaml (4.08+dev)
  (Xavier Clerc and Nandor Licker)
gasche added a commit to gasche/ocamlbuild that referenced this issue Sep 14, 2018
Making pack a "link" sub-mode (instead of its own mode) in ocaml#272
creates a regression for packages (eg. webidl.1.4) using
"true: linkpkg" in its tag file: this causes ocamlfind to pass .cma
archives to link (from package(...)) during pack creation, which is
rejected by the compiler.

The issue was noticed by Andreas Hauptmann in opam-repository CI logs

  https://ci.ocamllabs.io/log/saved/docker-run-af7d9f4b635e5949f2984b87fb1467ef/c4298e0875728ebbc7d36ed691591db38d7c1095
@gasche gasche mentioned this issue Sep 14, 2018
gasche added a commit to gasche/ocamlbuild that referenced this issue Sep 14, 2018
Making pack a "link" sub-mode (instead of its own mode) in ocaml#272
creates a regression for packages (eg. webidl.1.4) using
"true: linkpkg" in its tag file: this causes ocamlfind to pass .cma
archives to link (from package(...)) during pack creation, which is
rejected by the compiler.

The issue was noticed by Andreas Hauptmann in opam-repository CI logs

  https://ci.ocamllabs.io/log/saved/docker-run-af7d9f4b635e5949f2984b87fb1467ef/c4298e0875728ebbc7d36ed691591db38d7c1095
gasche added a commit to gasche/opam-repository that referenced this issue Sep 14, 2018
This bugfix release attempts to fix a regression due to the change in
"pack" handling in 0.13.0. It is not clear whether the regression
should be considered a bug in 0.13.0 or an incorrect _tags file in the
broken package, but we prefer to fix it anyway.

- ocaml/ocamlbuild#287: change "linkpkg" flag definition to not apply in the
  new "pack"++"link" mode introduced by ocaml/ocamlbuild#272. This avoids
  a build failure in webidl.1.4 and possibly other packages
  using "true: linkpkg".
  (Gabriel Scherer, report by Andreas Hauptmann)
gasche added a commit to gasche/opam-repository that referenced this issue Sep 14, 2018
OCamlbuild 0.13.0 contains new features (`ppopt(..)` and `ppxopt(...)` flags,
ocamlbuild options) and bugfixes (to pack production, for 4.08+dev support).

- ocaml/ocamlbuild#45, ocaml/ocamlbuild#190: add ppopt(arg) and ppxopt(package,arg) when -use-ocamlfind
  (Gabriel Scherer, review by whitequark,
   request by Gabriel Scherer, Gabriel Radanne and Pavel Argentov)

- ocaml/ocamlbuild#268, ocaml/ocamlbuild#269: add flag support for some ocamlmklib options:
  custom, debug, failsafe, linkall, ccopt(..), cclib(..), rpath(..), ldopt(..)
  (Gabriel Scherer, report by Hannes Mehnert, review by whitequark)

* ocaml/ocamlbuild#272: add the "link" tag to "pack" actions
  Instead of a separate category, "pack" is now another form of linking
  like "program", "library", "toplevel" and "output_obj". This fixes
  the issue that package(...) tags where not passed at pack-production
  time, spotted by Jérémie Dimino. More generally, this extends
  the meaning of all "link" flags to "pack", which seems to be the correct
  behavior for all the rules we inspected.
  (Gabriel Scherer, original issue diagnosis by Jérémie Dimino)

- ocaml/ocamlbuild#278: typo fixes in the manual
  (Xinzhe Yang)

- ocaml/ocamlbuild#282: fix compilation with trunk OCaml (4.08+dev)
  (Xavier Clerc and Nandor Licker)
gasche added a commit to gasche/opam-repository that referenced this issue Sep 14, 2018
This bugfix release attempts to fix a regression due to the change in
"pack" handling in 0.13.0. It is not clear whether the regression
should be considered a bug in 0.13.0 or an incorrect _tags file in the
broken package, but we prefer to fix it anyway.

- ocaml/ocamlbuild#287: change "linkpkg" flag definition to not apply in the
  new "pack"++"link" mode introduced by ocaml/ocamlbuild#272. This avoids
  a build failure in webidl.1.4 and possibly other packages
  using "true: linkpkg".
  (Gabriel Scherer, report by Andreas Hauptmann)
gasche added a commit to gasche/ocamlbuild that referenced this issue Feb 22, 2019
gasche added a commit to gasche/ocamlbuild that referenced this issue Feb 22, 2019
gasche added a commit to gasche/ocamlbuild that referenced this issue Feb 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant