fletcher / MultiMarkdown-5

Reference implementation of MultiMarkdown; replaces MultiMarkdown v4 (deprecated -- see MMD-6 instead)
https://github.com/fletcher/MultiMarkdown-6
Other
294 stars 46 forks source link

Make libMultiMarkdown a shared library for external reuse. #33

Closed jasedit closed 8 years ago

jasedit commented 8 years ago

This PR alters the build structure of MultiMarkdown slightly to make libMultiMarkdown a shared library used by the multimarkdown executable. The shared library and header can be used in other tools to provide the MultiMarkdown conversion functionality (e.g. a python interface.)

fletcher commented 8 years ago

Can you be more specific about what you're trying to accomplish? There is already a libMultiMarkdown in the existing build structure, and it is used to create the multimarkdown executable.

jasedit commented 8 years ago

When I run the default cmake system, no shared library is generated for libMultiMarkdown. Instead, everything is statically linked into the multimarkdown binary. In order to build a python interface in a portable fashion, I need a shared library of libMultiMarkdown in order to interface using ctypes (portable c library interface.)

I also discovered in testing that libMultiMarkdown.h uses bool in a return function, but that isn't a default type in C99. Instead, that is defined in stdbool.h. In order to include libMultiMarkdown.h without compile errors in an external integration, stdbool.h has to be included beforehand, which seems to break encapsulation. So the other commit adds the include to libMultiMarkdown.h to simplify using the header.

jasedit commented 8 years ago

For a more concrete example, the python wrapper I'm working on is available here, and currently can convert strings or files using libMultiMarkdown.

fletcher commented 8 years ago

I mistakenly read "library" when you wrote "shared library." The makefile builds a static library, libMultiMarkdown.

I don't want the default make system to build a shared library -- I want a single binary, so a static library is the proper way to go. But it is true that cmake allows you to easily change this as needed for your own needs.

If you want to have something pulled into the official repo, I would suggest a combination of changes to Makefile and CMakeLists.txt that enables something along the lines of make shared in order to build a shared library.

jasedit commented 8 years ago

PR has been reworked to provide a make shared command which builds the shared library alongside the rest of the tool. multimarkdown itself remains a statically linked executable in this configuration.

fletcher commented 8 years ago

This worked fine on my Mac, but caused an error on a developer Linux VM I use (due to an older version of CMake that doesn't support the $<TARGET:OBJECTS> functionality). I see the usefulness of this approach, but don't want to break build on older cmake versions just to use it. And not sure it's really necessary for this project, since the source file list is already abstracted into a short list.

I tweaked your code a bit to just build separate libraries -- I realized this requires compiling the same code twice, but hopefully one would only be using this compile option rarely. I think, in this instance, backwards compatibility is more important.