tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Updating lang/ocaml

David Holland <> writes:

> On Wed, Feb 16, 2022 at 02:50:53PM +0100, Jaap Boender wrote:
>  > I'm working on updating lang/ocaml to version 4.14 (in alpha at the moment
>  > - I'm working in wip so far), and with this update I'd like to change the
>  > way that the package determines when to build its native compiler and other
>  > stuff, in order to get rid of the cumbersome conditionals in
>  > lang/ocaml/Makefile and mk/, or at least concentrate them in one
>  > place.
>  > 
>  > My idea was to have one option (ocaml-native) that has a default value
>  > determined by whether the architecture supports the native code compiler,
>  > which is then interpreted by all the ocaml packages (through mk/
>  > to build/use the native compiler or not.
>  >
>  > [...]
> 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.)
> What I would think the right approach is some conditionals in
> mk/ to set a variable that's then used other places that need
> to know. But that's what's there already, AFAICT, so I'm not sure what
> else to suggest.

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.

Would simply:

  make a lang/ocaml/ and put all the conditionals/variables

  include that from

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

I'm also unclear on lang/ocaml/   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/

It also looks like 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.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index