Target audience and distribution
mjvankampen opened this issue · comments
I was wondering what the target audience of protolib is? Is it only meant for consumers/developers of norm for example, or do you also want it to be used for other projects outside NRL?
Reason I ask is that I would like to put NORM in conan (if you guys are ok with that). I could make a norm packages that builds protolib (makes it harder for others to use protolib) or make a separate package out of protolib. I would prefer the latter, it looks like you made a nice lib/kit here.
Only thing I would do is add a kind of stable API indication, sometimes it is hard to see what is current, what is draft, what is deprecated. Not sure as I haven't used the lib yet, but setting up cmake it was sometimes hard to see what is what.
That's a good question. Mostly it's just been me using Protolib for my NRL projects with a couple of other people in our group. We did add Java and Python bindings to the ProtoPipe class as a convenience for interprocess communication among our applications and controllers, etc. Recently, I have been thinking about a Python binding to the ProtoTree, etc data structures as they are useful and provide some unique features. So, generally we have tended to "bundle" Protolib, linking it in as a static library into the NORM, MGEN, SMF, OLSR, etc in the interest of making sure the right version is packaged, easier download, build, and use. As I mentioned in the description notes, we use it as more of source code toolkit than a bona fide library. I agree some version control indications would be needed to help make Protolib more useful as an independent entity. My development on Protolib tends to focused on the specific thing I am doing at the time with respect to feature additions, changes, etc. Since it is used on a modest number of projects I've been able to test to make sure I didn't break anything important at the moment and get away with that approach so far. Having it on GitHub helps and I need to get better about using branches and keep the 'master' safe and stable.
Ok, so I think it is better to consume it as you do now. So don't publish it as a separate library for general use but bundle it with things like NORM.
@mjvk - FYI - I have Protolib included into the NORM git repository as a submodule. I plan to do similar with the other Protolib-based projects. If, at some point, the Protolib "toolkit" is extended to have a more formal API or there is sufficient demand for managing it as a library, I am happy to revisit this. I agree with your idea that the installation should install the header files in a "include/protolib" or "include/protokit" directory if get installed as a development library.
FYI, if you switch NORM and others to cmake, you don’t need to use submodules. Cmake has an ExternalModules feature that can download from url or source code repo. Nice advantage is that you can have, for example, release tarballs and the build will pull down those sources automatically (where submodules only work if cloning from git).