Mk/**ocaml.mk: Convert remaining bsd.ocaml.mk to Uses/ocaml.mk

[bofh]

Summary

• Instead of USE_OCAML=yes use USES=ocaml
• If empty USES=ocaml implies build and run
• Instead of USE_OCAMLFIND_PLIST use USES=ocaml:findplist which also implies USES=ocaml:findlib
• Instead of USE_OCAML_CAMLP4 use USES=ocaml:camlp4
• Instead of USE_OCAML_FINDLIB use USES=ocaml:findlib
• Instead of USE_OCAML_LDCONFIG use USES=ocaml:ldconfig
• Instead of USE_OCAML_WASH use USES=ocaml:wash
• Instead of NO_OCAML_BUILDDEPENDS use USES=ocaml:run
• Instead of NO_OCAML_RUNDDEPENDS use USES=ocaml:build
• Instead of USE_OCAML_TK use USES=ocaml:tk which actually implies USES=ocaml:tkbuild and USES=ocaml:tkrun
• Instead of NO_OCAMLTK_BUILDDEPENDS use USES=ocaml:tkrun
• Instead of NO_OCAMLTK_RUNDEPENDS use USES=ocaml:tkbuild
• USES=ocaml:dune remains unchanged

I prefer to do more atomic/incremental changes rather than making bigger changes in one go. So rather than converting the entire bsd.ocaml.mk to valid args for the USES framework I have only converted to use the minimal USES framework and plan to do incremental changes and convert the remaining keywords to args.

Test Plan

• bulk -a -n works fine https://pkg.bofh.network/build.html?mastername=133-ocaml&build=2024-12-28_15h59m41s
• bulk -t ports that had USE_OCAML https://pkg.bofh.network/build.html?mastername=133-ocaml&build=2024-12-28_15h36m24s

[freebsd_dev.thsi.be]

Mk/Uses/ocaml.mk

9

Hi,
Thanks for working on this patch. I've also been working on a patch on this area, though I should be able to rebase my change on top of this if this lands quickly.

I believe that we can simply remove all this USE_OCAML_WASH or USES+=ocaml:wash thing. Because lang/ocaml ships lib/ocaml/ld.conf, removing lang/ocaml will remove that files.
All package modifying also lib/ocaml/ld.conf are RUN_DEPENDS on lang/ocaml, so lang/ocaml should always be removed _after_ any package modifying OCAML_LDCONF.
There is no in-tree package that overrides OCAML_LDCONF either where that could have made some sense...

I've a patch that I'd like to submit that re-do the way lib/ocaml/ld,conf is done , which will get rid of those uggy @postexec / @postunexec and fixes two PR.
I'm not sure if I should submit separately now or wait that this lands?

[bofh]

Hi,

We should have moved out of Mk/bsd.*.mk (except the obvious ones) maybe a decade ago and these are just some technical debts in the Mk directory. :)

So I am just trying to clear of the Mk directory and I plan to merge this before the next quarterly split. If you have patches for archivers/ocaml-zip and x11-toolkits/ocaml-lablgtk2 which actually utilizes the wash feature I can simply remove the wash from my commit.

I am still trying to convert some other keywords into args.

[freebsd_dev.thsi.be]

In D48227#1099727, @bofh wrote:

Hi,

We should have moved out of Mk/bsd.*.mk (except the obvious ones) maybe a decade ago and these are just some technical debts in the Mk directory. :)

So I am just trying to clear of the Mk directory and I plan to merge this before the next quarterly split. [...]

I am still trying to convert some other keywords into args.

Hi,

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testing that patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

I wonder if we could have both our changes merged together? what is the timeframe for branching 2025Q1? Either you can merge my DR and redo your ocaml.mk changes on top of it, or the opposite way I can rebase on your work?

If you have patches for archivers/ocaml-zip and x11-toolkits/ocaml-lablgtk2 which actually utilizes the wash feature I can simply remove the wash from my commit.

I've just added the ocaml-camlzip and ocaml-lablgtk2 commit to it (camlzip with an extra patch, but you can ignore that if you want). It is simply removing the USE_OCAML_WASH lines.
It would be fine to remove USE_OCAML_WASH from bsd.ocaml.mk or Uses/ocaml.mk even without those changes: it is not "nice" as the USE_OCAML_WASH=yes assignment would do nothing, but it wouldn't break the port either...
As said in my previous command, whenever those two packages would be removed, the lib/ocaml/ld.conf file would _not_ be empty because lang/ocaml is shipping the file with two lines that would not be removed by either of lablgtk2 or camlzip's postunexec, hence the @rmempty would do nothing anyway.

Mk/Uses/ocaml.mk

54

That one should really be an argument. Is it possible to convert it as well already ?

201

326–327

comment should be moved with the line ALL_TARGET?=

[freebsd_dev.thsi.be]

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testingthat patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

One other thing in that patch is the removal of USE_OCAMLFIND_PLIST, which make the bsd.ocaml.mk to Uses/ocaml.mk transistion less complicated. USE_OCAMLFIND_PLIST isn't really that useful, to the contrary it makes packaging error more likely (e.g. disabling a feature, not noticing less files are packages), so i think it is better to remove it.

[bofh]

Here is the updated patch which converts everything from bsd.ocaml.mk to args for USES=ocaml. See the summary.

[bofh]

In D48227#1099753, @freebsd_dev.thsi.be wrote:

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testingthat patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

One other thing in that patch is the removal of USE_OCAMLFIND_PLIST, which make the bsd.ocaml.mk to Uses/ocaml.mk transistion less complicated. USE_OCAMLFIND_PLIST isn't really that useful, to the contrary it makes packaging error more likely (e.g. disabling a feature, not noticing less files are packages), so i think it is better to remove it.

Thanks for the work. Unfortunately due to the holidays and everything it's difficult to count maintainer-timeout and commit some of those patches. This will be the final patch for the Mk infrastructure. However there is definitely another big patch touching nearly 128 more files to modify the USES directive. If you want I can share that patch with you but be aware that I am doing the same for bsd.java.mk which will touch around 540 files and there are common files so you will need lots of rebase. To ease your rebase what I can do is commit some of your ports patches if you can share it somewhere.

So far I do not see any more complication in this conversion but I think it's better to hold your ldconfig patch at this point.

[freebsd_dev.thsi.be]

In D48227#1099827, @bofh wrote:

In D48227#1099753, @freebsd_dev.thsi.be wrote:

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testingthat patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

One other thing in that patch is the removal of USE_OCAMLFIND_PLIST, which make the bsd.ocaml.mk to Uses/ocaml.mk transistion less complicated. USE_OCAMLFIND_PLIST isn't really that useful, to the contrary it makes packaging error more likely (e.g. disabling a feature, not noticing less files are packages), so i think it is better to remove it.

Thanks for the work. Unfortunately due to the holidays and everything it's difficult to count maintainer-timeout and commit some of those patches.

The timeouts are all 10weeks and more :-) But it is true that there are a couple fixes that I haven't submitted to their maintainers.

This will be the final patch for the Mk infrastructure. However there is definitely another big patch touching nearly 128 more files to modify the USES directive. If you want I can share that patch with you but be aware that I am doing the same for bsd.java.mk which will touch around 540 files and there are common files so you will need lots of rebase.

I assume that this patch is for removing all the USE_OCAML=yes? Once this revision and the patch for USE_OCAML is committed, I will rebase my D48228.

To ease your rebase what I can do is commit some of your ports patches if you can share it somewhere.

I'm not sure it is worth to update a couple of ports from my patchset. The problem with ocaml is that you can't really update a single library and expect existing consumers (other ocaml libraries) to keep working, they all need to be rebuild. So you end up having to rev-bump a lot of ports and that's generating lots of conflicts if you have many discrete updates to do. So i think it is better that I wait that your work gets committed, and by that time I'll work on submitting the removal of USE_OCAML_WASH and USE_OCAMLFIND_PLIST to the maintainer of packages still using it, so that I can all bundle everything in one update.

So far I do not see any more complication in this conversion but I think it's better to hold your ldconfig patch at this point.

Ok makes sense. I think that your conversion is good.

[rene]

I can hold off branching 2025Q1

[bofh]

In D48227#1100097, @rene wrote:

I can hold off branching 2025Q1

To be frank I can commit this if I get an approval from portmgr.

[mat]

Approved as long as it's been tested with a "today" ports tree. ("today" being regarding to the day it will being pushed.)

[mat]

Oh, please add a entry to the CHANGES file too.

[mat]

Whatever is in the review description will do just fine for the CHANGES entry.

[bofh]

I do have the necessary CHANGES entry just not attached it here for keeping it clutter free. I will rerun one more mini exp tomorrow and commit.

[mat]

Great, thank you for this work.