On Sat, Jan 23 2021, Bjorn Ketelaars <bket@openbsd.org> wrote:
> On Sat 23/01/2021 18:22, Jeremie Courreges-Anglas wrote:
>> On Sat, Jan 23 2021, Stuart Henderson <stu@spacehopper.org> wrote:
>> > On 2021/01/23 13:33, Jeremie Courreges-Anglas wrote:
>> >> On Fri, Jan 22 2021, Bjorn Ketelaars <bket@openbsd.org> wrote:
>> >> >
>> >> > 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.
>> >
>> > Agreed, variable build dependencies per-arch sounds like it's asking for
>> > trouble.
>> >
>> >> | # 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
>> >
>> > I'm not totally objecting to MODOCAML_BUILDDEP=no but I'm not sure
>> > there's a use for it. I'd be tempted to leave it out for now. If we
>> > do that and someone does comes up with a port that wants to disable
>> > build dep's later, they could just change ocaml.port.mk at the same
>> > time, no need to hack around it.
>> >
>> > Apart from anything else port-modules(5) is already hard to read and
>> > I'd be happy to avoid adding more :)
>> >
>> > I think MODGO_BUILDDEP can be removed from go.port.mk too, nothing
>> > uses it and I don't really see how it could..
>> >
>> > It's used quite a lot for python, and a bit for PHP though possibly
>> > not enough - this discussion made me wonder if I should change that to
>> > No by default for PHP. But those are quite different to the case of
>> > go or ocaml.
>>
>> By default I'd prefer to have all modules behave similarly, but I can
>> understand how it doesn't make sense in some situations.
>>
>> >> | +.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".
>> >
>> > love the "if-not-native" wording, that's perfect :)
>>
>> Great. Here's the latest, simpler diff. No more MODOCAML_BUILDDEP, no
>> more MODOCAML_*_DEPENDS either (after all, their content was obvious).
>>
>> Bjorn, still ok? Stuart, others?
>
> Yes, still OK.
It's in. Here's a documentation proposal, trying to make information
unambiguous wrt context. Feedback, oks?
Index: port-modules.5
===================================================================
RCS file: /d/cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.251
diff -u -p -p -u -r1.251 port-modules.5
--- port-modules.5 25 Jan 2021 14:02:18 -0000 1.251
+++ port-modules.5 1 Feb 2021 00:37:50 -0000
@@ -1309,7 +1309,13 @@ Appends to
.Ev BUILD_DEPENDS
and
.Ev MAKE_ENV .
-This selects a %%native%% plist fragment and
+Appends to
+.Ev RUN_DEPENDS
+unless
+.Ev MODOCAML_RUNDEP
+is set to No, or set to if-not-native and native compilation
+is supported on this architecture.
+Including this module selects a %%native%% plist fragment and
.Ev ocaml_native
property depending on whether the architecture supports native
compilation.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
No comments:
Post a Comment