manawy

I have no doubt they do, but still...

The question is : are the DOD/DOE (or the chinese/european equivalent) going to risk millions for their next supercomputers on a new architecture or prefer good old intel ?

Especially when we know that the jump to exascale computation will only be possible if we get rid of the buses and have everything on the same chip (which is one direction taken by Intel).

My point is that the conclusion of the article "Intel has to come up with an answer..." is just plain wrong. This new architecture is an answer to intel new developments. We will have to wait to see what stick to the wall.

or it could turn badly for the others, it will not gain attraction if intel products are not supported

Inertia is a very strong decisive factor, especially when you need to make sure that 30+ year-old code still work like it's the case in HPC

For your second example, this does not test for the compiler but for the provider of the SSL library. Clang does not provided it, so it's not a problem.

But I get your point.

My counter-argument is that more flexibility is left to the developer to assume stuff. These assumptions make things easier in most cases. In corner cases, then you need to provide explicit values to the module so he can find what you need.

I'd argue that for Qt this approach makes sense because they provide a well defined API that they stick too. The developer can also ask for specific component if it just want them (like QT GUI, QT SVG...).

I agree that this is more problematic with less common, more buggy libs where the API keep changing, but in this case it's quite easy to check for specific files, specific functions, ...

All this assumptions have huge consequences in terms of velocity and ease of use.

I'm not sure what you mean by databases of systems and features...

I use CMake everyday and for me it's not a database but a set of modules. Each of this module will look for a particular thing. Some modules are better written than other but they all allow you to bypass them. Of course on obscure systems it will fail. That's why they are called obscure. But on systems following more or less the good practice, there will be no problem at all. On the others, you need to pass the specific path, but it will be true with autoconf too... no magic here...

Also in the doc, it is stated that if you rely on a specific flag/option/function then you need to test for it, and CMake gives you the tool to do it. That's a good practice everyone should follow.

But I agree, it's not always done. Like Autoconf, I guess it really depends on how well the developer understand the tool, and how much time he is ready to spend on it.

There's no magic, it's a complicated problem, with only complicated solutions. CMake is more attractive to me, because it allows me to do simple stuff easily, but more complicated operations are also possible.

Yes, I'm really happy that GCC optimize that code away.

Most of us don't care about security issue too much when using C/C++. We do use it for performance, and use it mostly locally.

GCC is a very versatile code. It's ok that it makes secure code difficult to write because it's not what most of us is doing. Not being completely secure is ok, not being optimized is not.