Giter Club home page Giter Club logo

Comments (2)

aklomp avatar aklomp commented on July 3, 2024

First off, there may be a license conflict: Boost.Predef is licensed under the Boost license, whereas this project is BSD 2-clause. Maybe that's not a problem if we ship an unmodified version of the original, but I'd like to be sure.
Is Boost.Predef a standalone project or an integral part of Boost? If I include it as a dependency, I'd prefer to have a properly packaged third-party lib instead of some loose files copied out of a tarball.

My opinion is that the Base64 library should in principle be self-contained, without any third party code. Rationale: I don't want to maintain third party code if I don't have to, and I'd prefer to keep the scope of this library small. (Including lots of extra code automatically pulls in... lots of extra code.)
However, I must admit that at this point, the Base64 library does a lot of platform-dependent, nonportable checks (example: the whole build system), so it might not be the worst idea to delegate that to an industrial-strength solution. I must admit that the docs make it look like this would simplify a lot of things, which is a win.
How do you think this would integrate with the proposed Cmake solution? Could Cmake re-use the Boost defines, or would it still run its own platform detection? It would be really clean if we could merge all the platform stuff into one module.

from base64.

BurningEnlightenment avatar BurningEnlightenment commented on July 3, 2024

OK, so let's get the licensing issue settled first:

Boost.Predef is licensed under the Boost license, whereas this project is BSD 2-clause. Maybe that's not a problem if we ship an unmodified version of the original, but I'd like to be sure.

The boost license basically says that we have the permission to use, reproduce, display [and] distribute [...] the Software (which is what we want to do) as long as we retain the copyright notices and distribute a copy of the license along with the source code. So if we included (parts of) the library, we would put a Boost.License file in that directory and be done with it. The users of this library however aren't affected by this in any way because the license explicitly makes an exception for compiled software allowing use and redistribution without any restrictions.
To sum it up: If a user copied the source tree he would also copy the Boost.License within the source tree and thereby comply with the license. If a user compiled this library and linked against it he would be eligible for the license exception and therefore be compliant with the license. (Please note that in addition to that the terms of the BSD-License of this project still apply and must be complied with)

Is Boost.Predef a standalone project or an integral part of Boost?

Well, actually it is both πŸ˜„. Many Boost libraries build upon those preprocessor checks and it is included in the main Boost package. Therefore I would call it an integral part. On the other hand it doesn't depend on anything but the C Preprocessor and has its own github repository, i.e. it is well suited for use outside of the Boost context without pulling in any other library or source file.

My opinion is that the Base64 library should in principle be self-contained, without any third party code. Rationale: I don't want to maintain third party code if I don't have to, and I'd prefer to keep the scope of this library small. (Including lots of extra code automatically pulls in... lots of extra code.)

I suggest that we include the Boost.Predef library through the means of a git submodule hook targetting their official github repository. That way you can maintain a clear seperation between Boost.Predef and your project plus getting all the benefits of using the Boost.Predef library. Boost.Predef issues would be reported to their repository and addressed over there which may even reduce the amount of code you have to maintain.

How do you think this would integrate with the proposed Cmake solution? Could Cmake re-use the Boost defines, or would it still run its own platform detection? It would be really clean if we could merge all the platform stuff into one module.

While one cannot use Boost.Predef stuff directly from CMake, it is indeed possible to build a very clean and lean platform detection module on top of Boost.Predef.

HTH

from base64.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.