Re: Updating lang/ocaml

[Jaap Boender <jaapb%kerguelen.org@localhost>]

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
> 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.

> Would simply:
>
>    make a lang/ocaml/native.mk and put all the conditionals/variables
>    there
>
>    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?)

best

  Jaap