I created a script that downloads the git submodules as this:
The script “prepare_snap.sh” contains commands:
git submodule init
git submodule update
I can see in build logs that it does download the submodules just fine, but then it start building the application in forlder parts/application/src which was created before the download of submodules and so it doesn’t work
How to do that properly?
Did you find a solution for this problem?
I have also a repository with multiple submodules, and during the cmake process, it fails to find some other included cmake files (included in the root cmakelists.txt) so I assume that during building the submodules are not initialized.
This is the package I mentioned above: https://build.snapcraft.io/user/OpenMapper/OpenMapperDesktop/59235
Have a look at the
source-type option in Common source options.
If you set that to
git it will run
git submodule update --init --recursive --force on the source.
I did that, unfortunately, snapcraft still fails when building this package. failing build
I tried to put all submodules in a repository i.o. to localize the problem and it builds now
Though it should possible as @Saviq said.
After applying the patch below, your snap builds fine here?
diff --git a/snap/snapcraft.yaml b/snap/snapcraft.yaml
index 1d8acec..d6e0467 100644
@@ -13,6 +13,7 @@ apps:
application: # part name can take whatever identifier one likes.
# See 'snapcraft plugins'
+ source-type: git
I added the tag:
source-type: git to my yaml file, it did not help.
It still does not find the other cmakefiles.
But I made a second testing repo where I did not put only the main desktop app but also all other parts (whole libraries) instead of using submodules. There it works perfectly.
This leads to the assumptions that there is something wrong when pulling the submodules of a repository.
@Saviq Do you think that there is something wrong with this snap file ?
PS: In the second test repo the armhf build is failing because I do not this software is only intended for amd64, there is a bug report on this
I’ve found that this is probably a bug:
This seems to be solved now, It works on my repository with submodules…
Indeed, I rolled out the launchpad-buildd fix for that a couple of days ago.