Re: [boost] [CMake] what to do now?

Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-14 12:40:03

On Thursday, April 14, 2016 at 11:11:44 AM UTC-5, Peter Dimov wrote:
>
> Paul Fultz II wrote: 
> >> bpm doesn't have a problem with cycles because it doesn't have a 
> separate 
> >> install step. 
> > 
> > However, bpm can't remove or update a library either. 
>
> It can remove, actually. Updating is not required because it only targets 
> a 
> specific Boost release and does not version libraries separately. 
>

How does it know what files are associated with which library? It seems more
difficult to figure that out installing all the libraries together.
 

>
> To remove a cycle without -f, you need to remove all libraries that 
> participate in the cycle in a single step, otherwise it complains about 
> not 
> being able to remove a library that is still being depended on. 
>
> > cget can auto install the dependecies as well. 
>
> Yes, that's what I was asking. 
>
> > Currently, it grabs dependencies listed in a requirements.txt file, 
> which 
> > it will do a `cget install` on everything listed there. 
>
> So you depend on the library maintaining up-to-date dependency information 
> in requirements.txt? Is this file cget-specific, or is it some existing 
> convention? 
>

It is cget-specific. Channels will provide a non-intrusive way to get
dependencies. Although, I don't think its unreasonable for a library to 
track
its own dependencies.
 

>
> > Test dependencies can be distinguished as well, so they are only 
> installed 
> > when doing something like `cget install --test boostorg/config`. 
>
> Yes, and then you need to decide f.ex. when removing Core do you allow it 
> while Config is still there, because this would break Config's tests but 
> they may not be needed anymore. 
>

This is a good point. The test dependencies shouldn't be tracked as 
dependants
when they are installed. This way when a test dependency is removed it won't
remove the package that was used test with it.
 

>
> The alternative is to track Config and "Config's tests" as two separate 
> modules which immediately solves the cycle but has other drawbacks. 
>
>
> _______________________________________________ 
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost 
>