Re: [NEW] OCaml oasis and Janestreet Core and Async
On 29 March 2015 at 07:41, Christopher Zimmermann 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
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 Sat, 11 Oct 2014 06:09:49 -0700 Anil Madhavapeddy 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
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 11 October 2014 09:09, Anil Madhavapeddy wrote: > On 10 Oct 2014, at 11:48, Kenneth Westerback wrote: > >> On 10 October 2014 14:46, Kenneth Westerback wrote: >>> On 10 October 2014 13:03, Christopher Zimmermann >>> 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 10 Oct 2014, at 11:48, Kenneth Westerback wrote: > On 10 October 2014 14:46, Kenneth Westerback wrote: >> On 10 October 2014 13:03, Christopher Zimmermann >> 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 10 October 2014 14:46, Kenneth Westerback wrote: > On 10 October 2014 13:03, Christopher Zimmermann > 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
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 10 October 2014 13:03, Christopher Zimmermann 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
[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