Skip to content
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

Really use OASIS #18

Open
kit-ty-kate opened this issue Jan 27, 2014 · 7 comments
Open

Really use OASIS #18

kit-ty-kate opened this issue Jan 27, 2014 · 7 comments

Comments

@kit-ty-kate
Copy link
Member

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.

@hnrgrgr
Copy link

hnrgrgr commented Jan 28, 2014

After some discussions with @chambart, I reduced the number of issues at 2. Namely:

  1. empty package in META
  2. -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 BuildDependencies et XMETARequires. 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 it empty_hackish.cma. But this way, the _oasis file get crippled: you have to use a not very meaningful FindlibParent: 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 extra XMETARequires to such "virtual container'. Futhermore, the 'root' package being a virtual one, it seems oasis ignore the lib/META file (that may contains some lines outside of # OASIS_START... ). And we need this for the virtual syntax_tc package.

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.

@kit-ty-kate
Copy link
Member Author

@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

@hnrgrgr
Copy link

hnrgrgr commented Jan 31, 2014

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.

@gildor478
Copy link

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).

@hnrgrgr
Copy link

hnrgrgr commented Feb 8, 2014

@gildor478 Great news thanks.

@kit-ty-kate
Copy link
Member Author

@hnrgrgr Which problem remains for this issue ?

@kit-ty-kate
Copy link
Member Author

ping

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants