## Certain things which the almighty CMake utility cannot do.

CMake happens to be a friend of mine. On my Linux computers, if I need to custom-compile some software, and, if that software does not come with the older ‘./configure’ scripts…, then chances are, that source tree has a ‘CMakeLists.txt’ file in its root directory. On an ‘amd64′, or an ‘i386′ -based computer, this is usually all that I need to create Makefiles, and then to compile the project.

But, I have recently run into a situation where this utility became useless to me. It was an ‘aarch64-linux-gnu’, aka, an ‘arm64′ -based Guest System, running within ‘TightVNC’, running within an Android Host System. I tried to use CMake as usual (not really trying to cross-compile anything), and was startled by what this utility next told me: That my C++ compiler was broken, because CMake could not compile a test program, that CMake, in turn, generally tests compilers with.

What I found out was, that it was not the compiler’s fault, but rather, the apparent magic that allows CMake to find the libraries, not working when run on this architecture. Hence, the compiler was failing its test, because CMake could not even discern a single library’s location, nor any other variables, that would ultimately have been relevant to the project. The compiler’s test was not even being linked to ‘libstdc++.so’.

I basically had to give up on using CMake on that platform, as well as, on custom-compiling many software projects, that would have been written by other programmers.

What I have learned however is the apparent fact, that when true experts write the ‘CMakeLists.txt’ file to do so, they can even get it to cross-compile their projects to the same platform. But those would be their projects, and not my own project.

Dirk

## How To Install Yafaray Under Linux

One of the computing subtopics I dabble in, is the acquisition of 3D-graphics software. Therefore, I already have “Blender 2.78a”, which has its own built-in software-rendering engine, and I have several other rendering engines installed on my Linux-based computers.

Further, the rendering engines by themselves can be useless, unless they integrate well with a GUI (such as with Blender). And so one undertaking which I’ll typically reach with a given computer, is to install “Yafaray”, which used to be ‘Yafray’, which stood for ‘Yet Another Free Ray-Tracer’. If it’s installed properly, Blender can render its scenes, using Yafaray, but from within Blender.

Yafray used to be a much simpler piece of software to install than it has become. But I’m sure the effort I put into it this evening, will be well-worth it eventually. What I’m used to doing is to download a source-tree, and if it’s CMake-based, to run ‘cmake-gui‘ on it, to custom-pick my build options, and to go. But as it happens with Yafaray, this approach led to near chaos. What this did, was to compile all the source-code properly into libraries, but then to install those libraries to nonsensical locations within my system folders. One reason was the fact that a part of the project was to create Python 3 bindings, and another was the need for the Blender-integration, where modern Blender versions are based on Python 3. In any case I was sure to install all the build dependencies via my package-manager, but doing so was not enough to obtain working outcomes.

When I custom-compile source-code, which I downloaded, I usually use either one of

• ‘./configure’
• ‘cmake-gui’

In this previous posting, I described how to use ‘CMake’ in detail, especially in a case which entailed complications.

(I should add that this only works, when the source-code has specifically been set up, to use either of the above build-systems, which Open-Source software usually has. And, neither of the above configuration tools is actually a compiler, which anybody needs to provide, to use in conjunction with he configuration tools named above. )

But there is a second question related to CMake, which I feel I need an answer to, before I commit anything I compiled to the root file-system.

Usually, after having created the Makefiles, the course of action might be:


make -j 4
su
(...)

make install




But before I do the last bit, I want to be sure that I could uninstall anything which I might have installed ! So, as root, the way to uninstall would be:


make uninstall




But we might find, that with some Makefiles, there is no longer a target named ‘uninstall’ ! The way I find out about this, is to run:


make uninstall




as user, before running ‘make install’. If we happen to be using ‘CMake’, then we have a graceful way to exit. As root, in the build-directory, we can run the command:


cat install_manifest.txt | while read f; do rm -f "\$f"; done




This will usually uninstall the project again.

Dirk

## I’ve just custom-compiled ‘Aqsis’.

To give some context to this proclamation, I had written an earlier posting, about adapting the non-packaged software named ‘Ayam‘ to Debian / Stretch, that had worked just fine under Debian / Jessie. This is a GUI which constructs complex ‘Renderman‘-Compliant rendering instructions, in this case in the form of .RIB-Files, which in turn, ‘Aqsis’ can turn into 2D perspective views of 3D scenes, that have been software-rendered. OTOH, Ayam itself uses OpenGL and H/W rendering, for its GUI.

What I had found before, was that Ayam did not seem stable anymore under Debian / Stretch. I apologize for this assessment. Under close scrutiny, my computer has revealed, that it was really Aqsis giving the problems, not Ayam. Aqsis is a text-based tool in effect.

Ayam does not specifically need to be used with Aqsis to do its rendering. It can be set up to use other rendering-engines, most of which are quite expensive. Aqsis just happens to be the best Open-Source rendering-engine, whose language Ayam speaks. And at this point I’d say that Ayam is still quite stable, after all, under Debian / Stretch.

As is often the case with such troubles, I next sought to custom-compile Aqsis, to see whether doing so could get rid of its quirks. What were its quirks?

Finally, the only problem with Aqsis was and remains, that it cannot produce a real-time preview of the scene being edited, which it used to provide using a component-program named ‘piqsl’. And the reason why the packaged version of Aqsis does not have ‘piqsl’ under Debian / Stretch, is because this distribution of Linux has a very new ‘Boost’ library ( v1.62 ) , and the visual component to Aqsis, that could produce a display, still relies on the Qt4 libraries and their API, which have begun to bit-rot. The Qt4-specific code of Aqsis cannot parse the newest usage of the Boost libraries, and Debian maintainers have long since discovered this. They are shunning the use of ‘libqt4-dev’ and of ‘libqt4-opengl-dev’ to build any of their packages. So they were effectively forced to package a version of Aqsis, which was missing some important components.

(Updated 12/12/2017 … )