caml-list - the Caml user's mailing list
 help / Atom feed
* [Caml-list] LablGtk3 beta1
@ 2018-12-06  6:33 Jacques Garrigue
  2018-12-06 10:19 ` Louis Gesbert
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Jacques Garrigue @ 2018-12-06  6:33 UTC (permalink / raw)
  To: Mailing List OCaml

Dear LablGtk users,

Due to the planned deprecation of gtksourceview2 in Debian,
we have been working on a stripped down port of LablGtk2 to Gtk-3.

A first beta is available for download at the usual location:
	http://lablgtk.forge.ocamlcore.org
	https://forge.ocamlcore.org/frs/download.php/1769/lablgtk-3.0.beta1.tar.gz

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.

The code is in the lablgtk3 branch:
	https://github.com/garrigue/lablgtk/tree/lablgtk3
There is an ongoing discussion
	https://github.com/garrigue/lablgtk/issues/2

The current status is that a modified version of CoqIDE compiles
and runs.

Please report issues on GitHub.

Jacques Garrigue

-- 
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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
@ 2018-12-06 10:19 ` Louis Gesbert
  2018-12-06 10:40 ` Gabriel Scherer
  2018-12-07 10:04 ` Emilio Jesús Gallego Arias
  2 siblings, 0 replies; 11+ messages in thread
From: Louis Gesbert @ 2018-12-06 10:19 UTC (permalink / raw)
  To: caml-list, Jacques Garrigue

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

Hi Jacques,

I'll try to package your branch in a `lablgtk3` opam package, and see if I can run some tests. Thanks for the port!

Louis Gesbert — OCamlPro

> - Jacques Garrigue, 06/12/2018 15:33 -
> Dear LablGtk users,
> 
> Due to the planned deprecation of gtksourceview2 in Debian,
> we have been working on a stripped down port of LablGtk2 to Gtk-3.
> 
> A first beta is available for download at the usual location:
> 	http://lablgtk.forge.ocamlcore.org
> 	https://forge.ocamlcore.org/frs/download.php/1769/lablgtk-3.0.beta1.tar.gz
> 
> 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.
> 
> The code is in the lablgtk3 branch:
> 	https://github.com/garrigue/lablgtk/tree/lablgtk3
> There is an ongoing discussion
> 	https://github.com/garrigue/lablgtk/issues/2
> 
> The current status is that a modified version of CoqIDE compiles
> and runs.
> 
> Please report issues on GitHub.
> 
> Jacques Garrigue
> 
> 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
  2018-12-06 10:19 ` Louis Gesbert
@ 2018-12-06 10:40 ` Gabriel Scherer
  2018-12-07 10:04 ` Emilio Jesús Gallego Arias
  2 siblings, 0 replies; 11+ messages in thread
From: Gabriel Scherer @ 2018-12-06 10:40 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: caml users

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

> 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.

The point of conf-* packages is to centralize the logic to check for an
outside-opam dependency (that must be provided by the operating system); if
an installation task fails on a conf-* target, the user should know that
the problem is not their OCaml environment, but a system dependency to
install. Each conf-* package implements its own
external-dependency-detection logic; some packages call pkg-config to check
that a library exist, or even try to build a dummy C program with the
library, but the least they can be expected to do is to check for a list of
"depexts", system packages (one for each distribution / OS package manager)
that contain the dependency.

For conf-gtksourceview3, you should aim to do no worse than
conf-gtksourceview2. The source fo that package can be looked in the
current opam-repository:

https://github.com/ocaml/opam-repository/blob/master/packages/conf-gtksourceview/conf-gtksourceview.2/opam

You can see in the source that it lists some depexts, and also performs a
pkg-config test in its `build` rule.

It should be very easy to port that package into a conf-gtksourceview3
package, replacing what needs to be replaced:
- are the licence and homepage the same?
- what is the name of the pkg-config argument you should pass?
  (I just checked, it is "gtksourceview-3.0")
- what are the name for the gtk3 versions of the system packages?
  You can search the web to find the name of a package for a given
distribution,
  and the links to do this are listed in
    https://github.com/ocaml/opam-depext/blob/master/README.md



On Thu, Dec 6, 2018 at 7:33 AM Jacques Garrigue <
garrigue@math.nagoya-u.ac.jp> wrote:

> Dear LablGtk users,
>
> Due to the planned deprecation of gtksourceview2 in Debian,
> we have been working on a stripped down port of LablGtk2 to Gtk-3.
>
> A first beta is available for download at the usual location:
>         http://lablgtk.forge.ocamlcore.org
>
> https://forge.ocamlcore.org/frs/download.php/1769/lablgtk-3.0.beta1.tar.gz
>
> 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.
>
> The code is in the lablgtk3 branch:
>         https://github.com/garrigue/lablgtk/tree/lablgtk3
> There is an ongoing discussion
>         https://github.com/garrigue/lablgtk/issues/2
>
> The current status is that a modified version of CoqIDE compiles
> and runs.
>
> Please report issues on GitHub.
>
> Jacques Garrigue
>
> --
> 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: 5040 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
  2018-12-06 10:19 ` Louis Gesbert
  2018-12-06 10:40 ` Gabriel Scherer
@ 2018-12-07 10:04 ` Emilio Jesús Gallego Arias
  2018-12-07 10:15   ` Gabriel Scherer
  2 siblings, 1 reply; 11+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-07 10:04 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: Mailing List OCaml

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-07 10:04 ` Emilio Jesús Gallego Arias
@ 2018-12-07 10:15   ` Gabriel Scherer
  2018-12-07 18:35     ` Emilio Jesús Gallego Arias
  0 siblings, 1 reply; 11+ messages in thread
