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 !!
Ive 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 Ive 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) werent set to TRUE or FALSE, but were kept
empty.
So Im 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 dont know, this previous point being speculative since I didnt 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