Closed
Conversation
Coqdoc output backend selection is implemented using an `if then else` construction; thus adding new backends is a bit painful. Ocaml 3.12 has first class modules which allow to have a more convenient runtime backend selection. The patch is relatively straightforward; tested under Ocaml 3.12.1 & 4.03. Move CoqDoc backends to first class modules.
Refactoring, now the output backend is selected in `main.ml`.
It was a stub and had no effect. Kept a warning in case it has any user in the wild.
Changes to the backend API, trying to streamline code and make it more
functional.
The commit tries to be conservative wrt existing backend code so lots of
global variables remain in use. More work should be done, but this
commit serves as a checkpoint towards greater refactoring.
Tested with Coq documentation; SF and CPDT seems OK, that is, they
exhibit the same artifacts in vanilla v8.5 vs the refactored version.
The new API additions are documented using ocamldoc.
* New backend specific API functions:
- appendix: Generates the appendix for a document.
- start_file / end_file: Starts a file, sets options, generates
header/footer if needed.
* Operations removed:
- initialize, header, trailer: replaced by start_file / end_file.
- make_multi_index, make_index, make_toc: There are options in
start_file now.
* cdglobals.ml: Add .mli file, add output helper `with_outfile`, make
a couple of functions private.
* Remove subtitle functionality: Its price in code complexity was too
high; it also was not very flexible, we will replace it with a more
flexible mechanism.
Simple backend that logs lexer actions to a .txt file.
The jsCoq backend will output an HTML file meant to be run with a build from (https://github.com/ejgallego/jscoq-builds/)
page_title was set as a global when it is only used in the html backend.
Member
|
I need more time to review this but it looks fine, could you rebase on trunk though for integration in 8.6? |
Contributor
Author
|
Sure, I will, thanks Matthieu! |
Contributor
Author
|
I didn't set my mind yet on what to do with this PR. |
Member
|
@ejgallego what shall we do with this PR? Would you like to get it on the 8.7 roadmap? |
Contributor
Author
|
I am not using coqdoc anymore (switched to something closer to |
Member
Contributor
Author
|
I don't plan to support this anymore. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a unification of PR #122 and PR #128: we propose some conservative refactoring of coqdoc, please review. The commits are mostly self-contained and could partially merged.
We have been very convervative wrt to modification of old backend code, things seem to work. Tested with Coq documentation, seems to be OK; SF and CPDT seem also OK, that is, they exhibit the same artifacts in vanilla v8.5 vs the refactored version.
Some of the changes are: