Closed jasedit closed 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.
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.
For a more concrete example, the python wrapper I'm working on is available here, and currently can convert strings or files using libMultiMarkdown.
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.
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.
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.
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.)