Allow for C-style dynamic libraries to be produced

[gjtorikian]

I'd like to be able to use comrak for commonmarker, but before doing that this project needs to be able to generate a C-style dynamic library. This PR adds the crate-type necessary to do that.

[gjtorikian]

Actually some methods need to be exposed still (extern "C"), so consider this WIP.

[gjtorikian]

Before I continue I should ask @kivikakk whether this is even a desired change.

The main function is easy enough to expose, roughly:

#[no_mangle]
#[allow(unused)]
pub extern "C" fn c_markdown_to_html(md_char: *const c_char, options: &ComrakOptions) -> *const c_char {
    // Convert C string to Rust string
    let c_md = unsafe {
        assert!(!md_char.is_null());
        CStr::from_ptr(md_char)
    };
    let md = c_md.to_str().unwrap();

    let arena = Arena::new();
    let root = parse_document(&arena, md, options);
    let mut s = Vec::new();
    format_html(root, options, &mut s).unwrap();
    unsafe {
        CString::from_vec_unchecked(s).as_ptr()
    }
}

But I would need all the functions the current C library supports, including modifying nodes (append, prepend) and getting/setting attributes (fence_info, header_level=). Would you be okay with me exposing all of that within the lib?

[kivikakk]

Would you be okay with me exposing all of that within the lib?

Yes, absolutely! Thank you for starting this work. If we need to rejig some internals slightly for that to happen, that'd be fine too—it'd be lovely to have this usable through a C interface.

Some simple test harnesses around it will be necessary, but that could even be literally running the CommonMark spec through commonmarker with the Comrak backend.

[gjtorikian]

@kivikakk 👋 Hello!!! 👋 I'm back to finish this PR. 😆

In the time since I opened this PR, I've become marginally better at Rust FFI handling, so I've rewritten whatever garbage was previously here with some new thoughts.

I've added here a little Rust lib that exposes a few methods, defined in comrak.h. I've also added tests (via picotest) which show a proposal for how this API can be used. Happy to change any of these names/arguments/whatever—just dropping a basic outline of what I'm thinking about.

To be honest, the last time I tried doing this, I got horribly stuck on memory handling when exposing the Arena of nodes. If possible, I'd like to scope this PR to just basic option handling and direct Commonmark -> HTML rendering.

[kivikakk]

Hey Garen, so lovely to hear from you again 😊 This is awesome. I gave it a run (after overcoming my brief confusion at trying to cargo test the c-api stuff /o\) — it looks great, and the direction seems 💯. Very happy for this to go ahead! (And the smaller scope for this PR sounds good 👍)

[gjtorikian]

@kivikakk 👋 There are three tests failing oddly, which I will definitely address, but I believe this PR is ready for review in all other places!

[kivikakk]

This is looking awesome. Just from a quick look, a stray </table> at the end of one, and I think the --width option only applies when outputting CommonMark. (On my way to an appointment, will fix up myself if you don't by the time I'm back!)

[kivikakk]

I've pushed 0da84ed now 43382b2, which hopefully gets us all green on CI! ❤️

[kivikakk]

Rebased onto main. If you like the look of it as is, please feel free to merge! 🚀

[gjtorikian]

Thank you! It looks great. 😄

[kivikakk]

Awesome! Thank you so much & nicely done!