Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not use submodules? #7

Open
nils-werner opened this issue Jan 22, 2020 · 3 comments
Open

Do not use submodules? #7

nils-werner opened this issue Jan 22, 2020 · 3 comments

Comments

@nils-werner
Copy link

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
@Sleepwalking
Copy link
Owner

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
Copy link
Owner

Just now I realized that readme hasn't been updated. There used to be submodules, but they are gone in a0803ed. Sorry for the confusion.

@nils-werner
Copy link
Author

nils-werner commented Jan 22, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants