[graph] Sync develop with master?

older
[thread][circular_buffer] Unmerged...

Murray Cumming

30 May 2016 30 May '16

9:37 a.m.

Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release. -- Murray Cumming murrayc@murrayc.com www.murrayc.com

Show replies by date

Belcourt, Kenneth

30 May 30 May

7:43 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On May 30, 2016, at 3:37 AM, Murray Cumming wrote:

...

Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release.

Thanks for the reminder.

Murray Cumming

28 Jun 28 Jun

9:31 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Mo, 2016-05-30 at 19:43 +0000, Belcourt, Kenneth wrote:

...

On May 30, 2016, at 3:37 AM, Murray Cumming wrote:

...
Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release.

Thanks for the reminder.

To help, I tried doing a simple git merge --no-ff develop from the master branch. I think that's what boost's git workflow dictates. Here is the result: https://github.com/murraycu/graph/tree/master-murray-merged-from-develo p There was only one tiny whitespace conflict that I had to correct manually. Unfortunately, it has a big "merge" commit, which I find messy, but maybe that's normal with this workflow: https://github.com/boostorg/graph/commit/7891f415171a053c88bfcd84db0c87 e5175d0fbc I've tried to create a github pull request for this merge to master, in case that's helpful: https://github.com/boostorg/graph/pull/72 -- Murray Cumming murrayc@murrayc.com www.murrayc.com

Belcourt, Kenneth

5:32 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Jun 28, 2016, at 3:31 AM, Murray Cumming wrote:

On Mo, 2016-05-30 at 19:43 +0000, Belcourt, Kenneth wrote:

...
On May 30, 2016, at 3:37 AM, Murray Cumming wrote:

...
Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release.

Thanks for the reminder.

To help, I tried doing a simple git merge --no-ff develop from the master branch. I think that's what boost's git workflow dictates. Here is the result: https://github.com/murraycu/graph/tree/master-murray-merged-from-develo p

There was only one tiny whitespace conflict that I had to correct manually.

Unfortunately, it has a big "merge" commit, which I find messy, but maybe that's normal with this workflow: https://github.com/boostorg/graph/commit/7891f415171a053c88bfcd84db0c87 e5175d0fbc

I've tried to create a github pull request for this merge to master, in case that's helpful: https://github.com/boostorg/graph/pull/72

Thanks, I’d prefer to cherry-pick the individual commits so I can test them against master. The recent changes to the testing infrastructure has slowed this down as it’s now less-convenient to test that it was previously. Appreciate the ping. Noel

Murray Cumming

9 Aug 9 Aug

11:21 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Di, 2016-06-28 at 17:32 +0000, Belcourt, Kenneth wrote:

...

Thanks, I’d prefer to cherry-pick the individual commits so I can test them against master.

Thanks. I see that master is now almost exactly the same as develop.

...

The recent changes to the testing infrastructure has slowed this down as it’s now less-convenient to test that it was previously

Is this something different than this? https://github.com/boostorg/graph#running-tests Are you waiting for the 1.62 release to happen without problems before letting more code into develop? In general, I'm interested in modernizing the BGL code, requiring at least C++11 and possibly C++14, which would significantly simplify the code. -- Murray Cumming murrayc@murrayc.com www.murrayc.com

Belcourt, Kenneth

5:28 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Aug 9, 2016, at 5:21 AM, Murray Cumming wrote:

On Di, 2016-06-28 at 17:32 +0000, Belcourt, Kenneth wrote:

...
The recent changes to the testing infrastructure has slowed this down as it’s now less-convenient to test that it was previously

Is this something different than this? https://github.com/boostorg/graph#running-tests

Related. I used to be able to edit status/Jamfile and remove all but a handful of libraries that I’d then test all together (so I could for example, test Graph, GraphParallel, MPI, etc.. all at once). The currently testing model doesn’t easily support testing multiple Boost libraries at one time and this slows me down.

...

Are you waiting for the 1.62 release to happen without problems before letting more code into develop?

No, life intervenes and I’ve been on travel.

...

In general, I'm interested in modernizing the BGL code, requiring at least C++11 and possibly C++14, which would significantly simplify the code.

This is certainly an upgrade worth discussing. I’m not convinced we should drop support for pre-C++11 compilers as I have several systems that I need to run BGL and other Boost libraries on that can’t upgrade to C++11 at this time. And I’d bet there’s other users in the same boat. —- Noel

Rene Rivera

5:57 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth wrote:

...

...
On Aug 9, 2016, at 5:21 AM, Murray Cumming wrote:

