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

generate html documentation for a library #21

Open
andrewrk opened this Issue Dec 11, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@andrewrk
Member

andrewrk commented Dec 11, 2015

No description provided.

@andrewrk andrewrk referenced this issue Oct 26, 2016

Closed

zig build system #204

8 of 12 tasks complete

@andrewrk andrewrk added this to the 0.2.0 milestone Apr 3, 2017

@tiehuis

This comment has been minimized.

Member

tiehuis commented Sep 7, 2017

Started something preliminary here https://github.com/tiehuis/zig-docgen.

The idea right now is to generate some intermediate form (JSON) and pass that to some existing document generator. Working on writing the tokenizer in zig and a simplistic parser so may have some overlap with #89 eventually.

@andrewrk

This comment has been minimized.

Member

andrewrk commented Sep 7, 2017

Exciting!

I envision documentation generation as automatically happening as part of the normal build process. Rust's generated documentation looks great and has a usable search feature. I think doxygen is an example of what not to do.

Maybe as you mentioned, we get started on that self hosted compiler so we can do this feature in userland. As long as we keep the C++ implementation able to build the zig implementation, the bootstrapping process is simple enough.

Also related is the compiler outputting in some way data that is useful for IDEs such as an AST or a type table or something. @thejoshwolfe knows more about the requirements there.

@andrewrk

This comment has been minimized.

Member

andrewrk commented Nov 13, 2018

I'm starting to think it might make sense to go ahead and implement this in stage1:

  • Prototypes reveal issues so that when doing the final implementation, we can make better informed design decisions. For example, if I hadn't prototyped copy-elision in stage1, it would have been a much lower quality implementation in self-hosted.
  • We really need this feature. It's been too long without it already.
  • Much of the work can be reused, such as the html and js.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment