Re: [NEW] OCaml oasis and Janestreet Core and Async
Hi, I just updated my OCaml ports and I think at least oasis would be good to have in ports tree because I need it occasionaly to regenerate broken build systems (like recently for ocaml-rss). It is the OCaml automake. Oasis depends on five other ports I would need to import. OK to import the attached ports? Attached you find those ports: - oasis - ocaml-data-notation - ocaml-expect - ocaml-fileutils - ocaml-mod - ocaml-ocamlify Christopher -- http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE oasis.tar.gz Description: application/gzip pgpdVTfsLhDgi.pgp Description: OpenPGP digital signature
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 29 March 2015 at 07:41, Christopher Zimmermann chr...@openbsd.org wrote: Hi, I just updated my OCaml ports and I think at least oasis would be good to have in ports tree because I need it occasionaly to regenerate broken build systems (like recently for ocaml-rss). It is the OCaml automake. Oasis depends on five other ports I would need to import. OK to import the attached ports? Attached you find those ports: - oasis - ocaml-data-notation - ocaml-expect - ocaml-fileutils - ocaml-mod - ocaml-ocamlify Christopher -- http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE No objections from me. I'm off to p2k15 in a couple of days so I won't be able to test builds on non-amd64 boxes until I get back. Of course while at p2k15 I'm available to poke at/learn about ports. :-) Ken
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 10 Oct 2014, at 11:48, Kenneth Westerback kwesterb...@gmail.com wrote:
On 10 October 2014 14:46, Kenneth Westerback kwesterb...@gmail.com wrote:
On 10 October 2014 13:03, Christopher Zimmermann christop...@gmerlin.de
wrote:
Hi,
attached you find many new OCaml ports. Mainly the following two and
their dependencies:
* Oasis (an OCaml project build and metadata tool) used by many of our
OCaml ports.
* Janestreet Core standard library overlay and Janestreet Async
Oasis depends on devel/janestreet/ocaml-type_conv while most of
janestreet stuff uses oasis. If this is too much, I could leave the rest
of janestreet for now and only import ocaml-type_conv.
Since I'm currently waiting for the release of OPAM 1.2
(https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
which can be used to install all those libraries and binaries, I'm
wondering whether it still makes any sense to maintain those ports in
our ports tree. The same applies to other ports already in our tree
like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
Christopher
Personally I would prefer to use opam over ports. The only reason I
can see for maintaining ports is if they are needed to build other
ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
eliminated the penny).
Ken
I guess we would also need a port when upstream needs patches to
compile on OpenBSD. Hopefully a rare situation going forward.
I'm happy to merge OpenBSD-specific fixes into OPAM -- it's possible to
add OS-specific selectors in the patches field to not affect other OSes.
However, it is very convenient to be able to depend on a binary
installation of OCaml libraries for end-user applications, particularly
given the strict versioning requirements. The OpenBSD port is also
higher quality when it comes to architecture portability, since it
separates out bytecode vs native code vs native dynlinking architectures.
There is enough metadata available in an OPAM package to generate a
snapshot of OpenBSD ports from a given package set. I'm not suggesting
we automatically import the results into OpenBSD, but it would really
help keep the ports tree in sync with the latest versions of libraries.
The metadata needed for this is roughly:
- build instructions -- present in OPAM, but they do not separate out
fake installation and native code at the moment. This could be added
to OPAM fairly easily.
- external dependencies -- OPAM has a 'depexts' field where OS packages
can be specified. This is a free-form field, so it could be a precise
pkgspec for the OpenBSD entry.
- categories and homepages -- these can be lifted straight out of the
OPAM spec, and tags can be used to map OpenBSD-specific information.
More broadly though, does any other language-specific packaging system
do this at the moment, or all ports maintained manually?
-anil
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 11 October 2014 09:09, Anil Madhavapeddy a...@recoil.org wrote:
On 10 Oct 2014, at 11:48, Kenneth Westerback kwesterb...@gmail.com wrote:
On 10 October 2014 14:46, Kenneth Westerback kwesterb...@gmail.com wrote:
On 10 October 2014 13:03, Christopher Zimmermann christop...@gmerlin.de
wrote:
Hi,
attached you find many new OCaml ports. Mainly the following two and
their dependencies:
* Oasis (an OCaml project build and metadata tool) used by many of our
OCaml ports.
* Janestreet Core standard library overlay and Janestreet Async
Oasis depends on devel/janestreet/ocaml-type_conv while most of
janestreet stuff uses oasis. If this is too much, I could leave the rest
of janestreet for now and only import ocaml-type_conv.
Since I'm currently waiting for the release of OPAM 1.2
(https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
which can be used to install all those libraries and binaries, I'm
wondering whether it still makes any sense to maintain those ports in
our ports tree. The same applies to other ports already in our tree
like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
Christopher
Personally I would prefer to use opam over ports. The only reason I
can see for maintaining ports is if they are needed to build other
ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
eliminated the penny).
Ken
I guess we would also need a port when upstream needs patches to
compile on OpenBSD. Hopefully a rare situation going forward.
I'm happy to merge OpenBSD-specific fixes into OPAM -- it's possible to
add OS-specific selectors in the patches field to not affect other OSes.
However, it is very convenient to be able to depend on a binary
installation of OCaml libraries for end-user applications, particularly
given the strict versioning requirements. The OpenBSD port is also
higher quality when it comes to architecture portability, since it
separates out bytecode vs native code vs native dynlinking architectures.
There is enough metadata available in an OPAM package to generate a
snapshot of OpenBSD ports from a given package set. I'm not suggesting
we automatically import the results into OpenBSD, but it would really
help keep the ports tree in sync with the latest versions of libraries.
The metadata needed for this is roughly:
- build instructions -- present in OPAM, but they do not separate out
fake installation and native code at the moment. This could be added
to OPAM fairly easily.
- external dependencies -- OPAM has a 'depexts' field where OS packages
can be specified. This is a free-form field, so it could be a precise
pkgspec for the OpenBSD entry.
- categories and homepages -- these can be lifted straight out of the
OPAM spec, and tags can be used to map OpenBSD-specific information.
More broadly though, does any other language-specific packaging system
do this at the moment, or all ports maintained manually?
-anil
IANA porter, so I speak only from a user perspective. And I don't use
any perl ports so I don't know if they represent all perl ports used
on OpenBSD or just those needed OpenBSD specific tweaks.
If there are OpenBSD specific patches needed then I think a port is
the way to go. I'd hate to have a lot of info kept in opam only to
find Oxford has kidnapped Anil on boat race night and is demanding the
OpenBSD Ocaml community cough up. :-)
I currently have no idea how many OpenBSD patches are needed. The
couple I found while playing with getting core_extended working were
fixed by OpenBSD commits or are in queue to get fixed in core_extended
(right, Anil?). The other packages I needed/wanted to try all worked
from the wip opam 1.2 port.
My two minor concerns are 1) making sure RWO readers find OpenBSD a
congenial place to follow along, and 2) making sure that opam and
ports can co-exist if opam is available on OpenBSD.
In regards to 2), I encountered confusion when I had utop port
installed and then also blithely installed it with opam. Not to say it
is certain that I didn't screw up something just on my system, but the
relations between the two should be well known/easily discovered.
Ken
Re: [NEW] OCaml oasis and Janestreet Core and Async
On Sat, 11 Oct 2014 06:09:49 -0700 Anil Madhavapeddy a...@recoil.org wrote: I'm happy to merge OpenBSD-specific fixes into OPAM -- it's possible to add OS-specific selectors in the patches field to not affect other OSes. Can you show me an example please? However, it is very convenient to be able to depend on a binary installation of OCaml libraries for end-user applications, particularly given the strict versioning requirements. If that's the only reason for maintaining OCaml ports, I'd rather remove all ports without any end-user reverse-depends. If we don't add oasis, this would be all devel/ocaml-* ports (for starters). Our current set of OCaml end-user applications has a quite modest set of dependencies. Is this prone to change? The OpenBSD port is also higher quality when it comes to architecture portability, since it separates out bytecode vs native code vs native dynlinking architectures. In general I'd rather improve the quality of upstream / the OPAM repository than just OpenBSD ports. There is enough metadata available in an OPAM package to generate a snapshot of OpenBSD ports from a given package set. I'm not suggesting we automatically import the results into OpenBSD, but it would really help keep the ports tree in sync with the latest versions of libraries. The metadata needed for this is roughly: - build instructions -- present in OPAM, but they do not separate out fake installation and native code at the moment. This could be added to OPAM fairly easily. - external dependencies -- OPAM has a 'depexts' field where OS packages can be specified. This is a free-form field, so it could be a precise pkgspec for the OpenBSD entry. - categories and homepages -- these can be lifted straight out of the OPAM spec, and tags can be used to map OpenBSD-specific information. Great! That's something I wanted for quite some time now, but I didn't know enough of OPAM to tell whether it was feasible. Are you thinking of translating the OPAM repository to a ports tree or let OPAM generate binary packages? More broadly though, does any other language-specific packaging system do this at the moment, or all ports maintained manually? -anil -- http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE signature.asc Description: PGP signature
[NEW] OCaml oasis and Janestreet Core and Async
Hi,
attached you find many new OCaml ports. Mainly the following two and
their dependencies:
* Oasis (an OCaml project build and metadata tool) used by many of our
OCaml ports.
* Janestreet Core standard library overlay and Janestreet Async
Oasis depends on devel/janestreet/ocaml-type_conv while most of
janestreet stuff uses oasis. If this is too much, I could leave the rest
of janestreet for now and only import ocaml-type_conv.
Since I'm currently waiting for the release of OPAM 1.2
(https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
which can be used to install all those libraries and binaries, I'm
wondering whether it still makes any sense to maintain those ports in
our ports tree. The same applies to other ports already in our tree
like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
Christopher
The ports are also at /cvs.d/hack/chrisz/janestreet.tgz.
This is the full list of new ports:
devel/ocaml-data-notation
devel/ocaml-expect
devel/ocaml-fileutils
devel/ocaml-mod
devel/ocaml-ocamlify
sysutils/oasis
devel/janestreet/ocaml-type_conv
devel/janestreet/ocaml-async
devel/janestreet/ocaml-async_extra
devel/janestreet/ocaml-async_kernel
devel/janestreet/ocaml-async_shell
devel/janestreet/ocaml-async_unix
devel/janestreet/ocaml-bin_prot
devel/janestreet/ocaml-comparelib
devel/janestreet/ocaml-core
devel/janestreet/ocaml-core_extended
devel/janestreet/ocaml-core_kernel
devel/janestreet/ocaml-custom_printf
devel/janestreet/ocaml-enumerate
devel/janestreet/ocaml-fieldslib
devel/janestreet/ocaml-herelib
devel/janestreet/ocaml-pa_bench
devel/janestreet/ocaml-pa_ounit
devel/janestreet/ocaml-pa_test
devel/janestreet/ocaml-pipebang
devel/janestreet/ocaml-re2
devel/janestreet/ocaml-sexplib
devel/janestreet/ocaml-textutils
devel/janestreet/ocaml-typerep
devel/janestreet/ocaml-variantslib
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
janestreet.tgz
Description: application/compressed-tar
signature.asc
Description: PGP signature
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 10 October 2014 13:03, Christopher Zimmermann christop...@gmerlin.de wrote:
Hi,
attached you find many new OCaml ports. Mainly the following two and
their dependencies:
* Oasis (an OCaml project build and metadata tool) used by many of our
OCaml ports.
* Janestreet Core standard library overlay and Janestreet Async
Oasis depends on devel/janestreet/ocaml-type_conv while most of
janestreet stuff uses oasis. If this is too much, I could leave the rest
of janestreet for now and only import ocaml-type_conv.
Since I'm currently waiting for the release of OPAM 1.2
(https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
which can be used to install all those libraries and binaries, I'm
wondering whether it still makes any sense to maintain those ports in
our ports tree. The same applies to other ports already in our tree
like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
Christopher
Personally I would prefer to use opam over ports. The only reason I
can see for maintaining ports is if they are needed to build other
ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
eliminated the penny).
Ken
The ports are also at /cvs.d/hack/chrisz/janestreet.tgz.
This is the full list of new ports:
devel/ocaml-data-notation
devel/ocaml-expect
devel/ocaml-fileutils
devel/ocaml-mod
devel/ocaml-ocamlify
sysutils/oasis
devel/janestreet/ocaml-type_conv
devel/janestreet/ocaml-async
devel/janestreet/ocaml-async_extra
devel/janestreet/ocaml-async_kernel
devel/janestreet/ocaml-async_shell
devel/janestreet/ocaml-async_unix
devel/janestreet/ocaml-bin_prot
devel/janestreet/ocaml-comparelib
devel/janestreet/ocaml-core
devel/janestreet/ocaml-core_extended
devel/janestreet/ocaml-core_kernel
devel/janestreet/ocaml-custom_printf
devel/janestreet/ocaml-enumerate
devel/janestreet/ocaml-fieldslib
devel/janestreet/ocaml-herelib
devel/janestreet/ocaml-pa_bench
devel/janestreet/ocaml-pa_ounit
devel/janestreet/ocaml-pa_test
devel/janestreet/ocaml-pipebang
devel/janestreet/ocaml-re2
devel/janestreet/ocaml-sexplib
devel/janestreet/ocaml-textutils
devel/janestreet/ocaml-typerep
devel/janestreet/ocaml-variantslib
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 10 October 2014 14:46, Kenneth Westerback kwesterb...@gmail.com wrote:
On 10 October 2014 13:03, Christopher Zimmermann christop...@gmerlin.de
wrote:
Hi,
attached you find many new OCaml ports. Mainly the following two and
their dependencies:
* Oasis (an OCaml project build and metadata tool) used by many of our
OCaml ports.
* Janestreet Core standard library overlay and Janestreet Async
Oasis depends on devel/janestreet/ocaml-type_conv while most of
janestreet stuff uses oasis. If this is too much, I could leave the rest
of janestreet for now and only import ocaml-type_conv.
Since I'm currently waiting for the release of OPAM 1.2
(https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
which can be used to install all those libraries and binaries, I'm
wondering whether it still makes any sense to maintain those ports in
our ports tree. The same applies to other ports already in our tree
like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
Christopher
Personally I would prefer to use opam over ports. The only reason I
can see for maintaining ports is if they are needed to build other
ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
eliminated the penny).
Ken
I guess we would also need a port when upstream needs patches to
compile on OpenBSD. Hopefully a rare situation going forward.
Ken
The ports are also at /cvs.d/hack/chrisz/janestreet.tgz.
This is the full list of new ports:
devel/ocaml-data-notation
devel/ocaml-expect
devel/ocaml-fileutils
devel/ocaml-mod
devel/ocaml-ocamlify
sysutils/oasis
devel/janestreet/ocaml-type_conv
devel/janestreet/ocaml-async
devel/janestreet/ocaml-async_extra
devel/janestreet/ocaml-async_kernel
devel/janestreet/ocaml-async_shell
devel/janestreet/ocaml-async_unix
devel/janestreet/ocaml-bin_prot
devel/janestreet/ocaml-comparelib
devel/janestreet/ocaml-core
devel/janestreet/ocaml-core_extended
devel/janestreet/ocaml-core_kernel
devel/janestreet/ocaml-custom_printf
devel/janestreet/ocaml-enumerate
devel/janestreet/ocaml-fieldslib
devel/janestreet/ocaml-herelib
devel/janestreet/ocaml-pa_bench
devel/janestreet/ocaml-pa_ounit
devel/janestreet/ocaml-pa_test
devel/janestreet/ocaml-pipebang
devel/janestreet/ocaml-re2
devel/janestreet/ocaml-sexplib
devel/janestreet/ocaml-textutils
devel/janestreet/ocaml-typerep
devel/janestreet/ocaml-variantslib
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
