[1.75 release] Merging 'develop' to 'master' for Embarcadero fix
A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch but the branch has not been merged to 'master' for the 1.75 release. In the large majority of cases my PR for Embarcadero is the only difference between 'develop' and 'master'. These libraries are: assign circular_buffer container_hash date_time foreach graph iostreams numeric_conversion optional pool ptr_container random static_assert thread typeof units unordered If any of the maintainers of these libraries could see fit to get my PR in 'master' from 'develop' for the 1.75 release, it would be appreciated. I can assert that the PR causes no problems in the 'develop' regression tests for the aforementioned libraries. I have also opened up an issue for each of the aforementioned libraries in their Github page regarding my request.
On 10/28/2020 2:10 PM, Edward Diener via Boost wrote:
A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch but the branch has not been merged to 'master' for the 1.75 release. In the large majority of cases my PR for Embarcadero is the only difference between 'develop' and 'master'. These libraries are:
assign circular_buffer container_hash date_time
Including date_time above is my error. But the others are valid.
foreach graph iostreams numeric_conversion optional pool ptr_container random static_assert thread typeof units unordered
If any of the maintainers of these libraries could see fit to get my PR in 'master' from 'develop' for the 1.75 release, it would be appreciated. I can assert that the PR causes no problems in the 'develop' regression tests for the aforementioned libraries. I have also opened up an issue for each of the aforementioned libraries in their Github page regarding my request.
static_assert
Merged. John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
And Boost.LEAF On Wed, Oct 28, 2020 at 12:29 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Wed, Oct 28, 2020 at 11:11 AM Edward Diener via Boost <boost@lists.boost.org> wrote:
A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch
What about new libraries, such as Boost.JSON?
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/28/2020 5:59 PM, Emil Dotchevski via Boost wrote:
And Boost.LEAF
See my answer to Vinnie.
On Wed, Oct 28, 2020 at 12:29 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Wed, Oct 28, 2020 at 11:11 AM Edward Diener via Boost <boost@lists.boost.org> wrote:
A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch
What about new libraries, such as Boost.JSON?
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/28/2020 3:29 PM, Vinnie Falco via Boost wrote:
On Wed, Oct 28, 2020 at 11:11 AM Edward Diener via Boost <boost@lists.boost.org> wrote:
A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch
What about new libraries, such as Boost.JSON?
I should have explained the issue with Boost and Embarcadero although I thought I did so in the past. Here is the issue. The test for Borland/Codegear/Embarcadero workarounds in code should not solely rely on a test for the preprocessor symbol __BORLANDC__ and.or __CODEGEARC__. Instead the test must be done in either of two ways: 1) If config.hpp has already been include in the TU, any test for __BORLANDC__ should be the same test using BOOST_BORLANDC instead and any test for __CODEGEARC__ should be the same test using BOOST_CODEGEARC instead. 2) If config.hpp has not already been included in a TU, any test for __BORLANDC__ should be a test for !defined(__clang__) && __BORLANDC__ and any test for __CODEGEARC__ should be a test for !defined(__clang__) && __CODEGEARC__ . The reason for this is that the Embarcadero C++ clang-based compilers also define both __BORLANDC__ and __CODEGEARC__ but almost never need the manifold workarounds that the old bcc32 compiler, which also defines those preprocessor symbols, need, since the clang-based compilers are much more compliant to the C++ standard than the old bcc32 compiler is. To test for the Embarcadero C++ clang-based compilers, in case a specific workaround is needed for those compilers you can either simply test for BOOST_EMBTC if config.hpp has already been included, or test for defined(__clang__) and __BORLANDC__ or defined(__clang__) and __CODEGEARC__ if config.hpp has not been included. I can not be expected to endlessly go through a new library's code correcting __BORLANDC__ or __CODEGEARC__ workarounds to their correct equivalents, so please if you have such workarounds in your new code make the changes as explained above. Better yet, if you have such __BORLANDC__ or __CODEGEARC__ workarounds for new library code as an attempt to build/use your library with the old bcc32 compiler, I would strongly recommend to just get rid of them entirely. There is almost a 0% chance that the bcc32 compiler can use your new library in any way.
On Wed, Oct 28, 2020 at 4:30 PM Edward Diener via Boost <boost@lists.boost.org> wrote:
I can not be expected to endlessly go through a new library's code correcting __BORLANDC__ or __CODEGEARC__ workarounds to their correct equivalents
I agree. Fortunately, Boost.JSON is not using either of these :) Thanks for the explanation. Regards
On 10/28/2020 2:10 PM, Edward Diener via Boost wrote:
A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch but the branch has not been merged to 'master' for the 1.75 release. In the large majority of cases my PR for Embarcadero is the only difference between 'develop' and 'master'. These libraries are:
assign circular_buffer container_hash date_time foreach graph iostreams numeric_conversion optional pool ptr_container random static_assert thread typeof units unordered
If any of the maintainers of these libraries could see fit to get my PR in 'master' from 'develop' for the 1.75 release, it would be appreciated. I can assert that the PR causes no problems in the 'develop' regression tests for the aforementioned libraries. I have also opened up an issue for each of the aforementioned libraries in their Github page regarding my request.
The updated list is: assign container_hash foreach graph numeric_conversion ptr_container random thread typeof units unordered For most of these the only difference between 'develop' and 'master' is my PR to enable Embarcadero C++ clang-based compilers to work correctly with the library. I would really appreciate it if this fix could get in the upcoming 1.75 release for the libraries above.
Edward Diener wrote:
The updated list is:
assign container_hash foreach graph numeric_conversion ptr_container random thread typeof units unordered
I merged assign, graph and thread; Glen had already taken care of some of the rest. The remaining list is - foreach - numeric_conversion - random all of which contain other unmerged changes in addition to the Embarcadero patch. (Random, in particular, hasn't been merged in a while.)
On 11/1/20 6:29 AM, Peter Dimov via Boost wrote:
Edward Diener wrote:
The updated list is:
assign container_hash foreach graph numeric_conversion ptr_container random thread typeof units unordered
I merged assign, graph and thread; Glen had already taken care of some of the rest. The remaining list is
- foreach - numeric_conversion - random
all of which contain other unmerged changes in addition to the Embarcadero patch. (Random, in particular, hasn't been merged in a while.)
I'm thinking that the existence of many unmerged changes argues for testing one's development version against the current (next to be released) master version of other boost libraries. This way one can avoid having to spend time with out of date code.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 11/1/2020 9:29 AM, Peter Dimov via Boost wrote:
Edward Diener wrote:
The updated list is:
assign container_hash foreach graph numeric_conversion ptr_container random thread typeof units unordered
I merged assign, graph and thread; Glen had already taken care of some of the rest.
Thanks both to you and Glen.
The remaining list is
- foreach - numeric_conversion - random
all of which contain other unmerged changes in addition to the Embarcadero patch. (Random, in particular, hasn't been merged in a while.)
I think 'foreach' can easily be merged as the only other change, aside from mine, is a small documentation fix which can not affect code and looks right anyway. For 'numeric_conversion' you should be able to just merge my fix since none of the other changes affect any of the files in my fix, and in fact only affect the jamfile and a single other file. I agree with you that 'random' is pretty complicated. But should not some maintainer look at the possibility of merging 'random' 'develop' into 'master' since it has not been done for a long time now and the regression tests for 'random' on 'develop' look pretty good ?
On 11/1/2020 9:29 AM, Peter Dimov via Boost wrote:
Edward Diener wrote:
The updated list is:
assign container_hash foreach graph numeric_conversion ptr_container random thread typeof units unordered
I merged assign, graph and thread; Glen had already taken care of some of the rest. The remaining list is
- foreach - numeric_conversion - random
all of which contain other unmerged changes in addition to the Embarcadero patch. (Random, in particular, hasn't been merged in a while.)
Peter, would you please merge 'develop' to 'master' for 'foreach' if Eric is not going to do it. Also if you could cherry pick my change to numeric/conversion ( 1d856f673fc4ac8c5a599fadf8b865b2744ac2a1 ) and merge it to 'master' it would also be appreciated. As far as 'random' is concerned I assume that eventually someone will deal with the 'develop' changes in the future so that they get into the 'master' branch and my change will be picked up then.
Edward Diener wrote:
Peter, would you please merge 'develop' to 'master' for 'foreach' if Eric is not going to do it.
Eric has done it.
Also if you could cherry pick my change to numeric/conversion ( 1d856f673fc4ac8c5a599fadf8b865b2744ac2a1 ) and merge it to 'master' it would also be appreciated.
I merged all of the develop changes to master after testing them locally.
As far as 'random' is concerned I assume that eventually someone will deal with the 'develop' changes in the future so that they get into the 'master' branch and my change will be picked up then.
For Random, you should ask Steven Watanabe to take a look, reminding him that the deadline for merging to master is Wednesday.
On 11/2/2020 6:20 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
Peter, would you please merge 'develop' to 'master' for 'foreach' if Eric is not going to do it.
Eric has done it.
Bravo, Eric !
Also if you could cherry pick my change to numeric/conversion ( 1d856f673fc4ac8c5a599fadf8b865b2744ac2a1 ) and merge it to 'master' it would also be appreciated.
I merged all of the develop changes to master after testing them locally.
Thanks !
As far as 'random' is concerned I assume that eventually someone will deal with the 'develop' changes in the future so that they get into the 'master' branch and my change will be picked up then.
For Random, you should ask Steven Watanabe to take a look, reminding him that the deadline for merging to master is Wednesday.
I do not have Steven Watanabe's e-mail so hopefully he will read this message and respond. I had already created an Issue for 'random' at https://github.com/boostorg/random/issues/73 .
On 11/2/2020 6:20 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
Peter, would you please merge 'develop' to 'master' for 'foreach' if Eric is not going to do it.
Eric has done it.
Also if you could cherry pick my change to numeric/conversion ( 1d856f673fc4ac8c5a599fadf8b865b2744ac2a1 ) and merge it to 'master' it would also be appreciated.
I merged all of the develop changes to master after testing them locally.
As far as 'random' is concerned I assume that eventually someone will deal with the 'develop' changes in the future so that they get into the 'master' branch and my change will be picked up then.
For Random, you should ask Steven Watanabe to take a look, reminding him that the deadline for merging to master is Wednesday.
There has been no effort to merge the 'develop' branch of 'random' into 'master' and now the deadline for doing so has passed, at least for the beta release. Can anyone look into doing this and maintaining the 'random' library, at least for the future ? It is disappointing to me that my simple fix which would allow the Embarcadero C++ clang-based compiler to use Boost random will not get in the upcoming release, because it is the only Boost library of which I know for which my fixes to allow the Embarcadero C++ clang-based compilers to work properly has not been applied for the 1.75 release.
On Friday, November 6, 2020, Edward Diener via Boost <boost@lists.boost.org> wrote:
There has been no effort to merge the 'develop' branch of 'random' into 'master' and now the deadline for doing so has passed, at least for the beta release. Can anyone look into doing this and maintaining the 'random' library, at least for the future ? It is disappointing to me that my simple fix which would allow the Embarcadero C++ clang-based compiler to use Boost random will not get in the upcoming release, because it is the only Boost library of which I know for which my fixes to allow the Embarcadero C++ clang-based compilers to work properly has not been applied for the 1.75 release.
If someone is willing to contribute an Embarcadero C++ clang-based tester to the Boost regression test matrix, it would probably make it easier for maintainers to support this compiler going forward. Glen
On 11/6/2020 10:33 AM, Glen Fernandes via Boost wrote:
On Friday, November 6, 2020, Edward Diener via Boost <boost@lists.boost.org> wrote:
There has been no effort to merge the 'develop' branch of 'random' into 'master' and now the deadline for doing so has passed, at least for the beta release. Can anyone look into doing this and maintaining the 'random' library, at least for the future ? It is disappointing to me that my simple fix which would allow the Embarcadero C++ clang-based compiler to use Boost random will not get in the upcoming release, because it is the only Boost library of which I know for which my fixes to allow the Embarcadero C++ clang-based compilers to work properly has not been applied for the 1.75 release.
If someone is willing to contribute an Embarcadero C++ clang-based tester to the Boost regression test matrix, it would probably make it easier for maintainers to support this compiler going forward.
I discussed this with Embarcadero, hoping they could contribute. While I certainly think it is important, it is of prior importance that Boost allow the Embarcadero C++ clang-based compilers to at least compile/link Boost libraries correctly. This is what I have been trying to do with my fixes, incidentally discovering Embarcadero C++ clang-based compiler bugs along the way and reporting them to Embarcadero. If I can fully accomplish my initial aim, which I was hoping to do by this 1.75 release, maybe Embarcadero can be convinced to be more pro-active in supporting Boost with regression tests, free versions for Boost developers, and some CI testing framework for Embarcadero C++ clang-based compilers. But until I can accomplish this basic goal, I doubt Embarcadero will listen if I ask them again to be involved in supporting Boost with their clang-based compiler(s). The fact that it has taken a nearless endless amount of cajoling by me, just to accept the necessary fixes so that the Embarcadero C++ clang-based compilers can use Boost libraries. is disappointing to me. But I do realize that Boost libraries are supported by maintainers freely in their free time, and that maintainers are always doing their best.
participants (7)
-
Edward Diener -
Emil Dotchevski -
Glen Fernandes -
John Maddock -
Peter Dimov -
Robert Ramey -
Vinnie Falco