[graph] Sync develop with master?
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
On May 30, 2016, at 3:37 AM, Murray Cumming <murrayc@murrayc.com> 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.
On Mo, 2016-05-30 at 19:43 +0000, Belcourt, Kenneth wrote:
On May 30, 2016, at 3:37 AM, Murray Cumming <murrayc@murrayc.com> 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
On Jun 28, 2016, at 3:31 AM, Murray Cumming <murrayc@murrayc.com> wrote:
On Mo, 2016-05-30 at 19:43 +0000, Belcourt, Kenneth wrote:
On May 30, 2016, at 3:37 AM, Murray Cumming <murrayc@murrayc.com> 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
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
On Aug 9, 2016, at 5:21 AM, Murray Cumming <murrayc@murrayc.com> 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
On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 5:21 AM, Murray Cumming <murrayc@murrayc.com> 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
On Aug 9, 2016, at 11:57 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 5:21 AM, Murray Cumming <murrayc@murrayc.com> 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.
On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 11:57 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 5:21 AM, Murray Cumming <murrayc@murrayc.com>
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
On Aug 9, 2016, at 8:37 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 11:57 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 12:28 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 5:21 AM, Murray Cumming <murrayc@murrayc.com>
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
On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 8:37 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth <kbelco@sandia.gov> 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
On Aug 9, 2016, at 10:15 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 8:37 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth <kbelco@sandia.gov> 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
On Tue, Aug 9, 2016 at 11:27 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 10:15 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 8:37 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth <kbelco@sandia.gov> 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
On Aug 11, 2016, at 2:37 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 11:27 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 10:15 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 10:17 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Aug 9, 2016, at 8:37 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 8:47 PM, Belcourt, Kenneth <kbelco@sandia.gov> 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!
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
On Wed, Aug 10, 2016 at 3:38 PM, Murray Cumming <murrayc@murrayc.com> 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
On Aug 10, 2016, at 2:44 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Wed, Aug 10, 2016 at 3:38 PM, Murray Cumming <murrayc@murrayc.com> 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
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.
On Aug 10, 2016, at 2:38 PM, Murray Cumming <murrayc@murrayc.com> 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
On 8/11/2016 12:31 AM, Belcourt, Kenneth wrote:
On Aug 10, 2016, at 2:38 PM, Murray Cumming <murrayc@murrayc.com> 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.
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
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
participants (5)
-
Belcourt, Kenneth -
Edward Diener -
Gavin Lambert -
Murray Cumming -
Rene Rivera