Building frustration

[Raffaello Giulietti]

There are two kind of Truffle/Graal users:

(1) Those who like or need to be in control of every aspect of Truffle
and Graal. They have come to master configurations, builds, flags,
environment variables and can tweak with every detail of the product.
They know Mercurial, mx, the C++ compilers and all sort of other great
tools.

(2) And those who would like to use Truffle/Graal to experiment with
language implementations. They tend to avoid diving into low level
aspects of building Truffle and Graal, not because of lack of interest
but because of the limited time they can devote in fighting against
unset flags, missing libraries, obsolete documentation, undocumented
dependencies and so on.

I belong to the second category. I would like to have frequently updated
versions of Truffle/Graal. I would be happy with binary distributions,
were it not for the fact that they are rather old (afaik, October 2015
for the Oracle JDK distribution, July 2015 for the JKU OpenJDK
distribution).

Since Truffle/Graal is moving so rapidly, the only way to keep it
up-to-date is to build it from the (latest) source.

In the past I've tried on Windows, with a low rate of success. Hence, I
decided to switch to Linux (a couple of distributions, currently on
Oracle Linux 7.2). I often stumble against similar problems.

I conclude that building Truffle/Graal from source is currently simply
not robust enough because of the many moving parts: the OSes, the
standard tools, the standard libraries, the user environment, the
documentation, the dependencies, etc.

Truffle/Graal is too interesting: it absolutely deserves to be better
accessible to a wider audience. There are essentially two ways:

* Much more frequently updated binaries for various platforms. I
understand this means more work for Oracle Labs and/or JKU.
* Or a robust build system for dummies like me, interested in making
good use of the product but unwilling to spend a long time in
understanding obscure error messages on failed builds to discover that
some undocumented and unknown environment variable was set incorrectly.

So, excluding the excellent guys at Oracle Labs and at JKU, I would like
to ask to the rest of us:

* How many of you are experiencing similar frustrating build problems?
* How many of you have invested or still invest hours adjusting and
tuning your working environment so as to make something like "mx spull ;
mx build" work without fuss?
* What can we do in practical terms to document the many tweaks one must
be aware of to turn frustration into joy?

Ideally, we should strive to a build system that can check the user
environment and suggest everything s/he shall undertake preemptively to
make a build succeed without troubles.



Greetings and Merry Christmas
Raffaello