Re: bbv2-build exe without building dependants

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-23 09:32:04

Malcolm Cifuentes <malcolm_cifuentes_at_[hidden]> writes:

> David Abrahams <dave_at_[hidden]> wrote in
> news:ur7et1sq5.fsf_at_[hidden]: 
>
>> Malcolm Cifuentes <malcolm_cifuentes_at_[hidden]> writes:
>> 
>>> Hi all,
>>> is there any way to build an exe without bb actually trying to
>>> build its 
>>> dependants but still link against them?
>>>
>>> Example: 
>>> normally bb will :
>>> 1) find all dependant libraries
>>> 2) build libraries if required
>>> 3) pass libraries to linker 
>>>
>>> I would like the following workflow:
>>> 1. and 3.
>>>
>> 
>> How do you propose to link against a non-existent library?
>> 
>> or, are you saying that the libraries exist but are out-of-date, and
>> you want to link against them anyway?
>> 
>> There's no way to do the latter with Boost.Build. What's the use case
>> for this behavior?
>> 
> use case: using bb in a continuous integration model. 
>
> Continuous integration means every one on a project uses the same 
> include/library repository (located conveniently on one or more servers:) 
> This means a user releases a library/header and source to the repository 
> when they decide it is ready and all other users receive the changes upon 
> next compile/link. The user only builds what they are working on and not 
> what they depend on. I've used this system implemented in make and it 
> works well.

I don't understand. Someone has to produce the built libraries. If
the person "releasing" a library/header doesn't release a built
library at the same time as the headers, his users will produce
crashing programs until they are synchronized.

> The down side, is all dependancy management has been done by 
> mischievious means and it is error prone, 

There's a conspicuous lack of necessary detail here, but I think I
understand what you're saying.

> hence my desire to try and use bb to solve the problem.

Not sure just what the problem is yet.

It sounds like your users might not be using prebuilt versions of the
libraries, but instead referring to the library targets in other
Jamfiles. The best way to achieve what you want, it seems to me,
would be to have users depend on prebuilt libraries instead.

Boost.Build could really help with this model by implementing
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configuration_And_Installation
In short, when installing libraries, Boost.Build would generate a
Jamfile in the same directory that describes the built library
objects, their usage-requirements, and how they correspond to
variants, so users will get all the benefits of build propery
management that they enjoy when building dependencies.

> *- this is complex because it raises issues such as the user having 
> access to all the source repository with out requiring them to pull it 
> all into there work area. Of course the solution needs to work for 
> different platforms (i.e. win32, linux).
>
> Any ways, I guess I will slowly wittle away at it. Its obvious from this 
> post though that I need to better define what I want bb to do for me.

That is always helpful :)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com