The C programming language is 40 odd years old. In the last
two decades, the number of new programming languages has raced
ahead - each with their own look and feel.

C is a low level language - as CPU speed increases have stagnated,
people have looked at C for more gains in performance. C++ to a large
extent improves on C, and negates much of the need for the preprocessor.

But one has to laugh at how much attention is given to compilers,
optimisations, libraries and standards. The preprocessor is treated like
a diseased lovechild.

In all these decades, the preprocessor has barely gotten any feature
enhancements - except for varargs and the # and ## operators.

What is it missing? Well, for one, *intelligence*. Anything. Please.

#include "filename"

Such a great function, but so badly designed. What is the one
thing every serious application does? Uses some form of autoconf,
so you can do:

#ifdef SOMETHING
# include "filename"
#endif

Why cant that be in the language?

#include_only_if_exists "filename"

There. That wasnt hard, was it?

Ok, so lets try one more. Assume a header file defines a value, lets
call it REG_R0. Another header file defines an enum for REG_R0. Consider
the following:

#define REG_R0 0
enum { REG_R0 = 0 };

Of course thats a syntax error above. We can do:

#define REG_R0 0
#if !defined(REG_R0)
enum { REG_R0 = 0 };
#endif

If that enum appears in a header file, we have no way to put the #if statement
in there. We might do something like:

This might mean, pretend the specified values are not defined for
the duration of including filename, so we can hide and avoid the
syntax error that will result.

Why do I care? Well, DTrace is fighting issues with ARM register names
with the "ucontext.h" file which seemingly wants to define register names
via an enum. I havent worked out how to resolve this, portably
and at the point of issue (rather than modify every source file to
change the way #includes are done).

Really, every language implements string and file parser as the
day-1 feature, and then adds bells and whistles for the rest of its
life to handle this.

C, being a "portable assembler" chooses to ignore the compilation
environment, and expects every developer to build inconsistent tools
because of the shortcomings of the preprocessor and environment
detection.

One of my little projects was to get DTrace ported to ARM. People
using Android, RaspberryPi or other ARM related tools could get
the benefit of DTrace.

Now this is not a simple project - but I have started some of the
work to prove this.

I had originally intended to use the RaspberryPi to do a lot of the
heavy lifting, but was not happy with the RPI as a reliable
hardware device and have issues with some of the kernels.

Last week, I took a look at qemu/arm - and can actually run an
ARM based virtual machine on my x86 Linux machine. Performance isnt
brilliant, but its palatable.

After spending ages getting the network to work - so I could get
the requisite packages, I have been updating the scripts and
headers/source code to fill in the gaps for ARM. At this point, we
are about half way through the user land compilation. Some of the
things are annoyances due to the Linux distro (debian 2.6.32 kernel).
E.g. the handling of ucontext.h seems to be different.

Once I have user land compiling, I can move onto the kernel - obviously
there is a fair amount of 386/x64 code to write for ARM, but am hoping
that its viable - especially given that the i386/x64 code is on top
of the original SPARC architecture - i.e. we know roughly the bits
needing attention.

If I am lucky, at the end of this exercise, it will work on my
ARM based VM; it almost certainly wont work on other ARM CPUs or
other kernels (ie Android), but at least the heavy lifting will have been
done, and it makes it more palatable to target the other platforms
(or people may do this for themselves).

I'll put out a new release, which includes some Linux 3.7/3.8 fixes
(thanks to those that contributed the fixes or highlighted some of the
broken build things in my code).