Usability issues with the way dune handles headers
rgrinberg opened this issue · 3 comments
I've looked over @aantron's luv library, and I noticed that there are too many contortions required to use C headers the way one wants. Even with all the contortions, one still does not get a desirable result. Here's a list of the issues:
-
To preserve the file structure of the headers (as is often required), one is required to write
installstanzas manually like here https://github.com/aantron/luv/blob/44db25c2b2669f9d1373377006a4d5850e0820e3/src/c/dune#L15 -
Introducing a dependency on the library to which the headers belong does not introduce a dependency on the headers. To depend on the headers, one has to add a
(package luv)dependency somewhere. -
When the package containing the headers is installed, things are still broken because dependencies aren't inferred correctly. Dune only adds dependencies on the header files in the root of the package, and omits dependencies on headers in sub directories.
- one is required to write
installstanzas manually like here
Furthermore, since the set of headers of a vendored library might change over time, Luv even has an upgrade-time generator for the install stanza: https://github.com/aantron/luv/blob/44db25c2b2669f9d1373377006a4d5850e0820e3/src/gen/headers.ml. If Luv could specify to install uv.h. and the directory uv with all its contents recursively, the generator would be unnecessary.
A main header plus a subdirectory is the common "detail header" pattern of organizing header files.
When the package containing the headers is installed, things are still broken ...
Do you have an example or precision for the last point?
Do you have an example or precision for the last point?
Suppose we have the following headers installed
./uv/uv.h
./uv/linux/blah.h
We only introduce dependencies on uv.h when depending on the library uv.