On Mon, 20 Dec 2021, Marc Espie wrote:
> On Mon, Dec 20, 2021 at 08:25:40PM +0100, Christopher Zimmermann wrote:
> > On Mon, Dec 20, 2021 at 09:02:22PM +0200, Anil Madhavapeddy wrote:
> >
> > > This also looks good to me. Is there any infrastructure in the
> > > update-plist
> > > to hook in custom logic for OCaml? The various cmx/cmxs/a files should
> > > all be routed to a PFRAG.native or PFRAG.dynlink-native file and it would
> > > be nice if that were a little more automated.
> > >
> > > Alternatively I could just write a shell fragment if others would find
> > > it useful...
> >
> > I had such a sed / sh solution several years ago.
> > There's just one problem: Exceptions to the rule.
> > Also not all .a files go to native fragments.
> > Some .cmo are only available on native code (compiler libs).
> >
> > But maybe ask espie@. He seems to maintain
> > ports/infrastructure/bin/update-plist.
>
> You guy really want to look at ports/infrastructure/lib/OpenBSD/FS2.pm
>
> that's where you hook up new recognizers for special cases.
>
> Then you can code specific behavior depending on those properties in
> update-plist proper.
>
> Directing files based on their class to a PFRAG shouldn't be too hard.
> (Note that existing plists entries will tend to stay where they already
> are)
>
> I have zero idea about the logic behind it.
>
> If you explain it to me, I might even be willing to help a bit ;)
>
> But please, definitely do NOT add shell logic on top of it. You've got
> a powerful framework which can do things semantically. Why go down ?
>
Hi Marc, your help would be much appreciated.
Here's my proposal for which extensions should go where for new files that
are being added to the packing lists:
PFRAG.native a
PFRAG.native cmx
PFRAG.native cmxa
PFRAG.native cmxs
PFRAG.native native
PFRAG.native o
PFRAG.native opt
PLIST byte
PLIST cma
PLIST cmi
PLIST cmo
PLIST cmt
PLIST cmti
PLIST ml
PLIST mli