On Di, 2016-06-28 at 17:32 +0000, Belcourt, Kenneth wrote:

...
The recent changes to the testing infrastructure has slowed this down as it’s now less-convenient to test that it was previously

Is this something different than this? https://github.com/boostorg/graph#running-tests

Related. I used to be able to edit status/Jamfile and remove all but a handful of libraries that I’d then test all together (so I could for example, test Graph, GraphParallel, MPI, etc.. all at once). The currently testing model doesn’t easily support testing multiple Boost libraries at one time and this slows me down.

Did you see my response at the time you brought this up on the command line options that let you control that? (i.e. the --limit-tests= option) Just wondering as I'm willing to add support for what you need if what's there is not enough. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Belcourt, Kenneth

10 Aug 10 Aug

1:47 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Aug 9, 2016, at 11:57 AM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 5:21 AM, Murray Cumming wrote:

On Di, 2016-06-28 at 17:32 +0000, Belcourt, Kenneth wrote:

...
The recent changes to the testing infrastructure has slowed this down as it’s now less-convenient to test that it was previously

Is this something different than this? https://github.com/boostorg/graph#running-tests

Related. I used to be able to edit status/Jamfile and remove all but a handful of libraries that I’d then test all together (so I could for example, test Graph, GraphParallel, MPI, etc.. all at once). The currently testing model doesn’t easily support testing multiple Boost libraries at one time and this slows me down.

Did you see my response at the time you brought this up on the command line options that let you control that? (i.e. the --limit-tests= option) Just wondering as I'm willing to add support for what you need if what's there is not enough.

Hi Rene, 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. b2 "--limit-tests=graph|graph_parallel|mpi” Could we add support for a comma separator, or change the vertical separator to a comma? N.

Rene Rivera

2:37 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth wrote:

...

...
On Aug 9, 2016, at 11:57 AM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 5:21 AM, Murray Cumming

wrote:

...
...
On Di, 2016-06-28 at 17:32 +0000, Belcourt, Kenneth wrote:

...
The recent changes to the testing infrastructure has slowed this down as it’s now less-convenient to test that it was previously

Is this something different than this? https://github.com/boostorg/graph#running-tests

Related. I used to be able to edit status/Jamfile and remove all but a handful of libraries that I’d then test all together (so I could for example, test Graph, GraphParallel, MPI, etc.. all at once). The currently testing model doesn’t easily support testing multiple Boost libraries at one time and this slows me down.

Did you see my response at the time you brought this up on the command line options that let you control that? (i.e. the --limit-tests= option) Just wondering as I'm willing to add support for what you need if what's there is not enough.

Hi Rene,

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? 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? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Belcourt, Kenneth

3:17 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Aug 9, 2016, at 8:37 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 11:57 AM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 5:21 AM, Murray Cumming

wrote:

...
...
On Di, 2016-06-28 at 17:32 +0000, Belcourt, Kenneth wrote:

...
The recent changes to the testing infrastructure has slowed this down as it’s now less-convenient to test that it was previously

Is this something different than this? https://github.com/boostorg/graph#running-tests

Related. I used to be able to edit status/Jamfile and remove all but a handful of libraries that I’d then test all together (so I could for example, test Graph, GraphParallel, MPI, etc.. all at once). The currently testing model doesn’t easily support testing multiple Boost libraries at one time and this slows me down.

Did you see my response at the time you brought this up on the command line options that let you control that? (i.e. the --limit-tests= option) Just wondering as I'm willing to add support for what you need if what's there is not enough.

Hi Rene,

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.

...

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. 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. 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. — Noel

...

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

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Rene Rivera

4:15 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth wrote:

...

...
On Aug 9, 2016, at 8:37 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth 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

Belcourt, Kenneth

4:27 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Aug 9, 2016, at 10:15 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 8:37 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth 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.

I didn’t know that, thanks for the info.

...

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.

Yeah, that’s what I was thinking too.

...

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

I’ll try this, thanks again for all the help Rene. Noel

...

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

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Rene Rivera

11 Aug 11 Aug

8:37 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Tue, Aug 9, 2016 at 11:27 PM, Belcourt, Kenneth wrote:

...

...
On Aug 9, 2016, at 10:15 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 8:37 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth wrote:

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..

FYI.. That's now implemented, and documented. < https://github.com/boostorg/boost/commit/00f2425518ef230ffc7fb7fe6679cfde82b...

...

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

Belcourt, Kenneth

8:58 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Aug 11, 2016, at 2:37 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 11:27 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 10:15 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth wrote:

