[git-help] Doc. Suggestion: How to setup a custom boost "distribution"
This is a suggestion for documentation, that "could" not be a good idea, I'm not totally sure. The goal would be to provide a simple recipe to setup a boost super-repo fork that would contain only a specific set of libraries, chosen by the user. I believe it would be of interest to a lot of companies that consider using boost but don't want to have to use the whole package. As Ryppl isn't ready yet, I was thinking that just providing a way to do it using the fork would already be helpful. It would also allow some people to provide a well tested custom distribution that would be easy to keep up to date. I expect people to experiment such things (I think I will at some point). The goal is NOT to resolve dependencies, or detect dependencies issues. It would be only to show that you can strip down the count of libraries if you wish in your own fork. The user will have to deal with dependency issues on his own, which is ok in a lot of cases, I assume. However, I'm not a specialist and I will not have time to try my idea immediately so I would like to ask if the following process is enough to do achieve the goal: 1. fork boost super-repo (clone locally, clone on your own server, or use the github fork button); 1.1. optionally, switch to a company or project-specific branch name; 2. in the fork, to remove libraries you don't want: 2.1. go in the root directory and edit the '.gitmodules' file 2.2. in this file, you will see each library module defined as follow: [submodule "any-library"] path = libs/any-library url = ../any-library.git fetchRecurseSubmodules = on-demand 2.3. locate and remove these declarations of each library you want to remove from the fork. 2.4. save the file. 3. commit the change 4. [git pull ?] 5. compile boost as usual. I'm not sure about the 4th point, but I think an operation is necessary so that git removes the library directories in the local clone. If these instructions are correct (once 4 is confirmed) and complete and are considered useful, maybe putting them somewhere in the doc would be worthwhile. Thoughts?
On Wed, Jan 1, 2014 at 5:20 PM, Klaim - Joël Lamotte
This is a suggestion for documentation, that "could" not be a good idea, I'm not totally sure. The goal would be to provide a simple recipe to setup a boost super-repo fork that would contain only a specific set of libraries, chosen by the user. I believe it would be of interest to a lot of companies that consider using boost but don't want to have to use the whole package. As Ryppl isn't ready yet, I was thinking that just providing a way to do it using the fork would already be helpful. It would also allow some people to provide a well tested custom distribution that would be easy to keep up to date. I expect people to experiment such things (I think I will at some point).
The goal is NOT to resolve dependencies, or detect dependencies issues. It would be only to show that you can strip down the count of libraries if you wish in your own fork. The user will have to deal with dependency issues on his own, which is ok in a lot of cases, I assume.
However, I'm not a specialist and I will not have time to try my idea immediately so I would like to ask if the following process is enough to do achieve the goal:
1. fork boost super-repo (clone locally, clone on your own server, or use the github fork button); 1.1. optionally, switch to a company or project-specific branch name; 2. in the fork, to remove libraries you don't want: 2.1. go in the root directory and edit the '.gitmodules' file 2.2. in this file, you will see each library module defined as follow:
[submodule "any-library"] path = libs/any-library url = ../any-library.git fetchRecurseSubmodules = on-demand
2.3. locate and remove these declarations of each library you want to remove from the fork. 2.4. save the file. 3. commit the change 4. [git pull ?] 5. compile boost as usual.
I had to do the following to remove a library: # Removes the superproject's submodule reference and the contents of the library directory (but not the directory). git submodule deinit libs/<any-library> # Remove the directory. git rm -fr libs/<any-library> # Edit the .gitmodules file to remove the submodule <any-library> section. # Commit the changes to remove library. git commit -m"Remove <any-library>." -a
I'm not sure about the 4th point, but I think an operation is necessary so that git removes the library directories in the local clone.
If these instructions are correct (once 4 is confirmed) and complete and are considered useful, maybe putting them somewhere in the doc would be worthwhile.
Thoughts?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2 January 2014 05:39, Cox, Michael
I had to do the following to remove a library:
My version of git (1.8.5.2) seems to do everything with just 'git rm'. Although I didn't see any mention in the change log.
# Removes the superproject's submodule reference and the contents of the library directory (but not the directory). git submodule deinit libs/<any-library>
This is a fairly new feature (1.8.3), but not actually required in this case because the module hasn't been initialised. In older versions it can be done manually by removing the module's entry from '.git/config'. 'git rm' is required though, to remove the submodule entry in the index. It's a little different, but in the past I've used this process: https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial#Removal It's at the bottom of the page.
Ok I should have time to experiment with these recipes tomorrow and report here what I find simple and working.
participants (3)
-
Cox, Michael -
Daniel James -
Klaim - Joël Lamotte