-
Notifications
You must be signed in to change notification settings - Fork 3
Description
@mjscosta You asked me to take a look at your template some time ago. So far, I've only gone through the README files and wanted to share some thoughts. This is a very impressive template from which I learned several new things. I'll check for more details later.
There are just a few things I would do slightly differently, but your use case may be different. I'm just mentioning it, in case it may make sense for you:
-
I could not derive the following from the CMakeLists.txt file, so this is a guess. It seems that you are not installing the tests, which I would recommend. Whenever a user of some library or program runs into a problem and opens an issue, it is convenient that every installation also contains the tests. You can then provide very simple instructions for the user to run the (unit) tests as a first diagnosis.
-
I would add support for Cython, next to PyBind and Swig. (I tend to prefer Cython because it allows one to build Pythonic wrappers around C++ code, and because it offers more features than PyBind and Swig.)
-
I've tried to work with the cookiecutter before but I wonder how one can update (without too much trouble) a project later when the template repo is improved? An alternative (or complement) to using a cookiecutter template is that one tries to put as much template features as possible into a build tool, e.g. like Bazel. Updates in such a build tool are the more easily adopted downstream.
Feel free to close this issue anytime. These are just some loose thoughts, not really issues.