New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Targets that spit out the files needed to install a .mllib #6067
Comments
Comment author: @hhugo I like better the two target 'src/vg.libbytefiles' and 'src/vg.libnativefiles'. Theses rules could depend on *cma *cmxa *cmxs so then one can check what has been build from a precomputed (from *.mllib) set of possible targets (Vg.cmx or vg.cmx, lib##.ext_lib, dll##.ext_dll, ...) |
Comment author: gildor Have you ever open the file setup.log generate by OASIS after a build ? Look at the extract at end of the comment. We do exactly that in OASIS and you can know precisely what to install and what has been generated looking at setup.log. It also covers the documentation generated and the binary created (byte or native depending on what you can do). Sylvain "is_built_lib_oUnitAdvanced" "true" |
Comment author: @damiendoligez ocamlbuild is now a separate project that lives on GitHub. |
Original bug ID: 6067
Reporter: @dbuenzli
Status: resolved (set by @damiendoligez on 2017-03-01T15:49:13Z)
Resolution: suspended
Priority: normal
Severity: feature
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Related to: #5185
Monitored by: @gasche kerneis @hcarty gildor
Bug description
The idea would be to introduce targets corresponding to mllib so that we know which files need to be installed to get a correctly working lib.
Given the mllib: src/vg.mllib with:
Vg
Vgr_pdf
Vgr_svg
Invoking ocamlbuild src/vg.libfiles would create the following text file _build/src/vg.libfiles:
vgr_pdf.mli
vgr_pdf.cmi
vgr_pdf.cmx
vgr_svg.mli
vgr_svg.cmi
vgr_svg.cmx
vg.mli
vg.cmi
vg.cmx
vg.cma
vg.a
vg.cmxa
vg.cmxs
Alternatively we could have two targets src/vg.libbytefiles and src/vg.libnativefiles, the disadvantage is that the intersection would not be empty.
Alternatively we could have a target src/vg.libbyte and src/vg.libnative that actually builds all the needed targets and spits out/adds to the above src/vg.libfile according to what was invoked (but I guess that adding to a file must not be easy).
The text was updated successfully, but these errors were encountered: