Skip to content

Do not use submodules? #7

@nils-werner

Description

@nils-werner

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions