libpyin icon indicating copy to clipboard operation
libpyin copied to clipboard

Do not use submodules?

Open nils-werner opened this issue 5 years ago • 3 comments

This is an antithesis to #6 point 1 and a discussion starter.

Using submodules for this kind of dependency management is a little bit controversial, because it has significant drawbacks if your dependency tree becomes more complex. i.e. if you have three libraries and their dependencies

  • libA
    • libB
    • libC
  • libB
    • libC

libA and libB would both need to have libC as a submodule in their filetree, which produces duplicate code, confusion about which submodule is used, and potential conflicts if the dependencies do not match up exactly.

As an alternative, a flat directory structure with both libpyin and libgvps on the top level can be used. This is how UNIX systems manage their /usr/lib content. In this case the path in Makefile would read

GVPS_PREFIX = ../libgvps

and the installation instructions in README would read something like

git clone https://github.com/Sleepwalking/libpyin.git
git clone https://github.com/Sleepwalking/libgvps.git
cd libpyin
make

compared to

GVPS_PREFIX = external/libgvps

and

git clone https://github.com/Sleepwalking/libpyin.git
cd libpyin
git submodule update --init
make

nils-werner avatar Jan 22 '20 08:01 nils-werner

Hello,

Thanks for the suggestion.

As an alternative, a flat directory structure with both libpyin and libgvps on the top level can be used. This is how UNIX systems manage their /usr/lib content.

We actually have something similar among Dreamtonics' private repos. It is used for building the synthesis backend, which has a dozen of components. Unfortunately that also contains a few internal libs so we can't release it.

However, the current libpyin along with other speech processing libs I created (e.g. libllsm2, liblrhsmm) are tuned for this kind of flat configuration. With some small efforts you can create a "packaging" repo with all dependencies included as submodules, without modifying these existing libs.

Here's an example of the packaging makefile.

TARGETS = build-a build-b build-c
DIST = /usr

build-a:
	cd a  && make $(DEPS) $(CONFIG) default && make PREFIX=$(DIST) install && cd ..

build-b:
	cd b  && make $(DEPS) $(CONFIG) default && make PREFIX=$(DIST) install && cd ..

build-c:
	cd c  && make $(DEPS) $(CONFIG) default && make PREFIX=$(DIST) install && cd ..

Hope it helps.

Sleepwalking avatar Jan 22 '20 10:01 Sleepwalking

Just now I realized that readme hasn't been updated. There used to be submodules, but they are gone in https://github.com/Sleepwalking/libpyin/commit/a0803ed17fd74dddf7dea228a51197dc2f5c6180. Sorry for the confusion.

Sleepwalking avatar Jan 22 '20 10:01 Sleepwalking

OK, so you don't really want to use the submodules structure anymore? I can adjust my PR #6 accordingly.

nils-werner avatar Jan 22 '20 13:01 nils-werner