Documention

[TheDan64]

• Full documentation:
  • attributes.rs: 8ecc815
  • basic_block.rs: ed7175c
  • builder.rs
  • comdat.rs: e185481
  • context.rs: e4c218c
  • data_layout.rs
  • debug_info.rs
  • execution_engine.rs
  • lib.rs
  • memory_buffer.rs
  • module.rs: 28a1de3
  • object_file.rs
  • passes.rs
  • support/
    • error_handling.rs: 8ecc815
    • mod.rs
  • targets.rs
  • types/
    • array_type.rs: f9cb692
    • enums.rs: eab5006
    • float_type.rs: 82c5cb1
    • fn_type.rs: eab5006
    • int_type.rs: 9c7d5ec
    • mod.rs: eab5006
    • ptr_type.rs: f9cb692
    • struct_type.rs: 28216b8
    • traits.rs: eab5006
    • vec_type.rs: 3ca44a2
    • void_type.rs: ee692cb
  • values/
    • array_value.rs e4fc903
    • basic_value_use.rs
    • call_site_value.rs: ff941af
    • enums.rs
    • float_value.rs
    • fn_value.rs
    • generic_value.rs
    • global_value.rs
    • instruction_value.rs
    • int_value.rs
    • metadata_value.rs
    • mod.rs
    • phi_value.rs
    • ptr_value.rs
    • struct_value.rs
    • traits.rs
    • vec_value.rs

• Tari's example converted to Inkwell in the README
• Google Sheet Notes on what is or isn't supported yet: link
• Complete a brief (general overview) CHANGELOG.md for 0.1.0
• Kaleidoscope example
• Docs on GH pages: https://thedan64.github.io/inkwell/

[71]

I'm currently working on the Kaleidoscope tutorial using Inkwell, and I think it would make a great self-documenting example. Any chance this would get added to the repo, once it fully works?

[TheDan64]

Definitely! I was actually thinking the same thing. I just cant decided if it should be a test or if it should live as its own binary in a /examples directory. The former has the advantage of being run in every build, so we can easily ensure it compiles every time. But the latter has the advantage of being more easily noticeable when someone is browsing the repo or root directory. They can also build it themselves and try it out if we add a simple CLI.

For reference, the example in the readme is also duplicated as a test but I think it's small enough that it isn't a big deal. A Kaleidoscope example would be much larger, for sure. I will add Kaleidoscope to the checklist in the original post.

[71]

I think living in the /examples directory is definitely a plus. Furthermore, cargo test automatically compiles examples without running them (or at least can be configured to do so), which removes this problem.

I'm actually almost done with the first three chapters of the tutorial: the basic lexer, parser, and compiler are more-or-less working.

[TheDan64]

Oh neat, I didn't know that. Let's do that then. You can put it in /examples/kaleidoscope

[Michael-F-Bryan]

Are there any plans on getting Travis to upload docs for master to GitHub Pages after every commit? It'd probably make hacking on the repository or importing inkwell directly from git a lot easier.

As an example, this is what we've got set up for mdbook.

[TheDan64]

No, I've never even thought about doing this as I am not really familiar with how github pages work.

That said, it does sound like an excellent idea, so thanks! I'll add it to the above checklist and try and prioritize it.

So if I understand correctly, you're basically committing the docs from cargo doc to the gh-pages branch? And GH pages will automatically host that?

Could you also clarify how it would make importing inkwell from git easier?

[Michael-F-Bryan]

So if I understand correctly, you're basically committing the docs from cargo doc to the gh-pages branch? And GH pages will automatically host that?

Yep. Essentially everything in the gh-pages branch will be served up by GitHub Pages automatically. You do need to generate an API token (I'm pretty sure you need the public_repo permissions) to allow Travis to push stuff to github though.

I recently found out Travis made the process even easier by adding the GitHub Pages provider.

deploy:
  provider: pages
  skip-cleanup: true
  github-token: $GITHUB_TOKEN  # Set in travis-ci.org dashboard, marked secure
  keep-history: false  # this tends to really bloat your .git directory with useless docs churn
  local-dir: target/doc/
  on:
    branch: master

---

Could you also clarify how it would make importing inkwell from git easier?

Having access to an online version of the docs is useful when you need to link to things or want to browse the docs without needing to run cargo doc --open from the command line. As someone who doesn't mind trying out bleeding edge crates, it's nice to be able to browse a library's API before downloading it.

That said, this looks like a really cool! I'll try it out for a toy programming language I've been making in my spare time and see if there's anything I can do to help out.

[TheDan64]

Thanks for all this helpful info! I will be sure to look into doing this! And any assistance you can provide would be greatly appreciated.

[Michael-F-Bryan]

I thought I'd make a more in-depth guide to using inkwell for making programming languages. It's not as simple as @6a's kaleidoscope example (I want to briefly mention parsing with lalrpop and linking to C libraries), but it'll probably serve as a good example of how to use inkwell in a wider program.

Depending on how far I get, it may be a useful link to add to inkwell's README.

[TheDan64]

That is super cool! Please feel free to file issues for any stumbling blocks you find along the way.