On Fri, Jan 22 2021, Bjorn Ketelaars <b...@openbsd.org> wrote:
> On Fri 22/01/2021 08:19, Jeremie Courreges-Anglas wrote:
>> On Fri, Jan 22 2021, Bjorn Ketelaars <b...@openbsd.org> wrote:
>> > On Thu 21/01/2021 23:29, Jeremie Courreges-Anglas wrote:
>> >> On Thu, Jan 21 2021, Stuart Henderson <s...@spacehopper.org> wrote:
>> >> > On 2021/01/21 06:43, Bjorn Ketelaars wrote:
>> >> >> On Wed 20/01/2021 21:42, Jeremie Courreges-Anglas wrote:
>> >> >> > On Wed, Jan 20 2021, Bjorn Ketelaars <b...@openbsd.org> wrote:
>> >> >> > > (Maintainer timeout)
>> >> >> > >
>> >> >> > > ocaml is currently a RDEP for all ports that are build with it. 
>> >> >> > > This is
>> >> >> > > unnecessary for a couple of them, i.e. net/unison.
>> >> >> > 
>> >> >> > As far as I know, programs written in OCaml should run without the 
>> >> >> > OCaml
>> >> >> > runtime installed on ${OCAML_NATIVE_ARCHS}, currently i386 and amd64.
>> >> >> > Except for OCaml programs that make direct use of the OCaml runtime, 
>> >> >> > of
>> >> >> > course... But the rundep is still needed on non-native archs.
>> >> >> > 
>> >> >> > > I would like to
>> >> >> > > propose the addition of MODOCAML_RUNDEP and MODOCAML_BUILDDEP, 
>> >> >> > > which are
>> >> >> > > modelled on python.port.mk.
>> >> >> > >
>> >> >> > > Default behaviour is not changed. Setting MODOCAML_RUNDEP=No in a
>> >> >> > > Makefile excludes ocaml as RDEP.
>> >> >> > >
>> >> >> > > OK?
>> >> >> > 
>> >> >> > Your diff makes sense I think, but you can't just use it to
>> >> >> > disable the run-dep in net/unison: you'd break unison installs on
>> >> >> > non-native archs.
>> >> >> 
>> >> >> Oops, I didn't think about the above.
>> >> >> 
>> >> >> I will look further for a fitting, clean solution that serves all
>> >> >> arches.
>> >> >> 
>> >> >
>> >> > Maybe allow MODOCAML_RUNDEP=yes/no/nonative or some similar thing?
>> >> 
>> >> Hmm, so "nonative" would be for ports that produce bytecode-only
>> >> programs, even on native archs?  (No idea how many ports are affected.)
>> >> We could call it "bytecode" then, that would seem a bit more descriptive
>> >> than a plain MODOCAML_RUNDEP=Yes in a port Makefile.
>> >> 
>> >> And then MODOCAML_RUNDEP=Yes would be useful for ports that always
>> >> use lang/ocaml programs/files at runtime?
>> >> 
>> >> > It would be nice to handle the arch detection in ocaml.port.mk rather
>> >> > than in any port using this.
>> >> 
>> >> Here's the simple diff I had in mind yesterday, on top of Bjorn's diff.
>> >> It probably helps Bjorn with unison but it would require testing all
>> >> other OCaml programs, and bumping REVISION for a bunch of them.
>> >> Maybe not the easiest or safest approach.
>> >> 
>> >> I suspect that most people caring about OCaml in ports have thought
>> >> about this before, hopefully they can share their ideas. :)
>> >
>> > I'm not particular fond of testing all other OCaml programs.
>> >
>> > What do you think of the diff below; lang/ocaml is added to
>> > BUILD_DEPENDS and RUN_DEPENDS unless native-code compilation is possible
>> > *and* the port specifically requests not to.
>> >
>> > lang/ocaml is always added in cases of ! ${OCAML_NATIVE_ARCHS}, and
>> > 'make show=MODOCAML_RUNDEP' would show 'Ignored as native-code
>> > compilation is not supported on this platform'.
>> >
>> >
>> > diff --git ocaml.port.mk ocaml.port.mk
>> > index bda7f1fc763..b5e9c863089 100644
>> > --- ocaml.port.mk
>> > +++ ocaml.port.mk
>> > @@ -33,8 +33,27 @@ MODOCAML_OCAMLDOC?=ocamldoc
>> >  PKG_ARGS+=-Ddynlink=0
>> >  .endif
>> >  
>> > -RUN_DEPENDS +=            lang/ocaml
>> > -BUILD_DEPENDS +=  lang/ocaml
>> > +MODOCAML_RUN_DEPENDS=     lang/ocaml
>> > +MODOCAML_BUILD_DEPENDS=   ${MODOCAML_RUN_DEPENDS}
>> > +
>> > +# Add lang/ocaml to BUILD_DEPENDS and RUN_DEPENDS unless native-code
>> > +# compilation is possible (OCAML_NATIVE_ARCHS) and the port
>> > +# specifically requests not to.
>> > +.if ${PROPERTIES:Mocaml_native}
>> > +MODOCAML_BUILDDEP?=       Yes
>> > +MODOCAML_RUNDEP?= Yes
>> > +.else
>> > +MODOCAML_BUILDDEP:=       Ignored as native-code compilation is not 
>> > supported on this platform
>> 
>> You still need ocaml at build time, to build the bytecode and other things.
>
> I agree!
>
> It is highly unlikely that one would want to use MODOCAML_BUILDDEP=No in
> a Makefile. I can't think of any reason for offering this knob except
> that it mimics erlang/go/lua/php/python/ruby.

Unlikely but valid, just think of a port that would use OCaml scripts at
runtime.  (You can write OCaml scripts with a shebang line.)

Anyway I think it's good to allow anything in a module to be disabled,
else people tend to resort to hacks to work around hardcoded choices.

> Usage of this knob will result in failure early on. BTW if you set
> MODOCAML_BUILDDEP=No in a Makefile *and* build on a non-native arch
> lang/ocaml will still be added to BUILD_DEPENDS.

Well I misunderstood the intent of your diff, I'll blame it on my coffee
depriveness. :)

>> > +MODOCAML_RUNDEP:= ${MODOCAML_BUILDDEP}
>> 
>> Should still use ?= I think.
>
> Don't think so. If we are building on a non-native arch we want to make
> sure that lang/ocaml is added as BDEP and RDEP, independent how
> MODOCAML_RUNDEP or MODOCAML_BUILDDEP are used in a Makefile.
> [...]

An OCaml port probably needs lang/ocaml at build time on *all archs*,
I don't see a reason to introduce a difference between native and
non-native archs *at build time*, nor do I see a good reason to ignore
what a port specifies.

New proposal, still on top of your diff (full diff below).

| Index: ocaml.port.mk
| ===================================================================
| --- ocaml.port.mk.orig
| +++ ocaml.port.mk
| @@ -37,13 +37,19 @@ MODOCAML_RUN_DEPENDS=     lang/ocaml
|  MODOCAML_BUILD_DEPENDS=      lang/ocaml
|  
|  # Assume that we want to automatically add ocaml to BUILD_DEPENDS
| -# and RUN_DEPENDS unless the port specifically requests not to.
| +# unless the port specifically requests not to.
|  MODOCAML_BUILDDEP?=  Yes
| +# Same for RUN_DEPENDS, but MODOCAML_RUN_DEPENDS can take three values:
| +# Yes, No or if-not-native (translates to Yes if native-code is unsupported)
|  MODOCAML_RUNDEP?=    Yes
|  
|  .if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} == yes
|  BUILD_DEPENDS+=              ${MODOCAML_BUILD_DEPENDS}
|  .endif
| +
| +.if ${MODOCAML_RUNDEP:L} == if-not-native && ${MODOCAML_NATIVE} == No
| +MODOCAML_RUNDEP =    Yes
| +.endif
|  .if ${MODOCAML_RUNDEP:L} == yes
|  RUN_DEPENDS+=                ${MODOCAML_RUN_DEPENDS}
|  .endif

This implements the three choice logic suggested by sthen, doesn't
affect current defaults, and only cares about the runtime dep.
I hope that "if-not-native" is an improvement over "nonative".

Thoughts?


Index: ocaml.port.mk
===================================================================
RCS file: /cvs/ports/lang/ocaml/ocaml.port.mk,v
retrieving revision 1.32
diff -u -p -r1.32 ocaml.port.mk
--- ocaml.port.mk       3 Dec 2017 11:10:10 -0000       1.32
+++ ocaml.port.mk       23 Jan 2021 12:19:27 -0000
@@ -33,8 +33,27 @@ MODOCAML_OCAMLDOC?=ocamldoc
 PKG_ARGS+=-Ddynlink=0
 .endif
 
-RUN_DEPENDS +=         lang/ocaml
-BUILD_DEPENDS +=       lang/ocaml
+MODOCAML_RUN_DEPENDS=  lang/ocaml
+MODOCAML_BUILD_DEPENDS=        lang/ocaml
+
+# Assume that we want to automatically add ocaml to BUILD_DEPENDS
+# unless the port specifically requests not to.
+MODOCAML_BUILDDEP?=    Yes
+# Same for RUN_DEPENDS, but MODOCAML_RUN_DEPENDS can take three values:
+# Yes, No or if-not-native (translates to Yes if native-code is unsupported)
+MODOCAML_RUNDEP?=      Yes
+
+.if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} == yes
+BUILD_DEPENDS+=                ${MODOCAML_BUILD_DEPENDS}
+.endif
+
+.if ${MODOCAML_RUNDEP:L} == if-not-native && ${MODOCAML_NATIVE} == No
+MODOCAML_RUNDEP =      Yes
+.endif
+.if ${MODOCAML_RUNDEP:L} == yes
+RUN_DEPENDS+=          ${MODOCAML_RUN_DEPENDS}
+.endif
+
 MAKE_ENV +=            OCAMLFIND_DESTDIR=${DESTDIR}${TRUEPREFIX}/lib/ocaml \
                        OCAMLFIND_COMMANDS="ocamldoc=${MODOCAML_OCAMLDOC}"
 

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply via email to