<thomasga>
what happens if you run the Makefile again with a different value of HAS_CTYPES ?
<dsheets>
thomasga, how else would you instruct findlib about the optional deps that are activated?
<dsheets>
then you'd get a different installed package with a different META
<dsheets>
you want subpackages?
<dsheets>
i guess i took this approach to get some usability for the end user
<dsheets>
maybe it is misguided but i wanted people to be able to use Unix_fcntl.open_ and U_fcntl.Oflags.O_RDWR naturally
<thomasga>
dsheets: not sure if the META file will be recomputed properly then
<dsheets>
ohhh, i see what you mean
<thomasga>
the EXTRA_META is not a prerequisite of the META target
<thomasga>
and I don't see how to do that properly
<dsheets>
just force META generation
<dsheets>
or, clean between switching the depopts which is what i was doing
<thomasga>
but I'm bit afraid of the added complexity in the META if any compilation unit and deps can be optional
<dsheets>
any compilation unit?
<thomasga>
well, not in your Makefile, but sometimes you want to compile foo_unix only if you have some unix lib available — but I guess you should have a separate library for that
<dsheets>
Ah, yeah, I could have Unix_unistd_unix or something
<thomasga>
yup
<dsheets>
hmm perhaps i should do Unistd and Unix_unistd
<dsheets>
It would simplify things a lot
<dsheets>
and i could use subpackages and stop fighting the module system
<thomasga>
and then you can have multiple instances of the library with different features working together
<thomasga>
(we had the same kind of issues for mirage — should we use some linking hacks or not)
<dsheets>
how's that? Dirent would still have sexp
<dsheets>
and I'd have to add/remove the subpackage from the META in the build system
<thomasga>
well can build the subpackage and let the user choose the one he wants to link with it or not
<thomasga>
if you do a link hack, he has no choice
<dsheets>
then i require the unix deps all the time?
<dsheets>
they have a choice if they lack the extra deps
<dsheets>
if they don't lack them, they would get the subpack
avsm has quit [Quit: Leaving.]
<thomasga>
yes sorry, I meant they have the choice if you have a subpackage. If you tweak the requires, they don't
<dsheets>
oh, yeah, i think it is not a good idea the way i have it now
<dsheets>
but i didn't know how to make it easy to use/remember until I looked at Unix_unistd_unix >_<
<thomasga>
ok
<dsheets>
i will switch to Unistd/Unix_unistd or Unistd/Unistd_unix, I think
<dsheets>
probably the former
<dsheets>
Or Unistd.Unix
<dsheets>
but then I can't have types live in the top module because I'd have to pack :-/
<thomasga>
you can always have Unistd_unix which includes Unistd
<thomasga>
and ask the user to do 'open Unistd_unix` at the top of its file
<thomasga>
if he wants to use the extended unix interface
<dsheets>
includes as a submodule? or "include"?
<dsheets>
There is also the possibility of a future "Unix" module based on these
avsm has joined #mirage
<avsm>
dsheets: isnt this what exists_if is for in META
<dsheets>
avsm, ah, indeed, i can conditionalize based on build products with that
<dsheets>
ok, i'm not sure what my malfunction was when i did the present design O_O
<dsheets>
very strange that even if OCAML_TOPLEVEL_PATH is defined and has a topfind in it, #use "topfind" in a script fails with "cannot find file topfind"