caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Anil Madhavapeddy <anil@recoil.org>
To: Olaf Hering <olaf@aepfle.de>
Cc: Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>,
	Hongbo Zhang <hzhang295@bloomberg.net>,
	yminsky@janestreet.com, caml-list@inria.fr
Subject: Re: [Caml-list] PPX is harmful to our community in the long term
Date: Fri, 28 Apr 2017 14:04:22 +0100	[thread overview]
Message-ID: <05BE6A9C-9AFB-4AD2-B577-23F4B88B86B3@recoil.org> (raw)
In-Reply-To: <20170428110718.GB13305@aepfle.de>

On 28 Apr 2017, at 12:07, Olaf Hering <olaf@aepfle.de> wrote:
> 
> On Fri, Apr 21, Fabrice Le Fessant wrote:
> 
>> A lot of people use `autoconf` to generate `./configure` scripts, and the
>> standard practice is to keep the `./configure` script so that people don't need
>> to run `autoconf` to just compile and install the software. Maybe projects
> 
> This is and was a huge mistake to promote 'configure&&make' instead of
> autogen.sh&&configure&&make. Having a set of uptodate autotools
> installed is easy and cheap, they are not runtime dependencies. The
> result of that wrongdoing is a huge pile of broken and/or incomplete configure.ac.

Indeed -- we spent years in OpenBSD dealing with patching broken versions
of libtool scripts that embedded incorrect behaviour on our particular platforms,
and were stubbornly included in upstream distributions without being regenerated.

> Do not repeat that mistake, whatever it means in the OCaml world.

A similar analogue in the OCaml world may be the inclusion of autogenerated
files from _oasis.  The inclusion of the autogenerated files like myocamlbuild.ml
was a holdover from a pre-opam world when it was painful to install all the
build dependencies of OASIS.

Nowadays, it's quite easy to install oasis and run `oasis setup` in a project
to get the latest build rules, and the checked in autogenerated files only
get in the way and/or are increasingly complex due to having to deal with
multiple OCaml versions (e.g. for String.lowercase vs String.lowercase_ascii).

Bundling pre-evaluated ppx output in a release tarball runs the same risk...

Our experience in Mirage with PPX has been to find a balance -- we do not let
it proliferate beyond type_conv usage or ppx_cstruct for binary formats.  Some
libraries (such as the TLS stack) do not use it all. One of the heaviest uses
of camlp4 in the past for us was the pa_lwt syntax extension, and most libraries
have gone towards explicit Lwt.bind() calls instead of using the ppx alternative.

I'm hopeful that ocaml-migrate-parsetree will make it easier for us to test
common libraries on dev versions of OCaml.  In practise with 4.05, it has been
non-ppx changes that have been blocking testing -- for instance the close-on-exec
flag addition to the Unix module caused rippling breakage through Lwt and other
platform libraries.  That's not to say that PPX isn't a problem, but it has
gotten significantly easier to deal with since Fred's work on migrate-parsetree.

regards,
Anil


  reply	other threads:[~2017-04-28 13:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 19:23 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-21 21:17 ` Fabrice Le Fessant
2017-04-28 11:07   ` Olaf Hering
2017-04-28 13:04     ` Anil Madhavapeddy [this message]
2017-04-28 14:50       ` Yaron Minsky
2017-04-28 14:55         ` Jacques Carette
2017-05-11  9:37           ` Jeremie Dimino
  -- strict thread matches above, loose matches on Subject: below --
2017-04-23  0:06 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-23  1:25 ` Yaron Minsky
2017-04-22 14:47 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-22 19:47 ` Robert Muller
2017-04-23  1:30   ` Yaron Minsky
2017-04-21 21:48 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-21 23:10 ` Emilio Jesús Gallego Arias
2017-04-22 12:49   ` Serge Sivkov
2017-04-21 15:41 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-21 16:04 ` Yotam Barnoy
2017-04-21 16:43   ` Gerd Stolpmann
2017-04-21 17:11   ` Alain Frisch
2017-04-21 18:28     ` Jeremie Dimino
2017-04-21 16:55 ` Francois BERENGER
2017-04-21 19:11 ` Yaron Minsky
2017-04-21 19:22 ` Emilio Jesús Gallego Arias

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=05BE6A9C-9AFB-4AD2-B577-23F4B88B86B3@recoil.org \
    --to=anil@recoil.org \
    --cc=Fabrice.Le_fessant@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=hzhang295@bloomberg.net \
    --cc=olaf@aepfle.de \
    --cc=yminsky@janestreet.com \
    /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).