[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Updating lang/ocaml
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.
That all sounds right to me.
Stepping back, I guess the big question is what problem needs to be
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
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.
make a lang/ocaml/native.mk and put all the conditionals/variables
include that from ocaml.mk
work? Or is there some other place that all ocaml-using packages have
to include? To me the biggest gain comes from untangling the mk scheme.
Right now mk/ocaml.mk says what it does, but it does not say who must
include it. I'm guessing that if a package uses an ocaml compiler and
doesn't include it, that's wrong.
That's exactly the idea - ocaml.mk is supposed to be the file that all
ocaml-using packages need to include.
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.
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?)
Main Index |
Thread Index |