Re: [boost] [EXTERNAL] [graph] Sync develop with master?

Subject: Re: [boost] [EXTERNAL] [graph] Sync develop with master?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-08-10 00:15:45

On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth <kbelco_at_[hidden]>
wrote:

>
> > On Aug 9, 2016, at 8:37 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> >
> > On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth <kbelco_at_[hidden]>
> wrote:
> >
> >> Well, it’s just more typing than I want to do though it’s fine for 3
> >> libraries, it doesn’t scale well for, say, 30 libraries.
> >>
> >
> > But you had to type it in some form at some point the way it was before
> > also, right?
>
> No, before I just removed blocks of libraries I didn’t want to test from
> the Jamfile.v2.  A few vi block deletes and I was ready to test.
>

You could get more creative with with what test you limit also. For example
to limit to all "a" libs you could do "--limit-tests=a". Or multiple ranges
like "--limit-tests=[a-c]". The arg is a simple regex so you might be able
to get clever enough to make it short.

> > b2 "--limit-tests=graph|graph_parallel|mpi”
> >>
> >> Could we add support for a comma separator, or change the vertical
> >> separator to a comma?
> >>
> >
> > Sure, I could add a comma separator. Would it also help if I added an
> > inverse? i.e. an "--exclude-tests" option?
>
> This could be useful.

I'll add it in because..

>   But let me see if I can articulate the use case I’m really after.
>
> I want to change some arbitrary piece of code in some library, and have
> some ability to test every library that depends on the library I just
> modified.

That is rather hard to achieve. And I'd have to think about how to do that.
As it would require some core b2 changes to pull off.

>   Now I can do this by running b2 from the status directory once up front,
> but that builds and tests everything once.  But once I have everything
> built, then modifying some piece of code and rerunning b2 from status will
> only test what’s out of date.  So that’s my current fall back.
>
> Granted my old hack of deleting libraries from status/Jamfile didn’t
> accomplish this use case either, but it was fairly easy to test a largish
> number of libraries.
>

Maybe another choice would be to modify the dependency tool to spit out a
set of options to use. I.e. you might run it like this:

b2 `boost-dep --limit-tests=my-lib`

And it would return the list of options for all the dependent libraries.
fo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost>

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail