Write compiler detection macros

[odinthenerd]

Before everyone starts using their own macros to select compilers we should probably make a compiler detect header with a few 100% correctly written macros. Off the top of my head I would request

• is msvc
• is GCC
• is clang
• is msvc2013
• is msvc2015

for most of the algorithms I have written so far I would have liked to make a msvc2013 version and an everything else version. Probably someone besides me should write the detection because I, as a militant macro hater, have little experience with them.

[ldionne]

It looks like we might need the same thing: https://github.com/pfultz2/Fit/issues/126#issuecomment-193003444. I already have something that works for Clang and Clang-cl in Hana, perhaps we could make this a joint effort.

[edouarda]

Why not reuse Boost.Predef?

[ccharly]

boost.predef is probably what you're looking for @porkybrain, you can easily check for specific versions and also it supports many many compilers. Take a look here.

[ldionne]

Why not reuse Boost.Predef?

I'm allergic to dependencies. Hana's needs are very modest (basically know which compiler is being used, the version is not even always useful), and I'd rather not introduce a dependency just for this. Hence the desire to have a simple, single header that I can drop into Hana's tree.

[mjcaisse]

I'm allergic to dependencies. Hana's needs are very modest ...

And this is the central theme of the NIH disease. Another way to spell dependency is re-use. I would find it odd that you only need to know the compiler and not the version. There are obviously assumptions being made based on that. The real requirement is a (working) language feature set.

[ldionne]

Ok, just to make it clear: I know that my approach (no dependencies) is obviously wrong in the general case. Code reuse is the reason why we write libraries in the first place. Plus, arguing against any form of external dependencies could be transferred to others by saying "you shouldn't use Hana since it's an external dependency". This is braindead, and it's not what I'm advocating.

However, here's the part of Hana that could benefit from Boost.Predef. If I was writing a library supposed to compile on many different compilers, or one that contained workarounds on specific compilers, things would be different. But Hana only requires a C++14 compiler, and I refuse to introduce workarounds. I don't feel like the code duplication here is sufficiently horrible to justify adding an external dependency, but YMMV. If you feel like Hana should be doing things differently for the purpose of code reuse, open an issue on Hana and I'll be happy to discuss.

[odinthenerd]

There is also a fundamental hierarchy to libraries, the more low level or generic a lib is the less dependencies it should have. I chose to use brigand in kvasir partly because it has no dependencies.

[pfultz2]

I think more or less the dependency problems stem from not having a simple way to fetch and build dependencies. As I mentioned in the other thread, I started writing a tool to fetch and build libraries using the standard cmake build and install, called cget. Since its completely non-intrusive, it can already build and install lots of libraries. It can build and install hana using cget install boostorg/hana or brigand with cget install edouarda/brigand, and it can even install LAPACK with cget install http://www.netlib.org/lapack/lapack-3.6.0.tgz(as long as you have a fortran compiler installed). Its still a WIP, right now, but I hope to eventually use it to manage the dependencies of my libraries as well.

[odinthenerd]

It's not just getting the libs, what about compiling with exceptions disabled? This makes perfectly good constexpr code that we are not even using blow up. What about unused code dragging in unused clib stuff that you don't need. On a desktop that doesn't matter, it's like 40k our something. I work on small processor embedded, and deploy on chips that have like 16k total... Killing argument.

[pfultz2]

I am not sure what your point is. Does brigand support exceptions being disabled? Does Boost.Predef or brigand bring in unused clib stuff?

[edouarda]

I didn't know about cget and it seems to have certain degree of awesomeness (about 87.3%).

From what I understand Boost.Predef is pure macros and it would be pretty safe to include it in Brigand, if needed. Brigand uses the Boost Software License as well so I see no incompatibilities.

We can put Boost.Predef in /brigand/detail/thirdparty, as a copy (no submodule). That way we can update as needed.

[odinthenerd]

Yes brigand supports turning off exceptions (I'm not sure that was by design but since msvc constexpr is broken the problem is elided). Boost.predef probably will not be a problem though, I was making a broader argument against dependencies.

[edouarda]

We can depend on a a preprocessor library, but I don't think we can depend on much else.

[jfalcou]

dependencies on Boost.Predef are fine in my book. It's basically just C preprocessor things.

[edouarda]

I renamed the issue accordingly.

[edouarda]

We can't use Boost.Predef because it would cause problems for the single header version of Brigand. We need a very small amounts of macros and we will write them.

If we submit Brigand to Boost, we will then switch to Boost.Prefef but right now we don't want to impose the usage of Boost when someone uses Brigand.

[odinthenerd]

Sounds good to me, I use the single header version ;)