grzegorzmazur
commented
5 years ago Hi Andreas!
It's really good to have you here; having some insight from the point of view of a person who knows how to package software is really valuable.
Let me start from saying that the current scheme is the most convenient one for day to day development, and setting this up I've not thought at all about packaging. And it seems that I have to reconsider :)
The idea of git submodules sounds good, but given that I just use a particular version of the js libraries perhaps easier approach could do. How about if I just keep compressed tarballs of the libs in the (new) third_party directory and use ExternalProject_Add() the same way as now, but pointing to the local files? Or you're convinced that using submodules is just better?
With respect to the other point you've made, I'm afraid that it cannot really be done generally enough. Which version of mathjax is installed and where depends on a particular version of a specific distribution; preparing a package for it you can add mathjax as dependency and then remove the builtin mathjax and replace the builtin path with the system-wide one. The only way I can see to make this easier is providing a compile-time option which selects builtin or system-wide mathjax and modifies appropriate paths. But I can't see how it could be done completely automatically.
Cheers, Grzesiek
as seen in
cyacas/yacas-gui/resources/CMakeLists.txtFor distribution, all file manifests need to be known to the package manager. A package can not be allowed to download files during the build process, and most packaging environments will actively forbid network access.
With git, you could look into providing the necessary external packages as submodules, however, preferably not without checking for available system packages (at least mathjax should be available on most distributions).
A release tarball however would need to bundle these files instead of trying to download them via build system.