Jaap Boender <jaapb%kerguelen.org@localhost> writes: > On 2/18/22 3:17 PM, Greg Troxel wrote: >>> I don't think there's any benefit to trying to use the options >>> framework for it, since it's not really an option but a property of >>> the compiler. (That is, there's little or no benefit to turning the >>> native compiler off if it's supported, and none at all to trying to >>> turn it on when it's not.) > > The reason to use an option is that there were, if I recall, some > problems with specific architectures (I think it was i386) where the > native compiler is technically supported but has problems on NetBSD. > > Of course, we could also just disable those architectures in ocaml.mk. If it doesn't work, it should be turned off. In general any ability to do things differently increases complexity and thus effort, so if it's not needed I think it's better not to have it. So let's head to world where the native compiler is on if it works, and off if it doesn't, unless there's a good reason to do something different. >>> [...] > >> That all sounds right to me. >> >> Stepping back, I guess the big question is what problem needs to be >> solved. >> >> Is this just determining if the platform supports the native compiler >> or not? Or is there an idea to allow people to disable it where it >> works? >> >> Once ocaml is built with or without native compiler support, do >> pacakges that invoke the ocaml compiler need to behave differently. I >> am assuming there does need to be something different, or this >> question wouldn't come up. > > Some packages need to explicitly have options set at configure time to > build with the native compiler; almost all packages install extra > files if they're built with the native compiler. I see this now. So a package that includes ocaml.mk can inspect the variables that are set. > That's exactly the idea - ocaml.mk is supposed to be the file that all > ocaml-using packages need to include. It would be good to add a coment at the front that says that in a precise way. "ocam-using" presumably means "package that invokes an ocaml compiler as part of the build". >> I'm also unclear on lang/ocaml/buildlink3.mk. Is that needed because >> programs that use the compiler need to link to the runtime? Is it >> intended to be directly included, or only via mk/ocaml.mk? > > My idea certainly was to only have this used through ocaml.mk. And > yes, packages that use the compiler do need to link to the runtime. OK, then the buildlink3.mk should therefore have comment that it should not be included directly. >> It also looks like ocaml.mk is not include form lang/ocaml, which would >> argue for putting the "should native compiler be used" in its own mk >> fragment to be included from both places. > > I quite like this idea (probably should have done it ages ago, in > fact) in that it concentrates the architecture-detecting conditional > in one place. > > So then, for the moment I'll stay with the current idea (i.e. no > options framework) but factor out the conditionals from lang/ocaml and > mk/ocaml.mk into one file. I'd say this goes into mk/ocaml-native.mk > rather than lang/ocaml/native.mk, given that it affects all ocaml > packages, but I'm happy to be persuaded otherwise. (Maybe both ocaml > mk files should go in lang/ocaml, like with python?) I think stuff like this belongs in lang/ocaml so as not to clutter mk. So I suggest adding lang/ocaml/native.mk. If you want to move mk/ocaml.mk to lang/ocaml/ocaml.mk and patch the things that use it, I think that's a better outcome but more work, so if you want to not spend the effort I don't feel like I can complain.
Attachment:
signature.asc
Description: PGP signature