Configure USE_GITHUB to download submodules?

Is it possible to configure USE_GITHUB to download submodules during fetch? Submodule directories in the GitHub code checked out by USE_GITHUB are empty, which causes an error.

The upstream project initializes the submodules like so
Bash:
git submodule update --init
after checking out a particular revision.
 
Usually a "reasonable" upstream would provide a dist file for each release containing the necessary submodules (assuming that those are not dependencies supposed to be managed by the package manager).
Check for such a dist file first. Whenever upstream provides a dist file, that is preferred over USE_GITHUB.

Other than that have a look at GH_SUBDIR and GH_TUPLE.

Edit: zirias@ was slightly faster.
 
The project in question is google/snappy. The /thirdparty subdirectories are empty in the dist file (https://github.com/google/snappy/archive/refs/tags/1.1.10.tar.gz).

So the alternative is to add an additional GH_ACCOUNT, etc. (or GH_TUPLE) for each submodule and set GH_SUBDIR to the directory where a recursive clone would have put them? Can I rely on the GH_ACCOUNTs being extracted in order (i.e. know that the snappy directory structure will already be there if I put it first in the list so that the submodules have a place to go)?
 
The project in question is google/snappy. The /thirdparty subdirectories are empty in the dist file (https://github.com/google/snappy/archive/refs/tags/1.1.10.tar.gz).
Anything in archive/refs is not a proper distfile but auto-generated by github from the repository, that's exactly what USE_GITHUB fetches (just using a different filename). So, in absence of a real distfile,
So the alternative is to add an additional GH_ACCOUNT, etc. (or GH_TUPLE) for each submodule and set GH_SUBDIR to the directory where a recursive clone would have put them?
exactly.

Can I rely on the GH_ACCOUNTs being extracted in order (i.e. know that the snappy directory structure will already be there if I put it first in the list so that the submodules have a place to go)?
Yes. Use a group name for each submodule, just not for the main source (so it's automatically in the default group).
 
Look at https://git.wilbury.net/otis/FreeBSD-ports/src/snappyarch/archivers/snappy-java

I've started the work, it actually builds up to:

Code:
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::          UNRESOLVED DEPENDENCIES         ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: org.xerial.sbt#sbt-sonatype;3.9.21: not found
[warn]  :: com.github.sbt#sbt-pgp;2.2.1: not found
[warn]  :: com.typesafe.sbt#sbt-osgi;0.9.6: not found
[warn]  :: org.scalameta#sbt-scalafmt;2.5.2: not found
[warn]  :: com.github.sbt#sbt-dynver;5.0.1: not found
[warn]  :: org.scala-lang#scala-library;2.12.18: not found
[warn]  :: org.scala-lang#scala-compiler;2.12.18: not found
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::


This has to be fixed (I don't have any Scala and/or sbt insight myself).
 
Back
Top