Re: [boost] License of endian and limits in Boost detail

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Philip Bennefall Sent: Sunday, March 17, 2013 9:31 AM To: boost@lists.boost.org Subject: Re: [boost] License of endian and limits in Boost detail

----- Original Message ----- From: "Rene Rivera" To: Sent: Thursday, March 14, 2013 2:45 AM Subject: Re: [boost] License of endian and limits in Boost detail

On Tue, Mar 12, 2013 at 4:31 AM, John Maddock wrote:

...

Are there any news on what might be done regarding this? I looked a little

...

more into it today, and it appears as though something as trivial as boost/circular_buffer.hpp pulls in the whole config folder with endian.hpp and limits.hpp so I am avoiding using them altogether for now in this project.

I've just removed detail/limits.hpp and edited boost/limits.hpp to not refer to it.

We'll see if anyone complains I guess.

endian.hpp is harder to know what to do with: there's no actual code in there, it's more like the accumulated wisdom of multiple Boosters plus bug reports etc. I'm actually not sure why SGI's copyright ended up in there: looks like when Caleb Epstein originally wrote that header he borrowed the "wisdom" from limits.hpp and so put SGI's copyright on it. Any ideas on how we would go about creating a clean version? If someone described the logic in words, and someone else wrote a new header from the description would that do it - or am I deceiving myself? If someone describes the general aspects of the detection I can see about adding it to my Predef library. With the eventual expectation that the library is going to make it into Boost soon obviously. But if it doesn't it would be then OK to steal the code into Boost without the library.. I could also do some research into doing the detection entirely on my own. But that would take more time.

Hello,

For my part, I would be most greatful to anyone willing to spend the time to correct this problem. For me, it's a bit of a Boost usage showstopper because pretty much every library includes endian.hpp. While my knowledge on the subject of detecting endianness is quite limited, I would be more than happy to do anything I can to help resolve the situation.

I agree that getting rid of this 'feature' is an important issue. We really should ensure that Boost licencing 'does what is says on the tin' - being Boost licensed. John's proposal and then add to the proposed Predef library sounds a good way forward. Actually I suspect that there is really only one way to do this task - whatever the actual macro variable names used in the code. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com