caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: whitequark <whitequark@whitequark.org>
To: Caml List <caml-list@inria.fr>
Subject: [Caml-list] [ANN] ocamlbuild 0.11.0
Date: Wed, 08 Mar 2017 20:58:47 +0000	[thread overview]
Message-ID: <db65e044adede51f0dd228b5ae3470b8@whitequark.org> (raw)

Hello all,

I'd like to announce the 0.11.0 release of OCamlbuild.

OCamlbuild is a build system with builtin rules to easily build most 
OCaml projects.

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.

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

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

- #125, #160: added "-toolchain" option for corresponding ocamlfind 
option.
   (whitequark)

- #127, #137, #138: install ocamlbuild's man pages, missing since 4.02
   (Adam Sampson and Gabriel Scherer)

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

* #132, #159: 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:

   - <https://github.com/dbuenzli/uucp/pull/9>
   - <https://github.com/dbuenzli/uunf/pull/4>
   - <https://github.com/dbuenzli/uuseg/pull/4>

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

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

- #143-171: migration of Mantis bugtracker issues to the github issue 
tracker
   (Damien Doligez)

- #172-175, #177: setting up Continuous Infrastructure (CI) testsuite 
checks
   (whitequark)

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

- "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 (#132), fixed with the help Daniel Bünzli, Jérémie Dimino
and, in particular, whitequark.

-- 
whitequark

                 reply	other threads:[~2017-03-08 20:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=db65e044adede51f0dd228b5ae3470b8@whitequark.org \
    --to=whitequark@whitequark.org \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).