search

ltfat / libltfat

Backend library for LTFAT
http://ltfat.github.io/libltfat
GNU General Public License v3.0
12 stars 2 forks source link

Backend lib to separate repository? #2

Closed susnak closed 8 years ago

susnak commented 8 years ago

From @susnak on January 7, 2016 12:57

There seems to be an increasing demand for interfacing the backed library directly (e.g. ltfatpy and others).

Would it make sense to move the backend library (basically just the src dir) to a separate repository? Something like https://github.com/ltfat/libltfat Then it would be able to live an independent life. We could include it back to the ltfat repository as a git submodule https://git-scm.com/book/en/v2/Git-Tools-Submodules

(More) Advantages:

Separate issue tracker

This should force me to (finally) write documentation and polish things more.

We could branch and version the library separately.

Disadvantages:

git cloning needs another parameter.

We would have to implement some things which are Matlab-only now (e.g. firwin etc.) (and maintain compatibility) just to make the library usable.

Copied from original issue: ltfat/ltfat#52

susnak commented 8 years ago

From @jvnv on January 7, 2016 18:30

I think it definitely makes sense. I vote for it!

In case you decide to separate the backend library, is there something with which you need some help?

susnak commented 8 years ago

From @psoenderg on January 7, 2016 22:45

Sounds like a good idea. Everything is also prepared for that, as the backend can be build as a standalone library. Go for it!

susnak commented 8 years ago

Ok, now it seems there are two options how to do that: git module and git subtree I have to read more about that.

susnak commented 8 years ago

So subtree seems to be a better choice. Most importantly, no extra git commands are necessary for the basic usage i.e. clone, push, pull commands work as before.

Basically src/ and the new libltfat repository behave like separate repositories and they could both be contributed to, but the changes must be synchronized (by us) using git subtree push and pull. E.g. if someone contributes to the new libltfat repository, it will not automatically update src/ in ltfat repository. We must do (from within the ltfat repository) git subtree pull and commit (and push) the merge.

The only limitation this approach brings is that we must avoid doing commits which change stuff in src/ AND elsewhere simultaneously (since the new repository knows only stuff in src/). Which is not that hard to do.

In src/, there is still some stuff which is not relevant to the backend library itself e.g. configure.ac checks for mkoctfile and portaudio, the makefiles use MATLABROOT patch and the destination for the compiled library is hardcoded to ../lib etc. We have to get rid of it somehow. Meanwhile, use the libltfat/ltfatcompat branch.

You do not have to change your setting in any way.

The following commands are basically just for me (or anyone who will do the synchronization):

Create alias for the new remote in your local ltfat clone git remote add -f libltfat git@github.com:ltfat/libltfat.git (or use HTTPS version of the address) and use git subtree push --prefix src/ --squash libltfat ltfatcompat to push changes form ltfat/src to libltfat and git subtree pull --prefix src/ --squash libltfat ltfatcompat to get the remote changes.

Here is a nice tutorial https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec#.wnfbh08r9

susnak commented 8 years ago

The following should now work: git remote add -f libltfat git@github.com:ltfat/libltfat.git git subtree push -P libltfat --squash libltfat master git subtree pull -P libltfat --squash libltfat master