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

Fix build of uuseg.cmxs #4

Closed
wants to merge 1 commit into from
Closed

Conversation

vouillon
Copy link

@vouillon vouillon commented Dec 1, 2016

File uuseg.mldylib is needed for that. Otherwise, only uuseg.cmx is included in the library.

@dbuenzli
Copy link
Owner

dbuenzli commented Dec 1, 2016

This duplication is a bit annoying. @gasche can't we have a rule that produces a .cmxs from an .mllib ?

@dbuenzli
Copy link
Owner

dbuenzli commented Dec 1, 2016

See also
dbuenzli/uucp#9
dbuenzli/uunf#4

@gasche
Copy link

gasche commented Dec 1, 2016

The difference between "what we obviously want" for .cmxa and .cmxs file (exemplified in the difference between the .cmx -> .cxma rule, which pulls the local dependencies of the module as well, and the .cmx -> .cmxs rule which doesn't) makes me a bit wary of this kind of change. For example it's not clear what would be the interaction with the proposal to infer .mllib and .mldylib files (with the difference of behavior listed above) directly from .ml files -- MPR#5185: if I understand correctly the two paths .ml -> .mllib -> .cmxs and .ml -> .mldylib -> .cmxs would disagree with each other.

Note that if you want to avoid duplication you could also use a copy_rule call in your myocamlbuild.ml. I have been toying with the idea of a generic %.copy -> % rule (foo.copy would contain a path whose content should be copied to build foo), but I'm not sure what the implication on the solver would be and whether users would like that better: on the plus side, if you are on the mindset that users never want to look at myocamlbuild.ml, you hide less logic from them, on the minus side you have more noise in your directory.

@dbuenzli
Copy link
Owner

dbuenzli commented Dec 1, 2016

(exemplified in the difference between the .cmx -> .cxma rule, which pulls the local dependencies of the module as well, and the .cmx -> .cmxs rule which doesn't)

TBH I don't understand the rationale behind this (see https://caml.inria.fr/mantis/view.php?id=5208). In that discussion I was told that I should write .mllib files to be precise.

Now to me it seems pretty clear when you define a library explicitly (i.e. list its compilation units via a .mllib file) you want the same objects in the static archive and in the dynamic linkable one.

The chances of a file like https://github.com/dbuenzli/uucp/pull/9/files#diff-f7fdbf82d60063b7cba841f2a46292cf to disagree with the .mllib when you evolve the code base is just ridiculously high and the amount of non-dryness of that system just makes me cry.

@gasche
Copy link

gasche commented Dec 1, 2016

Now to me it seems pretty clear when you define a library explicitly (i.e. list its compilation units via a .mllib file) you want the same objects in the static archive and in the dynamic linkable one.

This is a very good point. Could you create an ocamlbuild issue to track the feature request? (Would you specify what you think should be done when both a .mldylib and .mllib can be built? Give priority to the .mldylib rule, I assume?)

@gasche
Copy link

gasche commented Dec 1, 2016

The feature was implemented by @Armael in ocaml/ocamlbuild#132. It should be part of the next ocamlbuild release.

@dbuenzli
Copy link
Owner

Should be solved in the next version of ocamlbuild see ocaml/ocamlbuild#131.

@dbuenzli dbuenzli closed this Dec 23, 2016
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Jul 11, 2017
0.11.0 (5 Mar 2017):
--------------------

OCamlbuild 0.11.0 introduces a change to the way `.cmxs` files are
produced when no `.mldylib` file is absent: it will now use the exact
same semantics as `.cmxa` and `.mllib` file -- in particular, it
should not be necessary anymore to have identical
`foo.{mllib,mldylib}` files, only `foo.mllib` should suffice. See the
detailed changelog below for details.

- added "nostdlib" flag for corresponding ocaml{c,opt} options
  (Thomas Wood)

- add `node_modules` to the list of directories ignored by default
  (.svn/, CVS/, .bzr/, .hg/, .git/, _darcs/, node_modules/)
  (Yunxing Dai)

- added "-toolchain" option for corresponding ocamlfind option.
  (whitequark)

- install ocamlbuild's man pages, missing since 4.02
  (Adam Sampson and Gabriel Scherer)

- make sure that -just-plugin always stops after the plugin-build phase
  (Gabriel Scherer, report by whitequark)

* remove the rule ".cmx -> .cmxs"
  Previously, there was a ".cmx -> .cmxa" rule that would
  pull a module and its dependencies in a .cmxa, and a separate
  ".cmx -> .cmxs" rule that would pull only a module as a .cmxs.

  The latter is a reasonable default choice, the idea being that
  a module's dependencies may often be statically linked with the
  program instead of being dynamically linked. But it conflicts with
  the presence of a rule ".cmxa -> .cmxs" as soon as the library has
  the same name as one of the modules it contains.

  The reason why the rule ".cmxa -> .cmxs" matter is that it can be
  composed with the rule ".mllib -> .cmxa" to build .cmxs files from
  .mllib files, without having to copy each .mllib file into
  a separate .mldylib file.

  In other terms, the previous behaviour would, by default (in absence
  of .mldylib file who always takes priority), only link the module in
  the .cmxs file, and people wishing otherwise would have to write
  a list of modules in a .mldylib file. The new behavior will, by
  default, take the .mllib file or the module dependencies (as for
  .cmxa) to build a .cmxs file, and people wishing otherwise will have
  to write just the module name in a .mldylib file.

  It is unclear whether this change will break some projects on which
  users relied on the previous semantics. It seems equally likely that
  the previous semantics, when it applied, was a source of bugs
  (the .cmxs files didn't have the expected modules) that would not be
  discovered by people not testing dynamic linking. Such bugs have
  been found and fixed in the following cases:

  - <dbuenzli/uucp#9>
  - <dbuenzli/uunf#4>
  - <dbuenzli/uuseg#4>

  (Daniel Bünzli, Jérémie Dimino, Armaël Guéneau, Gabriel Scherer, whitequark)

- do not explicitly pass -shared when building shared libraries;
  let the compiler decide what to build.
  (whitequark)

- migration of Mantis bugtracker issues to the github issue tracker
  (Damien Doligez)

- setting up Continuous Infrastructure (CI) testsuite checks
  (whitequark)

- install license, changes and readme in opam's docdir for `odig`
  (Gabriel Scherer, request and review by Daniel Bünzli)

* new heuristic for handling the OCAMLLIB environment variable.
  `ocamlbuild -where` will ignore OCAMLLIB completely if OCAMLBUILD_LIBDIR is
  not a lexical subdirectory of OCAML_LIBDIR (i.e. an opam installation).
  Otherwise, it now returns $OCAMLLIB with the difference between
  OCAMLBUILD_LIBDIR and OCAML_LIBDIR appended (i.e. for a normal findlib
  installation, it now returns $OCAMLLIB/site-lib/ocamlbuild)
  (David Allsopp, review by Gabriel Schere)

- "noautolink" tag for ocaml{c,opt}
  (Gabriel Scherer)

0.10.{0,1} (Dec 2016):
----------------------

These releases were never widely distributed, because of
a quickly-caught regression due to the change of .cmxs compilation
behavior, fixed with the help Daniel Bünzli, Jérémie Dimino
and, in particular, whitequark.

0.9.3 (6 Oct 2016):
-------------------

OCamlbuild 0.9.3 introduces several features contributed or requested
by our users. See the detailed changelog below.

- new ".o -> .clib" rule to build libraries out of single C stubs
  (Gabriel Scherer, request by whitequark)

- Integrate the in-progress OCamlbuild manual, previously located at
    https://github.com/gasche/manual-ocamlbuild
  into the ocamlbuild repository, in the manual/ subdirectory.
  The most current version of the manual can thus be accessed at
    https://github.com/ocaml/ocamlbuild/tree/master/manual/manual.adoc
  (Gabriel Scherer)

- added "noassert" and "unsafe" flag for corresponding ocaml{c,opt} options
  (François Pottier)

- added "cc", "cclib", and "ccopt" flags which correspond to the
  respective ocaml{c,opt} options
  (Rudi Grinberg)

- add infer_interface support for various type-checking-time flags:
    color, keep_docs, no_alias_deps, nolabels, nopervasives, open,
    strict_formats, strict_sequence, warn, warn_error
  (Gabriel Scherer, report by Knuth Posern)
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

Successfully merging this pull request may close these issues.

None yet

3 participants