deriving
deriving copied to clipboard
ocsigen
Really use OASIS
For now the META file is written by hands because of some issues. @hnrgrgr can you explain here what are the issues you encountered ?
Maybe someone has an idea of how to fix it.
After some discussions with @chambart, I reduced the number of issues at 2. Namely:
- empty package in META
-
-link-all
The ideal META file, as discussed in #16, contains 2 "empty-packages" or "meta-packages", i.e. the deriving and the deriving.syntax packages do not contain archives rules, only requires rules. I don't know how to express that in an _oasis file, without one of the two following hacks :
- Empty "Library". We may define libraries without 'Modules' and add the expected
BuildDependenciesetXMETARequires. However, I'm not fond of having empty cma-files. It might be error-prone (e.g. you may wrongly assume such a cma have to be linked). Maybe, if we name itempty_hackish.cma. But this way, the_oasisfile get crippled: you have to use a not very meaningfulFindlibParent: empty_hackish. - Empty "Library" (bis). An alternative would be to use
FindlibContainer, but i didn't succeed. It seems oasis does allow to add some extraXMETARequiresto such "virtual container'. Futhermore, the 'root' package being a virtual one, it seems oasis ignore thelib/METAfile (that may contains some lines outside of# OASIS_START... ). And we need this for the virtualsyntax_tcpackage.
The second issue (-link-all) may be a bug in oasis. When using XMETAType: syntax oasis generates the following 'archives' rules:
archive(syntax, preprocessor) = "pa_deriving_common.cma"
archive(syntax, toploop) = "pa_deriving_common.cma"
archive(syntax, byte) = "pa_deriving_common.cma"
archive(syntax, byte, plugin) = "pa_deriving_common.cma"
archive(syntax, native) = "pa_deriving_common.cmxa"
archive(syntax, native, plugin) = "pa_deriving_common.cmxs"
I' m not sure what the last 4 lines are but they seems imcompatilbe with -link-all. With the ideal META, we may compile a simple program with the following command:
ocamlfind ocamlc -linpkg -syntax camlp4o -package deriving -o test test.ml
With these rules, the pa_deriving_common.cma argument is given to camlp4 but also to 'ocamlc' in order to be linked into test. In common situations, it has no effect, as test.ml as no dependencies over modules within pa_deriving_common.cma. But, when -link-all is used, the syntax extension get linked into the exe ! Probably not a good idea.
If these lines are really required (when defining a syntax extension that reuse the internal of deriving ?), a solution would be to use require(syntax, preprocessor) = "deriving.syntax.common" and require(syntax, toploop) = "deriving.syntax.common", instead of the current require = "deriving.syntax.common". It could be achievedby adding some XMETAEXtraLines. But without specific supports within oasis, I believe the _oasis file become less readable than the hand written META. That is a pity.
If someone propose a readable _oasis file, i'm OK with it. But I won't hack on it furthermore.
PS: about the last hack, you should also add a archive (syntax, preprocessor) = "-ignore dummy" if the 'current' package is not a syntax extension itself. Otherwise, findlib ignores the dependency.
@gildor478 ?
About the « archives » rules, it's taken from this page: http://projects.camlcity.org/projects/dl/findlib-1.2.8/doc/guide-html/x412.html
Well, this page use two distinct .cma: one for the runtime and one for the preprocessor. And only the 'runtime.cma' is associated to the 'byte' predicate. This is totally different to the code currently generated by oasis where the same cma is associated to the 'byte' and 'preprocessor' predicates.
Quick word, I am working on all the issues you have raised. I need to write a test to check the problem with the META generated and I will come back to you with answers and fixes (I think PR#38 for oasis will solve this -- but I need to prove it).
