Hello,
Is CLANG compiler to be so much recommended for FreeBSD ?
There are many other possible alternatives to CLANG.
Is CLANG compiler to be so much recommended for FreeBSD ?
There are many other possible alternatives to CLANG.
Is CLANG compiler to be so much recommended for FreeBSD?
There are many other possible alternatives to CLANG.
make
[kernel] modules. Modules can be compiled on their own, [by going to the subdirectory, or editing make.conf to compile modules with the world or kernel] but there was no make
command line option directly to be used from /usr/src/ or simple way for it.Intel sells compilers too, and again they have a very good reputation for fast code, but they are also expensive..
From the perspective of a common FreeBSD user, Clang is the most practical C/C++/Objective-C compiler option because it ships with the system, while any other compiler must be installed separately, perhaps using Clang for boot strapping.
As to why FreeBSD switched form GCC to Clang, the short answer is because of the license – GPLv3 vs. BSD.
In 2014, David Chisnall, the port maintainer of devel/gnustep and the developer of devel/libobjc2, wrote down the whole story, and this gives also answers about everything you always wanted to know about BSD & LLVM/Clang but were afraid to ask for: https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201403-asiabsdcon2014-llvmbsd.pdf
Please feel free to name a few alternatives which are BSD licensed and for this reason may be legally shipped within the BSD licensed FreeBSD base system.
GCC uses gigabytes of bloat to get 1 usable instruction set.
40 hours of compile time, for what should take 15 minutes.
But on topic, yes, clang can really be recommended. Just play a bit with the scan-build tooling giving you a detailed roadmap to the problem points. This was one strong point I brought to the table in my current job when I was yelling about the code quality.
GCC uses gigabytes of bloat to get 1 usable instruction set.
40 hours of compile time, for what takes 15 minutes of all the necessary compile.
If you are stuck within C and C++, here's a good trick to reduce compile times: Try to get rid of unnecessary #includes. First, make sure every .h file you wrote has an overall "#ifndef _THIS_H ... #endif" around it.
#include <memory>
class Enemy;
class Player
{
std::weak_ptr<Enemy> enemy;
};
// Wrong, we dont need to know Enemy internals for a pointer.
// A wasted file access.
#include "Enemy.h"
// Note still need this because we need to know its size
// because the std::weak_ptr<T> object is used. Not just a pointer.
#include <memory>
class Player
{
std::weak_ptr<Enemy> enemy;
};
Clang is not a great improvement compared to GCC.
That's true, but is actually not a major factor. During a compile on a reasonable machine (where the source mostly fits in RAM cache), the header files will remain in the file system buffer cache. Having to do open(), read() of a few lines, parsing very superficially to find the #endif, and close() again is pretty cheap, compared to having to parse everything through the full language parser. But you are right, it is not free. Not even having to open the file is definitely better.1) If your header file has been opened (to read the #ifndef) then it has already wasted time on file access.
Definitely true. Well designed C++ code to some extent follows the rules you propose; they can't always be strictly enclosed (for example, if one has to take sizeof() and object, one needs the header file). Refactoring code in this direction is a great idea, but is also a lot of work; the changes I described above can be done quickly and mechanically, without changing the design very much.2) We should only be #include'ing a file if we really need it. For 90% of things, we should be forward declaring. I.e #includes in C++ header files are often only needed when inheriting or non-pointer objects. In .cpp files, it should be the first time that a header is included anyway so the #ifndef is pointless.
Absolutely. Cyclic includes means that someone wasn't thinking. But this can be also done by analyzing the dependency graph that make spits out.3) We want to see an error on a cyclic include.
It looks like they no longer provide the compiler:
https://software.intel.com/en-us/articles/intel-system-studio-2016-for-freebsd
Another example why proprietary solutions are a stupid choice. They just die.
In that case I would apologize but I am still not entirely sure. You click on their download link and it only lists Windows, MacOS, Linux and Android.Actually, it looks like they do still provide it - see eg Intel® System Studio 2018 Update 1 for FreeBSD* Release Notes.
Changing the license of GCC from GPLv2 to GPLv3 was the main driver behind migrating to another system level compiler. Having said that, a mature and industry level BSD-licensed compiler would replace GCC in the long term eventually.License ok, but it is quite strange that you moved from GCC to Clang. Clang is not a great improvement compared to GCC. Why not other possible compilers?
Yes, I have had that challange which ended with frustration. I used a clean jail to compile llvm from source, but the task was way more challening and full of pitfalls than I initially thought.On the other hands, have you ever tried to compile CLANG for your system? Good luck really.