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.