Is there any roadmap to install MetaToolkit as Library ( aka: make install ) ??
(Sorry for the slow response.)
Not yet, but it’s something that we should definitely look into. Would you mind creating an issue on the Github repo for this?
I suspect this is mostly just adding
install() commands to the
CMakeLists.txts, but we’ll also have to think about things like application naming (we probably can’t install
/usr/bin, for example).
Course yes, I’ll open an issue on Github.
As a start could we look to build and install an so (server object) omitting the tools. I would like to help but not sure where to start.
Still, I"m not so much worried with binary(executable) names, since this is not the main focus for the usage as library.
Main focus should be to deploy the headers and llbmeta.so with the API to be used on other projects.
I’ve forked master on my user and configured the install(DIRECTORY) for headers ( usr/local/include/meta ) and the Libraries (also under a “meta” folder (ie: /usr/local/lib/meta/libmeta-parser.a …). I’ll do some tests yet before any pull request…
Well… Just to update…
I’m still having some problems with meta dependencies (deps). Right now I’m doing with linking problems with icu_tokenizer
Meta is attached to those dependencies in a very ‘special’ way. I just can not install all dependency libraries in the host system due to an "make install’. I’m thinking if this is an opportunity to do some refectory on Meta, may to be more based on boost (standard) libraries instead of things like “cpptoml” (or even Poco). Or just to document those dependencies as other installations …Or, even better, “port them” (and later even meta) as conan.io dependencies. I think conan.io is the best solution for dependencies and libraries… but I’d like some other opinions about it…
Just a heads up to those of you interested in this: I’m going to start looking closely at this as my next big issue for me to tackle in MeTA. The goal for now will just be to allow installation of the header files and the library files (either as static or shared libraries).
It turns out most of our “dependencies” (in the
/deps folder) are actually only build-time dependencies.
cpptoml are the only ones we really need to have around when using the library itself.
cpptoml is super easy to work with since it’s just a single header file (and I am upstream, so I can do whatever needs to be done on that to make it easy to work with here).
icu is another beast, but I’m thinking a reasonable solution for now is to just force it to be statically compiled into
meta-utf, which is the only place it is used explicitly anyway. I may need to refactor the headers a bit, but I think I can make it work so that the
icu includes are only a build-time dependency and the actual library calls can be statically compiled into
meta-utf.so. I would just sidestep this issue, but MeTA really depends on having a fixed version of ICU, since ICU version changes also change the internal Unicode standard implemented, which changes the behavior of e.g. word breaking (which changes our tokenization).
…and I think this is working now!
I’ve only done some rudimentary testing (on Linux), but it seems to be working for me.
To consume the installed CMake configs for MeTA, you’ll also need to install cpptoml from here: https://github.com/skystrife/cpptoml
But your standard
make install should do the trick now! You can then use MeTA from CMake just like most other config-based packages:
find_package(MeTA 2.4 REQUIRED) add_executable(my-program src/my_program.cpp) target_link_libraries(my-program meta-index) # or whatever other libs you need from MeTA
EDIT: I should clarify that this is only on the
develop branch for now, but will make it to
master in the next release.