From: Gabriel Scherer @ 2018-12-07 10:15 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias, Jacques Garrigue, caml users

[-- 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 --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-07 10:15   ` Gabriel Scherer
@ 2018-12-07 18:35     ` Emilio Jesús Gallego Arias
  2018-12-11  3:09       ` Francois Berenger
  0 siblings, 1 reply; 11+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-07 18:35 UTC (permalink / raw)
  To: Gabriel Scherer; +Cc: Jacques Garrigue, caml users

Hi Gabriel,

Gabriel Scherer <gabriel.scherer@gmail.com> writes:

> 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.

Umm, indeed that may make sense very widely used packages, such as `m4`,
etc... I am not sure this makes sense for gtk tho; right now we have:

lablgtk2.opam
lablgtk2-glade.opam
lablgtk2-gnomecanvas.opam
lablgtk2-gspell.opam
lablgtk2-rsvg.opam
lablgtk2-gl.opam
lablgtk2-gnome.opam
lablgtk2-sourceview2.opam

so adding so many conf- packages seems like a nuisance. Also it is
harder for consumers of the library to depend on the right packages;
this is the reason Debian uses this scheme:

liblablgtkmathview-ocaml-dev
liblabltk-ocaml-dev
liblablgl-ocaml-dev
liblablgtk2-gnome-ocaml-dev
liblablgtk-extras-ocaml-dev
liblablgtksourceview2-ocaml-dev
liblablgtk2-gl-ocaml-dev
liblablgtk2-ocaml-dev

I much prefer to depend on `lablgtk-sourceview` than on `lablgtk` and
`conf-gtksourceview`; not to say the issue with the side effects [see
below]

> 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).

In this case the error messages are the same I think. I am not sure the
"early in the build tree" is so important tho.

> 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.

The thing is that I am coming from a world (Debian) were package builds
are required to be deterministic; what does editing a package to update
system dependencies mean? How is the repository going to be more
maintainable?

For example, in this case, installing `conf-gl` will force the
recompilation of `lablgtk`, and `conf-gl` could be pulled by an
unrelated package.

It seems very wrong to me that this sharing will actually force a
side-effect on a unrelated package.

IMVHO this is very non-standard behavior that I've only seen in OPAM and
makes things less maintenable indeed, for example if you want to have
Debian packages.

> 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.

I could do that, but what is the point on shipping a fake, empty package
then? `lablgtk2-sourceview2` can handle the dependencies just fine.

An even worse problem is this case: imagine package A and B both depend
on gtksourceview, however package A requires version > 2.10 and package
B version > 2.11.

How can the sharing possibly work here?

Cheers!
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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-07 18:35     ` Emilio Jesús Gallego Arias
@ 2018-12-11  3:09       ` Francois Berenger
  2018-12-11 11:40         ` Louis Gesbert
  2018-12-14 11:38         ` Emilio Jesús Gallego Arias
  0 siblings, 2 replies; 11+ messages in thread
From: Francois Berenger @ 2018-12-11  3:09 UTC (permalink / raw)
  To: caml users; +Cc: caml-list-request

On 08/12/2018 03:34, Emilio Jesús Gallego Arias wrote:
> Hi Gabriel,
> 
> Gabriel Scherer <gabriel.scherer@gmail.com> writes:
> 
>> 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.
> 
> Umm, indeed that may make sense very widely used packages, such as 
> `m4`,
> etc... I am not sure this makes sense for gtk tho; right now we have:
> 
> lablgtk2.opam
> lablgtk2-glade.opam
> lablgtk2-gnomecanvas.opam
> lablgtk2-gspell.opam
> lablgtk2-rsvg.opam
> lablgtk2-gl.opam
> lablgtk2-gnome.opam
> lablgtk2-sourceview2.opam
> 
> so adding so many conf- packages seems like a nuisance. Also it is
> harder for consumers of the library to depend on the right packages;
> this is the reason Debian uses this scheme:
> 
> liblablgtkmathview-ocaml-dev
> liblabltk-ocaml-dev
> liblablgl-ocaml-dev
> liblablgtk2-gnome-ocaml-dev
> liblablgtk-extras-ocaml-dev
> liblablgtksourceview2-ocaml-dev
> liblablgtk2-gl-ocaml-dev
> liblablgtk2-ocaml-dev
> 
> I much prefer to depend on `lablgtk-sourceview` than on `lablgtk` and
> `conf-gtksourceview`; not to say the issue with the side effects [see
> below]
> 
>> 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).
> 
> In this case the error messages are the same I think. I am not sure the
> "early in the build tree" is so important tho.
> 
>> 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.
> 
> The thing is that I am coming from a world (Debian) were package builds
> are required to be deterministic; what does editing a package to update
> system dependencies mean? How is the repository going to be more
> maintainable?
> 
> For example, in this case, installing `conf-gl` will force the
> recompilation of `lablgtk`, and `conf-gl` could be pulled by an
> unrelated package.
> 
> It seems very wrong to me that this sharing will actually force a
> side-effect on a unrelated package.
> 
> IMVHO this is very non-standard behavior that I've only seen in OPAM 
> and
> makes things less maintenable indeed, for example if you want to have
> Debian packages.
> 
>> 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.
> 
> I could do that, but what is the point on shipping a fake, empty 
> package
> then? `lablgtk2-sourceview2` can handle the dependencies just fine.
> 
> An even worse problem is this case: imagine package A and B both depend
> on gtksourceview, however package A requires version > 2.10 and package
> B version > 2.11.

Oh, this one is an interesting question!

You are suggesting that opam should support the installation of 
different versions of the same thing.
I think nix can do that, and that indeed looks like a current limitation 
of opam.

Regards,
F.


-- 
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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-11  3:09       ` Francois Berenger
@ 2018-12-11 11:40         ` Louis Gesbert
  2018-12-14 11:41           ` Emilio Jesús Gallego Arias
  2018-12-14 11:38         ` Emilio Jesús Gallego Arias
  1 sibling, 1 reply; 11+ messages in thread
From: Louis Gesbert @ 2018-12-11 11:40 UTC (permalink / raw)
  To: caml-list, Francois Berenger; +Cc: caml-list-request

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

> > An even worse problem is this case: imagine package A and B both depend
> > on gtksourceview, however package A requires version > 2.10 and package
> > B version > 2.11.
> 
> Oh, this one is an interesting question!
> 
> You are suggesting that opam should support the installation of 
> different versions of the same thing.
> I think nix can do that, and that indeed looks like a current limitation 
> of opam.

It is a limitation that has been explicitely put into opam, because of what the rest of the tooling requires. I made a more detailed explanation here: https://github.com/ocaml/opam/issues/3696

I don't believe that's what was suggested in the original message, though ? The pointed issue seemed to me that we don't handle detailed versions for `conf-*` packages, which means we can't encode precise dependencies to the underlying system package versions. In other words, _handling_ the fact that "package A requires version > 2.10 and package B version > 2.11" is no problem at all for opam, but _expressing_ it is, for `conf-*` packages.

The thing is that we can only detect the installed versions of system packages, not control them (even with `opam-depext`, we can trigger the installation of a given package, but most distributions don't allow to choose between multiple versions). In this case, you will have to rely on your package's `./configure` to fail when the version of the system dependency doesn't match, which is not the most helpful solution; adding the depexts to the package directly could help a bit, but again, as we don't control the system package version anyway, not that much.

There is one way we could improve a (little) bit: e.g. `conf-gtksourceview` could expose¹ a `system-version` variable upon installation, e.g. `2.11`, and then you could fail explicitely with a message directly from the opam file, without relying on `./configure` (it will still fail only at build time, though, because the value of the variable can't be known yet at resolution time).

Hope this helps,
Louis Gesbert — OCamlPro

¹ http://opam.ocaml.org/doc/Manual.html#dotconfigsection-variables

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-11  3:09       ` Francois Berenger
  2018-12-11 11:40         ` Louis Gesbert
@ 2018-12-14 11:38         ` Emilio Jesús Gallego Arias
  2018-12-16  8:12           ` Jacques Garrigue
  1 sibling, 1 reply; 11+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-14 11:38 UTC (permalink / raw)
  To: Francois Berenger; +Cc: caml users, caml-list-request

Hi Francois,

Francois Berenger <mlists@ligand.eu> writes:

> You are suggesting that opam should support the installation of
> different versions of the same thing.
> I think nix can do that, and that indeed looks like a current
> limitation of opam.

I wasn't going that far [as that tends to be quite complicated
technically].

I just proposed that our OPAM workflow should support for packages to
specify versioned dependencies on depext stuff, so a package A can do
"gtk-3.0 >= 3.12" and some other package B can specify "gtk-3.0 >=
3.14".

Even if that only serves as documentation for now.

The `conf-gtk` approach seems not very well suited for this.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-11 11:40         ` Louis Gesbert
@ 2018-12-14 11:41           ` Emilio Jesús Gallego Arias
  0 siblings, 0 replies; 11+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-14 11:41 UTC (permalink / raw)
  To: Louis Gesbert; +Cc: caml-list, Francois Berenger, caml-list-request

Louis Gesbert <louis.gesbert@ocamlpro.com> writes:

> I don't believe that's what was suggested in the original message,
> though ? The pointed issue seemed to me that we don't handle detailed
> versions for `conf-*` packages, which means we can't encode precise
> dependencies to the underlying system package versions. In other
> words, _handling_ the fact that "package A requires version > 2.10 and
> package B version > 2.11" is no problem at all for opam, but
> _expressing_ it is, for `conf-*` packages.

Exactly, thanks for the summary Louis.

> The thing is that we can only detect the installed versions of system
> packages, not control them (even with `opam-depext`, we can trigger
> the installation of a given package, but most distributions don't
> allow to choose between multiple versions). In this case, you will
> have to rely on your package's `./configure` to fail when the version
> of the system dependency doesn't match, which is not the most helpful
> solution; adding the depexts to the package directly could help a bit,
> but again, as we don't control the system package version anyway, not
> that much.
>
> There is one way we could improve a (little) bit:
> e.g. `conf-gtksourceview` could expose¹ a `system-version` variable
> upon installation, e.g. `2.11`, and then you could fail explicitely
> with a message directly from the opam file, without relying on
> `./configure` (it will still fail only at build time, though, because
> the value of the variable can't be known yet at resolution time).

I am still not convinced by this; it seems to require quite a bit of
overhead for something that is IMO better done on the package itself.

The thing is that packages are the ones that really know what they
depend upon; adding this indirection layer serves little purpose.

Something that should be very useful tho is to be able to rely on a
centralized depexp database.

Thus, when I write "depext: [ gtk-2.0 >= 2.11 ]" I don't have to provide
the info for native mappings, and I can check what the supported set of
names is, etc...

Best,
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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-14 11:38         ` Emilio Jesús Gallego Arias
@ 2018-12-16  8:12           ` Jacques Garrigue
  0 siblings, 0 replies; 11+ messages in thread
From: Jacques Garrigue @ 2018-12-16  8:12 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias; +Cc: Mailing List OCaml

2018/12/14 20:38, Emilio Jesús Gallego Arias <e@x80.org>:
> 
> Hi Francois,
> 
> Francois Berenger <mlists@ligand.eu> writes:
> 
>> You are suggesting that opam should support the installation of
>> different versions of the same thing.
>> I think nix can do that, and that indeed looks like a current
>> limitation of opam.
> 
> I wasn't going that far [as that tends to be quite complicated
> technically].
> 
> I just proposed that our OPAM workflow should support for packages to
> specify versioned dependencies on depext stuff, so a package A can do
> "gtk-3.0 >= 3.12" and some other package B can specify "gtk-3.0 >=
> 3.14".
> 
> Even if that only serves as documentation for now.
> 
> The `conf-gtk` approach seems not very well suited for this.

Emilio, I do agree with you on that.
I added a conf-gtk3 as was suggested to me, and since lablgtk3 requires
gtk 3.18, if dependes on a versioned package conf-gtk3.18 (i.e. cong-gtk3 ">= 18”)
However, if somebody else introduces a conf-gtk3.22 version, that one will
be installed by default (even for lablgtk3), and fail if one gtk-3.18 is available,
so this does not seem to be the right solution for versioning, and I see no
other way to do it with the current opam.

Jacques


-- 
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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
2018-12-06 10:19 ` Louis Gesbert
2018-12-06 10:40 ` Gabriel Scherer
2018-12-07 10:04 ` Emilio Jesús Gallego Arias
2018-12-07 10:15   ` Gabriel Scherer
2018-12-07 18:35     ` Emilio Jesús Gallego Arias
2018-12-11  3:09       ` Francois Berenger
2018-12-11 11:40         ` 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

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list

AGPL code for this site: git clone https://public-inbox.org/ public-inbox