caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: "Emilio Jesús Gallego Arias" <e@x80.org>,
	"Jacques Garrigue" <garrigue@math.nagoya-u.ac.jp>,
	"caml users" <caml-list@inria.fr>
Subject: Re: [Caml-list] LablGtk3 beta1
Date: Fri, 7 Dec 2018 11:25:12 +0100	[thread overview]
Message-ID: <CAPFanBEPqxj29X=bXZf5U+2wAmudXctwn_Kz5A-FncT4+KrqFA@mail.gmail.com> (raw)
In-Reply-To: <87va45odpo.fsf@x80.org>

[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]

> I am not sure I see the advantages of the *-conf solution vs a more
> granular approach [...] where each package has a
> fixed set of system dependencies.

If several OCaml package have system dependencies in common,
(of several versions of the same OCaml package),
indicating depexts per-package duplicate the information. This is what we
were doing before and in practice most package depexts were perpetually
out-of-date.
Some information in the conf-package is rather canonical from system to
system
(such as: the pkg-config name, even though there is still variation
unfortunately),
some is highly system-dependent (the package name in the package manager);
I think it's reasonable to also have the "canonical" information in the
build system.

Also, conf-* packages are very early in the dependency tree, so a pragmatic
advantage
is that they will fail early in the build, typically before you have
installed all the OCaml dependencies
and you start building the package itself.
(Also, depending on the configure/build system, you may geta nice error if
a dependency is missing,
or a crappy compilation failure that can be hard for users to interpret).

> they don't have the *-conf pitfall of having to recompile a lot of
> dependencies when a *-conf package is installed

If you edit a package to update system dependencies, you have the same
recompilation issues.
If you have to recompile *more* in the case of a conf-* package, it is
because it introduced dependency
sharing, which is a good thing -- making the repository more maintainable.


> I find more natural to do `opam install lablgtk2-sourceview2` than
> `opam install conf-gtksourceview lablgtk2`

I don't understand, the point is for lablgtk2-sourceview2 to depend
on conf-gtksourceview2, so you should just use the first command
and the conf-* package(s) will get installed as well.


On Fri, Dec 7, 2018 at 11:04 AM Emilio Jesús Gallego Arias <e@x80.org>
wrote:

> Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> writes:
>
> > There is no opam package yet, because I’m not sure how to do that:
> > I seem to need to add a new conf-gtksourceview3 package too, and I’m not
> > sure how to proceed. Help accepted.
> >
> > Note that this is not the originally planned introspection based port,
> but
> > a manual port of lablgtk2, dropping widgets that are no longer
> > available. It is of course possible to add new widgets if people
> > are willing to contribute.
> >
> > The main goal is to allow application using lablgtksourceview,
> > such as CoqIDE, to compile on top of Gtk-3. Since Gtk-2 itself
> > stays available, lablgtk2 will continue to be supported for other
> > applications.
>
> I am not sure I see the advantages of the *-conf solution vs a more
> granular approach as done here
> https://github.com/garrigue/lablgtk/pull/14, where each package has a
> fixed set of system dependencies.
>
> AFAICT `depext` fields can be added to the custom packages just fine,
> and they don't have the *-conf pitfall of having to recompile a lot of
> dependencies when a *-conf package is installed.
>
> I find more natural to do `opam install lablgtk2-sourceview2` than
> `opam install conf-gtksourceview lablgtk2`
>
> E.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> https://inbox.ocaml.org/caml-list
> Forum: https://discuss.ocaml.org/
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 4742 bytes --]

  reply	other threads:[~2018-12-07 10:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06  6:33 Jacques Garrigue
2018-12-06 10:05 ` Louis Gesbert
2018-12-06 10:35 ` Gabriel Scherer
2018-12-07 10:04 ` Emilio Jesús Gallego Arias
2018-12-07 10:25   ` Gabriel Scherer [this message]
2018-12-07 18:34     ` Emilio Jesús Gallego Arias
2018-12-11  3:09       ` Francois Berenger
2018-12-11 11:34         ` Louis Gesbert
2018-12-14 11:41           ` Emilio Jesús Gallego Arias
2018-12-14 11:38         ` Emilio Jesús Gallego Arias
2018-12-16  8:12           ` Jacques Garrigue
2018-12-17 12:11             ` Emilio Jesús Gallego Arias
2018-12-18 14:33               ` David Allsopp
2018-12-19  1:20                 ` Emilio Jesús Gallego Arias
2018-12-19 10:15                   ` David Allsopp
2018-12-19 11:13                     ` Emilio Jesús Gallego Arias
2018-12-19 11:50                       ` David Allsopp
2018-12-19 16:41                         ` Emilio Jesús Gallego Arias
2018-12-20 11:33                           ` David Allsopp

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='CAPFanBEPqxj29X=bXZf5U+2wAmudXctwn_Kz5A-FncT4+KrqFA@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=e@x80.org \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /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).