First draft of the OCAMLLIB patch

[samoht]

Surely not good enough to inclusion, but at least there's something to discuss.

Need to fix:

• decide if we want to return a proper/prettier error in Misc.expand_directory when +name` cannot be resolved. This patch tries to keep the same behaviour as before.
• fix asmrun/dynlink.c
• fix byterun/dynlink.c
• fix stdlib/caml/dynlink.c
• fix ./ocamlbuild/ocamlbuild_where.ml
• check that the debugger still works ok

[samoht]

Need to implement string split and test the patch a little more, but I think we can fix this with not too many changes.

[avsm]

What, you didn't like the symlink idea? :-)

[samoht]

Also need to handle asmrun/dynlink.c properly.

[whitequark]

What's the purpose of this patchset?

[samoht]

it was just a quick and hackish response to some issues with system camlp4.

from @avsm
There are two distribution channels for the new camlp4: via OPAM (source users) and via OS binary packaging (distro users). In the latter case, camlp4 can be installed in exactly the same way as it is today, beside the compiler so that adding -I +camlp4 is sufficient to pick up the library).

With OPAM, things get a little more complex. There are two types of compiler switches that are supported: a system compiler, and a custom-compiled compiler. Installing camlp4 via OPAM requires that the installation operate without root privilege. If a custom compiler switch is used, this isn't a problem since the compiler binaries live under ~/.opam//{bin,lib}.

It's the system switch that is problematic for installing camlp4, since we cannot modify the (root owned) system compiler installation, and must stick OCaml somewhere inside ~/.opam. The most obvious way to work around this is by installing it via ocamlfind, which is what the camlp4-4.01.0+rc1 tagged version does.

Using ocamlfind brings a couple of drawbacks though:

• Most obviously, any use of camlp4 now requires ocamlfind to be used to locate camlp4 in the pp path. One could argue this isn't too bad since it brings the tool into line with the vast majority of other packages that do use it (including the emerging set of ppx tools).
• Unfortunately, ocamlbuild's builtin tags for rules hardcode a -I +camlp4 as far as I can tell, so porting some of these requires imposing a -use-ocamlfind and possibly adding custom rules, or patching ocamlbuild quite late in the RC cycle (i.e. tomorrow, presumably).

Any opinions on the best way to fix this with minimal disruption? We could revert the ocamlfind dependency, or see if there's some symlink magic that would let all three setups work (distro, OPAM-system and OPAM-custom). Here's hoping the wisdom of crowds finds an easy solution that doesn't leave one of these folks high and dry :-)

[samoht]

Closing as no more relevant