Suggestion - use git submodules or a separate git repo to build libbitcoin-server
coinnail opened this issue · 7 comments
Hi,
What do you think about using git submodules to state the dependencies between the libbitcoin projects or having a project to ease the way to build these projects?
Although git submodules don't seem the easiest think to manage I think they would provide a more easy way to build and test libbitcoin projects without having to manually recreate the folder structure required.
I created such project to build all projects (I wanted to build libbitcoin-server) with the required folder structure and a script to call build everything.
https://github.com/coinnail/libbitcoin-build
PS: I still haven't quite figure out how I can manage/choose which commit to reference in the reference repositories.
Did you try using the install.sh?
No since I'm Windows and I naively expected to just clone, open VS2017 and be ready to work. (Your build requirements are a little more complicated than of what I'm used to in .net)
I started this manly because I wanted to be easier to build libbitcoin-server with VS2017 and wanted to avoid manual steps to created the build environment. Install.sh and build.cmd scripts are fine but hide in "script code" the folder structure and the real dependencies which libbitcoin-server has to be built.
Anyway, I just wanted to check if you have thought about git submodules to reduce the complexity of the build environment for all projects. It would trade scripting, and documentation, maintenance for git submodules usage/maintenance.
I don't have a clear idea if it's a good trade-off so it's just a question if you have thought about it.
Sobmodules is not something I’m too excited about: https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407
The install.sh manages this process nicely for autotools builds, and we generate that so it’s easy and reliable. Until recently we only had VS2013 and no project generation. But now that we have that complete we could potentially automate the full vc++ get and build as well.
The most annoying part of it is the population of the local NuGet store. VS assumes that NuGet is a sub directory of the solution, which doesn’t work if you are building multiple libs. I’m contemplating creation of the NuGet directory structure and index within the libbitcoin-build repo. That way you could simply get all of the repos and build them from VS.
Once that it done, which should be simple, we can add generated installers (install.cmd) in each repo, mirroring install.sh. We already have something like this for the AppVeyor builds. We use install.sh for our Travis builds, which ensures it is always tested. We could probably do the same for an install.cmd.
Humm, yeah I also felt that might be more to git modules than what I was seeing at first.
Oh, I missed the libbitcoin-build project, cool thing!
The most annoying part of it is the population of the local NuGet store. VS assumes that NuGet is a sub directory of the solution, which doesn’t work if you are building multiple libs.
Is there a specific reason each solution can't reference it's own NuGet directory?
It wastes a few KBs of disk space but that's the only bad reason bad I see.
I’m contemplating creation of the NuGet directory structure and index within the libbitcoin-build repo.
Not sure what you mean by index, so I got lost in your response here.
Is there a specific reason each solution can't reference it's own NuGet directory?
Static linkage may multiply-import dependencies, causing a binary size increase and a risk from non-sharing of static state. Plus for 10 repos the update time is a big hassle.
I've resolved this in the latest builds, the nuget repo is automatically set up and usable in a central location. Should work right off the download and VS build of the solutions, though you will have to tell the first ones to update the repos via the VS NuGet GUI (or command line).
Not sure what you mean by index, so I got lost in your response here.
NuGet maintains an index as part of the repo, but turns out this isn't important.
Thanks for the replies, it seems that I can help much.
I was about to suggest some improvements to the readme but you have already done it xD
Kudos for you :)
Thanks for your inputs!