Re: [boost] Link dependencies

Subject: Re: [boost] Link dependencies
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-12-05 13:22:38

On 12/3/2014 7:56 PM, Stephen Kelly wrote:
> Andrey Semashev wrote:
>> I imagine, when Boost gets
>> truly modular, one would download sources of the needed libraries
>> separately,
>
> That is explicitly a non-goal for Boost.
>
>   http://thread.gmane.org/gmane.comp.lib.boost.devel/254635
>
> If you want your imagined scenario to result in a new reality, start by
> making that a goal for boost. If you don't do it, no one will :).

I believe that Boost should pursue the goal of allowing individual 
libraries to be downloaded and used without having to download the 
complete Boost structure.

A couple of things however I will mention in my usual list-like way:

1) The people who are interested in this goal have to be willing to "get 
together" and discuss this in a calm and rational way in order to come 
up with a solution. This is not going to be easy and those who want to 
be involved need to take their time with it and not work in some sort of 
panic mode. This means everyone needs to back off the rhetoric and 
carefully consider possible solutions. I have my own ideas and I am sure 
a number of people also have their own ideas, so people need to be 
tolerant of individual solutions. If enough people agree on a particular 
solution it can be done by those people. There should not be any 
pressure on anybody to work on the solution since it is almost ceetainly 
going to be much effort.

2) Allowing individual libraries to be used, rather than current 
monolithic Boost, is being done for the end-user community. We need to 
make the goal that the way of doing this is as simple for the end-user 
as possible, no matter what has to be done underneath to get everything 
to work properly. If we make things arcane at all for the end-user the 
efforts will be a failure, no matter how clever we think we are. The 
end-users are not Linux gurus or Windows gurus or Mac gurus. They are 
simply programmers wanting to use individual Boost libraries for their 
programming efforts. Assuming guru status and telling them to follow a 
complicated menu of items just to get an individual library and its 
dependencies working correctly, which Boost developers themselves might 
accept, is not going to work with with individual end-user programmers 
or programmers in corporate America.

3) Modular Boost with Git has already been a success over the previous 
SVN system. As someone who previous to the move knew next to nothing 
about Git and has had the usual beginner's problems with it I think I 
can say unequivocally that it is a much better system than previously. 
So let's not spend time carping over that choice.

4) We should probably just start with proposals, preferable published on 
Github. Whoever has a proposal specifies what it is in whatever general 
terms or detail terms he chooses. We can say that proposals should be 
made within some time period, let's say within the next three months. 
After which people who are interested can discuss the proposals and try 
to see if there is one that meets a fairly large consensus. If that is 
the case, then those who are part of that consensus can work together to 
make it happen. Endless discussions of "let's try this, no let's do 
that, no that is no good but maybe this will work or that will work, but 
if we could only do this or that, and if we used my tool everything is 
fine, or if we used X tool on the Internet it might fly, or Y 
development does this and Z development does that so why don't we follow 
their example etc." is not going to get us anywhere. The problem is 
complicated and we really need serious proposals and plans.

5) Even with a consensus plan it's very important that there is no rush 
or panic to getting i done and getting everything right. There is no 
time by which this must be done. Monolithic Boost is not a failure, it's 
just the single alternative we have now and it works. But if we can 
provide an alternative, of individual libraries and their dependencies 
being used without the necessity of all of Boost, I believe it would be 
greatly appreciated in programming shops where monolithic Boost is seen 
as an impediment to program development ( because of the large size of 
the directory structure, because many businesses have tight rules above 
3rd party software, because of the fear of too many dependencies or too 
fragile dependencies etc. etc. ).

6) I see the ability to use only individual subsets of Boost libraries 
as a worthwhile goal. This is not because I view monolithic Boost as a 
failure of any kind, or that I feel that the libraries that are part of 
Boost are not of the highest quality, but because I understand the 
impetus of programmer end-users who only want to deal physically with 
the libraries they actually use without the responsibility of even 
downloading libraries to which they are indifferent.