Hi all !

ReactOS severely needs to be self-hostable for many reasons, one of it because it could allow people who only have Linux to be able to program / debug ReactOS with Windows tools (e.g. we have some people here and there complaining that they cannot use powerful debugging programs for debugging ReactOS (e.g. WinDbg and so on with MSVC builds of ReactOS) and therefore restrain themselves in using the “Goode Olde” GCC + DPRINT method, because they are running only on Linux). Something more personal is that I really want to program ReactOS on itself (in a VM) when it becomes self-hostable. But there are *only* few steps remaining before ReactOS can really be in such situation !!

I’ve already tested RosBE on it and I was able to download and configure a build. But there *are still* problems.

Here is my setup on a VM: main HDD of letter drive C: with ReactOS, second HDD of letter drive D: with ROS source code in D:\rossrc, third HDD of letter drive E: with build output files in E:\rosbuild .

After having successfully configured a build in the usual way (E:\rosbuild> D:\rossrc\configure.cmd), I first tried to compile the host-tools (cd host-tools && ninja). The first thing that I’ve noticed is that doing so retriggered a configure, then the compilation as wanted. I retried again, and again it reconfigured the build before actually rebuilding the host-tools. The same phenomenon appears then when trying to build ReactOS proper.

After analyzing produced files by the configuration step and comparing with a clean build on windows 2k3, it became clear that few files were missing, because obviously not generated:

E:\rosbuild\host-tools\CMakeFiles\2.8.10.2-ReactOS\CMakeCCompiler.cmake and CMakeCXXCompiler.cmake . The other .cmake files that should also be present here (CMakeRCCompiler.cmake and CMakeSystem.cmake) as well as two .bin files and two subdirectories where present (and contain the same things).

I was suggesting it might be a problem with the command-line interpreter, so I changed our cmd.exe with the one of windows 2000 (not win2k3, because the latter makes extra calls to some security APIs of advapi32 – not implemented on ReactOS – before running .bat / .cmd files, and it fails), but nothing changed, the files were not still present.

After having enabled extra debug output of cmake (that is called when configuring a build) by adding the flags “--debug-output --trace” (without quotes) in the cmake calls in configure.cmd (and after redirecting console stdout + stderr to a file when retrigerring a clean configuration), doing that on ReactOS *and* on win2k3 for comparison purposes, I saw that, at some point, some cmake flags concerning compiler recognition (à la: “CMAKE_GCC_EXISTS” for example) weren’t set to TRUE or FALSE, but were kept empty.

So I’m wondering whether it is actually some issue, either concerning our C runtime library (e.g. some called sprintf-like function fails or whatever) is buggy and something fails, OR, something file-system related. Concerning file-system, you know that we have LOTS of kernel32:file winetests failing, about problems for deleting files, recreating (or just creating) them, and so on… Maybe for some reason cmake fails to create those CMake(C/CXX)Compiler.cmake files for the same reason one of the kernel32:file tests fail ?

I don’t know, this previous point being speculative since I didn’t test anything regarding that.

Therefore it would be very nice *to see you all* trying to uncover where this bug comes from so that you can *finally* declare ReactOS self-hostable before, maybe, the next release !!

Cheers,

Hermès