Try to link dynamically and exclude external software from repo

[bernt-matthias]

I would like to add this to conda (bioconda?). For this it would be cool to have this compile as shared objects and to exclude external software (which should be installed independent of this project .. also license files are missing).

TODO:

• exclude external header files (help needed)

Any help and suggestion welcome.

Motivation: Other projects e.g. start to use this software by copying the sources. This is file license wise but seems horrible it terms of maintenance and versioning.

[mhoopmann]

I think this is a good idea, but a lot of work needs to be done. A possible shortcut would be to create a fork and cut out the 3rd party tools (zlib, expat, sqlite).

BTW which license files are missing? zlib and expat are provided exactly as the authors intended (with license files intact), SQLite is public domain, and the rest is my code under Apache 2.0.

[bernt-matthias]

Could you enable github actions for this repo? Then we would have proof if cmake and compiling works.

I think this is a good idea, but a lot of work needs to be done.

What do you think is missing?

A possible shortcut would be to create a fork and cut out the 3rd party tools (zlib, expat, sqlite).

I would prefer not to maintain a fork :)

BTW which license files are missing? zlib and expat are provided exactly as the authors intended (with license files intact), SQLite is public domain, and the rest is my code under Apache 2.0.

Sorry, I have mistaken this with the other linked repo (sipros4). Apparently they use the same 3rd party software but removed quiet a few files.

[mhoopmann]

Ok, give me some time to get this repo organized and up-to-date. It's a busy time in the lab and I have a few other matters to resolve first, but I will get to this. We'll avoid the fork, and I'll get the repo organized and enable github actions.

[mhoopmann]

I'm only part way through the process, but the Restructuring branch is the current status. In brief:

1. External tools (zlib, expat) have been segregated.
2. Unused resources (sqlite, pepXMLwriter, mzMLWriter) were removed. SQLite was to support a format nobody uses anymore (or ever?). The other two tools are better served with more robust packages: NeoPepXMLParser and NeoMzMLParser
3. Visual Studio solutions/projects and GitHub Actions for building on windows have been added. The windows builds included dynamic linked library and static builds.
4. Two libraries are created on successful builds: MSToolkit is the main library with support for reading (and in some cases writing) data files. It must be linked with existing zlib and expat libraries on the host system. Should zlib and expat not exist on the system, or should the user not wish to link them, the second library, MSToolkitExtern, can be linked instead. When developing software, all MSToolkit classes are accessed via the include directory. If using MSToolkitExtern then also bind the include/extern directory, otherwise include the dev directories for zlib and expat wherever they exist on the dev system.

Still to go is creating new build instructions for Linux systems and GitHub Actions to test.

I think this will create the best options for all users. First, it should allow integration MSToolkit in tools that already have 3rd party packages included and not cause conflicts. Second, for lazy developers looking for a tool that doesn't require chasing down 3rd party packages, everything you need is still included here. Third, this should not break [much] existing tools; they can either link the 3rd party packages on their system, or link MSToolkitExtern to restore their builds. In other words, they would need only to minimally update their -I and -D compiler directives.

[mhoopmann]

Good template to build off of. Thanks!

[bernt-matthias]

Thanks for the efforts. Looks like an excellent way to go.

Still to go is creating new build instructions for Linux systems and GitHub Actions to test.

I think with this I could even try to add a recipe to conda-forge.