...
...
On Aug 9, 2016, at 8:37 PM, Rene Rivera wrote:

On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth wrote:

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..

FYI.. That's now implemented, and documented. < https://github.com/boostorg/boost/commit/00f2425518ef230ffc7fb7fe6679cfde82b...

Wow, thanks for getting that done so quickly. It may be the weekend before I can test it but will let you know if I encounter any issues. Thanks!

Murray Cumming

10 Aug 10 Aug

8:38 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Di, 2016-08-09 at 17:28 +0000, Belcourt, Kenneth wrote:

...

This is certainly an upgrade worth discussing. I’m not convinced we should drop support for pre-C++11 compilers as I have several systems that I need to run BGL and other Boost libraries on that can’t upgrade to C++11 at this time. And I’d bet there’s other users in the same boat.

Can't they stick with older versions of BGL? People didn't seem to need the fixes in the recent releases for the last couple of years, because develop didn't get merged to master - they were effectively using an old version with not much more than a version number change. They would only be forced to use a newer BGL because of the bundling of BGL with other Boost libraries that they might want to upgrade. But this is a general Boost issue, I guess, and I don't know of any guidelines. I think Boost has to drop support for older compilers at some point so the Boost code can move forward with clean code. I've found that things like variadic templates and decltype(auto) can massively simplify generic code. -- Murray Cumming murrayc@murrayc.com www.murrayc.com

Rene Rivera

8:44 p.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Wed, Aug 10, 2016 at 3:38 PM, Murray Cumming wrote:

...

But this is a general Boost issue, I guess, and I don't know of any guidelines.

The general guideline is that what is supported as far as compilers and C++ standard is up to the individual authors.

...

I think Boost has to drop support for older compilers at some point so the Boost code can move forward with clean code.

We've dropped various compilers over the years. But compiler support is mostly orthogonal to C++ standard support. Since you can have a modern compiler and still use an older C++ standard. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Belcourt, Kenneth

11 Aug 11 Aug

4:49 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Aug 10, 2016, at 2:44 PM, Rene Rivera wrote:

On Wed, Aug 10, 2016 at 3:38 PM, Murray Cumming wrote:

...
I think Boost has to drop support for older compilers at some point so the Boost code can move forward with clean code.

We've dropped various compilers over the years. But compiler support is mostly orthogonal to C++ standard support. Since you can have a modern compiler and still use an older C++ standard.

We rely on exactly this, new compilers, old standards. Not sure how much longer we can take this for granted, thankfully it works today. — Noel

Gavin Lambert

12:40 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On 11/08/2016 08:38, Murray Cumming wrote:

...

Can't they stick with older versions of BGL? People didn't seem to need the fixes in the recent releases for the last couple of years, because develop didn't get merged to master - they were effectively using an old version with not much more than a version number change. They would only be forced to use a newer BGL because of the bundling of BGL with other Boost libraries that they might want to upgrade.

But this is a general Boost issue, I guess, and I don't know of any guidelines. I think Boost has to drop support for older compilers at some point so the Boost code can move forward with clean code. I've found that things like variadic templates and decltype(auto) can massively simplify generic code.

Perhaps not a guideline, but in the past several libraries that have wanted to go C++11/14-only have done so by retaining the existing library as C++03+ and creating a new library (eg. bgl2) that is C++11/14-only. This also provides a good opportunity for making other breaking changes to the API to remove legacy things or to take advantage of more modern coding styles -- although on the other hand there's also a certain benefit to allow user applications to simply change the include path and namespace and have their existing code Just Work™. FWIW, to me it still seems like C++14 support is sketchy and can't be assumed. C++11 is reasonably commonplace but there are still some applications that can't use it for whatever reason.

Belcourt, Kenneth

4:31 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

...

On Aug 10, 2016, at 2:38 PM, Murray Cumming wrote:

On Di, 2016-08-09 at 17:28 +0000, Belcourt, Kenneth wrote:

...
This is certainly an upgrade worth discussing. I’m not convinced we should drop support for pre-C++11 compilers as I have several systems that I need to run BGL and other Boost libraries on that can’t upgrade to C++11 at this time. And I’d bet there’s other users in the same boat.

Can't they stick with older versions of BGL? People didn't seem to need the fixes in the recent releases for the last couple of years, because develop didn't get merged to master - they were effectively using an old version with not much more than a version number change. They would only be forced to use a newer BGL because of the bundling of BGL with other Boost libraries that they might want to upgrade.

Right, some of our projects are using develop for this very reason.

...

But this is a general Boost issue, I guess, and I don't know of any guidelines. I think Boost has to drop support for older compilers at some point so the Boost code can move forward with clean code. I've found that things like variadic templates and decltype(auto) can massively simplify generic code.

Agreed that c++11 and 14 offers much, but I’d really hate to lose a functioning capability like BGL c++98 without understanding the impact to existing users (perhaps a poll is in order). On the other hand, requiring legacy support risks alienating developers like yourself who want to move Boost forward. Just curious, but do you envision supporting the legacy API in the new BGL, or will users have to upgrade their code to use the new BGL? Could both API versions exist in a single code base to facilitate migration from the old APIs to the new, assuming the APIs break (e.g. could we use namespaces to manage different API versions in the same code base to allow incremental adoption)? —- Noel

Edward Diener

5:13 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On 8/11/2016 12:31 AM, Belcourt, Kenneth wrote:

...

...
On Aug 10, 2016, at 2:38 PM, Murray Cumming wrote:

On Di, 2016-08-09 at 17:28 +0000, Belcourt, Kenneth wrote:

...
This is certainly an upgrade worth discussing. I’m not convinced we should drop support for pre-C++11 compilers as I have several systems that I need to run BGL and other Boost libraries on that can’t upgrade to C++11 at this time. And I’d bet there’s other users in the same boat.

Can't they stick with older versions of BGL? People didn't seem to need the fixes in the recent releases for the last couple of years, because develop didn't get merged to master - they were effectively using an old version with not much more than a version number change. They would only be forced to use a newer BGL because of the bundling of BGL with other Boost libraries that they might want to upgrade.

Right, some of our projects are using develop for this very reason.

...
But this is a general Boost issue, I guess, and I don't know of any guidelines. I think Boost has to drop support for older compilers at some point so the Boost code can move forward with clean code. I've found that things like variadic templates and decltype(auto) can massively simplify generic code.

Agreed that c++11 and 14 offers much, but I’d really hate to lose a functioning capability like BGL c++98 without understanding the impact to existing users (perhaps a poll is in order). On the other hand, requiring legacy support risks alienating developers like yourself who want to move Boost forward.

Just curious, but do you envision supporting the legacy API in the new BGL, or will users have to upgrade their code to use the new BGL? Could both API versions exist in a single code base to facilitate migration from the old APIs to the new, assuming the APIs break (e.g. could we use namespaces to manage different API versions in the same code base to allow incremental adoption)?

You could support both a C++98 version and a C++11 version of your library using the Cxx_dual library. But since practically no one showed an interest in my Cxx_dual library I want to repeat here that the situation where any library, not just Graph, wants to support both a C++98 version and a C++11 version of the library with much of the same set of code is the main purpose of the Cxx_dual library.

Murray Cumming

10:08 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Do, 2016-08-11 at 04:31 +0000, Belcourt, Kenneth wrote:

...

Just curious, but do you envision supporting the legacy API in the new BGL, or will users have to upgrade their code to use the new BGL?

People would probably need to make changes to build against a newer BGL. For instance, if we removed typedefs, because people can now use auto (with C++11), and decltype(auto) (with C++14), that would break code that used those typedefs. But that application code wouldn't need those typedefs if it was updated to C++11/14 code. Personally, I'm a long way from deciding to "support" anyone with BGL. I'm still exploring it myself.

...

Could both API versions exist in a single code base to facilitate migration from the old APIs to the new, assuming the APIs break (e.g. could we use namespaces to manage different API versions in the same code base to allow incremental adoption)?

I guess a BGL2 would be best. There's no point trying to simplify the code (and make it more maintainable) with C++11/14 just to sprinkle legacy code throughout it. -- Murray Cumming murrayc@murrayc.com www.murrayc.com

Murray Cumming

12 Aug 12 Aug

7:47 a.m.

New subject: [EXTERNAL] [graph] Sync develop with master?

On Do, 2016-08-11 at 12:08 +0200, Murray Cumming wrote:

...

I guess a BGL2 would be best. There's no point trying to simplify the code (and make it more maintainable) with C++11/14 just to sprinkle legacy code throughout it.

This would also be an opportunity to finally put the API in a boost::graph namespace. -- Murray Cumming murrayc@murrayc.com www.murrayc.com

3028

Age (days ago)

3102

Last active (days ago)

List overview

Download

21 comments

5 participants

participants (5)

Belcourt, Kenneth
Edward Diener
Gavin Lambert
Murray Cumming
Rene Rivera