One thing to be discussed is whether to pull in the full boost library or individual component libraries.

@steampunkkoala are you free and interested to help finish this?

I am happy to try and help, though I will probably not have any time to really look it to till latter next week.

pulling all of git as done makes the work of getting this working easier, it also make adding new libraries easier as everything is already there.

When I played with it a little before I pulled in the whole thing. The huge downside is that boost is massive so you increasing the download size and size on disk having the history of libraries that are not needed.

I think if we can get it just to the libraries that nano uses, then it is less of a burden to people who are playing with the source.

The boost download seems to be in the order of 75MB, not small but also not forbiddingly large.
The increased compilation time is a bigger concern.
But it if it only has to be built once, and if we can avoid building unnecessary boost libraries e.g. python then it should be OK.

if I clone https://github.com/boostorg/boost.git recursively on my windows machine.
Size: 1.77 gb
Size on Disk: 15.7gb

not sure how you got it to be 75mb

if you do not have it as a submodule and add a fixed downloaded version that might take a smaller amount of size

I didn't notice the huge number of submodules. Hmm, 2GB is a lot.

Doing a bit of research it seems git sparse-checkouts might be a solution for this. https://stackoverflow.com/questions/4114887/is-it-possible-to-do-a-sparse-checkout-without-checking-out-the-whole-repository

I might be wrong, but I can not see a way to do this for a single submodule, sparse seems to be everything or nothing. There might be way to get people to get the project no recursive then run a script to get the sub modules.

This seems like it has lots of possible errors there.

Unless you know an easy way to make a submodule sparse by default.

How open would you be to just have the files that are needed in a boost directory the same as if it was a submodule, but added directly to the project, so not everything and no boost history?

I am leaning towards:

• pointing to a release boost tarfile (which ideally would be hosted on an archive server that we control, although it is OK to point to external sites as well, external sites add the risk that we want to be able to go back in time and guarantee that we can build past releases without meddling)
• downloading it
• installing in a local folder
• building it just once
• using the local copt of boost by setting BOOST_ROOT

I have done this in:
https://github.com/dsiganos/nano-workspace.git

The reason why I like adding the file directly in is that it is smaller then having it as a submodule, which look at boost is huge. Trying to move boost out of the code project is a waste of time and resources and does not solve anything.

Your solution will work, it does not mean using it as a sub module so not using a huge amount of space. If you have multiple copies of the nano source code, then you have only one copy of boost and only have to compile it once which is good.

The downside is that you are adding extra steps to new users, which can cause more points of failure. The other issue is that you are not controlling the version of boost that is being used, if there is any negative change, or an older version that is not fully compatible a user could be using that.

I personally like to know what exactly is being used to be built, but your project you get to choose.