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 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 3:29 PM, Vinnie Falco via Boost wrote:

On Wed, Oct 28, 2020 at 11:11 AM 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

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.

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/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 ?

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.

...

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 11/6/2020 10:33 AM, Glen Fernandes via Boost wrote:

On Friday, November 6, 2020, Edward Diener via Boost 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.