From: Malcolm Cifuentes (malcolm_cifuentes_at_[hidden])
Date: 2005-06-23 22:15:32
David Abrahams <dave_at_[hidden]> wrote in
> Malcolm Cifuentes <malcolm_cifuentes_at_[hidden]> writes:
>> David Abrahams <dave_at_[hidden]> wrote in
>>> 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?
>>>> 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.
crashing programs is what you get if u r lucky. Users allways release
the library and required headers at the same time, buts its when
dependant libraries (build system does not do this in one step) are not
rebuilt life becomes difficult. Typical example may be library b depends
on a. A user changes the interface in a and releases it to all users.
The user must also release b. There are safe guards to protect you so
you can verify that your build is indeed synchronized, but I'm hoping bb
will be able to turn it into a non-existant problem:)
Ideally when a user releases a library I would like bb to re-release all
dependants. I don't think bb is designed to do this so a more natural fit
maybe to do this during the exe stage. This would require bb to look in
the release structure for the libraries, source, Jamfiles and what ever
other information is required to perform this feat.
>> 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.
yeh, I've given you the equivalent of about 1/8 the alphabet, and sort of
hoped you can fill the rest in, you have done well:)
>> 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
> ation_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.
ah, this looks close to what I want.
I'm still not sure how information on the Wiki is stored. I can only
find the Page you referenced by looking in [index of all pages] list.
Is there another index that people use that uses some sort of
categorisation that is adhered to?
>> *- this is complex because it raises issues such as the user
>> 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 :)
thanks for your feed back
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk