From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Thomas Gazagnaire <thomas@gazagnaire.org>
Cc: "Daniel Bünzli" <daniel.buenzli@erratique.ch>,
platform <platform@lists.ocaml.org>,
"OCaml List" <caml-list@inria.fr>
Subject: Re: [Caml-list] [ocaml-platform] Package compilation and debug mode
Date: Wed, 23 Mar 2016 11:12:50 +0100 [thread overview]
Message-ID: <CAPFanBFVZ45oKswNq-Zd+gzRN6n_KHv50Wjp0u=PTyJnFVdrXw@mail.gmail.com> (raw)
In-Reply-To: <FB914EF9-EE47-4A68-9C83-9746E2EB479B@gazagnaire.org>
The new (4.03)
ocaml_compiler_internal_params
mechanism might be of use here:
OCAMLPARAM option passed using a configuration file
https://github.com/ocaml/ocaml/pull/428
Note that as a software packager I would be fine fetching a %{debug}%
variable and adapt my configure/build chain to handle it. I already
have specific logic for ocaml-native and ocaml-native-tools. But I
wonder whether this approach scales to other preferences one may want
to set globally. (OCAMLPARAM is a kludge, but duplicating it inside
OPAM may not be much better.)
On Wed, Mar 23, 2016 at 11:02 AM, Thomas Gazagnaire
<thomas@gazagnaire.org> wrote:
>> By default all my packages are released with -g disabled. It seems easy enough to have an opam switch (even the official one) that automatically enables the flag.
>
> How do you envision such a global debug flag? As far as I know, there is no configuration-time option to enable that option in the compiler (which would be the cleaner option IMHO). I'd rather avoid using OCAMLPARAM for this. A new opam variable can be created and used in the opam file to pass the debug command (or not) explicitly to the build system, but this will require adapting all the build systems (and ideally a new release of opam, but we can work-around that by setting OPAMVAR_debug in the .comp file).
>
>> So I think OCaml's opam repository should have a policy here. The answer should also take system package managers into account since those pull directly from the tarballs (if this document [3] is still in use for debian it seems they do require compilation with debug mode).
>>
>> Personally I don't have an opinion about it, I'm rather seeking an answer here.
>
> I don't have a strong opinion either. I like when packages come with -g by default, but I can understand that the (small) runtime cost can be a problem for deployment scenarios.
>
> Thomas
> _______________________________________________
> Platform mailing list
> Platform@lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
next prev parent reply other threads:[~2016-03-23 10:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-12 21:35 [Caml-list] " Daniel Bünzli
2016-03-13 19:16 ` Ivan Gotovchits
2016-03-14 7:19 ` Mark Shinwell
2016-03-14 8:14 ` whitequark
2016-03-14 8:24 ` Mark Shinwell
2016-03-23 9:43 ` Daniel Bünzli
2016-03-23 10:02 ` Thomas Gazagnaire
2016-03-23 10:12 ` Gabriel Scherer [this message]
2016-03-23 10:23 ` Daniel Bünzli
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='CAPFanBFVZ45oKswNq-Zd+gzRN6n_KHv50Wjp0u=PTyJnFVdrXw@mail.gmail.com' \
--to=gabriel.scherer@gmail.com \
--cc=caml-list@inria.fr \
--cc=daniel.buenzli@erratique.ch \
--cc=platform@lists.ocaml.org \
--cc=thomas@gazagnaire.org \
/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).