Why Not Use "Cl.exe Link.exe" as the primary compiler?

[melen523]

As the topic says.

[melen523]

Ah i know , in that case , the code would not be easy to compile cross platform

[hbelusca]

But we support compiling ReactOS with Visual C++ !

[Yuntian Zhang]

1. GCC has been ported to multi platform. But VC is Windows only. Of course you can use Wine, but that isn't supported officially, which means Microsoft can detect it and refuse to run if they want.
2. GCC is open source and libre. As an open source project under GPL, there is no reason not to support another open source project.
3. GCC, if not better than VC, is as good as VC. If GCC really sucks, although it is under GPL blah blah blah we won't use it. But it works flawlessly.
4. VC doesn't fully support C99, nor C11. Microsoft has tried to push their users to use C++. ALthough I didn't type it, VC means "Visual C++", not "Visual C". In this project the basic programming language is C. No point to use VC for compiling C source codes.

Those are what I come up with right now.

[Z98]

We require C89 for all C code, so VC++'s lack of support for newer versions of C is irrelevant. Several developers are already using VC++ to do much of their work. The only thing that stopped them in the past was our build configuration system could not correctly support it. With CMake (plus a few patches of our own), we now can. It's a moot point however as not everyone can run VC++, so we maintain compatibility with GCC for practical reasons.

[BlackRabbit]

With CMake (plus a few patches of our own), we now can.

Really? If so, I must be confused. I have been attempting to compile using the cmake method, on average, about once a week since it was first announced a few months ago. I have not yet had any success. I must be doing something wrong.

Could someone please clarify what to expect with the cmake method? I am not so much interested in how to compile with cmake. I know how to do that (I think). I am more interested in the answers to the following questions:

1. Does Intellisense work using after loading the cmake-generated Visual Studio solution and project files?
2. If I download a virgin ReactOS/cmake build bundle and follow the instructions for building using cmake, will I be able to at least compile all of ReactOS without any fatal build errors?
3. Is it possible to use the Visual Studio-via-cmake method to build livecd?
4. Is it possible to use the Visual Studio-via-cmake method to build bootcd?

Each time I broach this subject, I am told that cmake works with Visual Studio, but when I try it myself, it fails. When I bring it to someone's attention that it fails, I am told something like, "It is not working yet."

Also note that, by my question, I am not implying that, for example, #3/#4 should be true. I am merely trying to gain some perspective here.

[Z98]

1) Yes.
2) Mostly, minus some C++ components. Note I am assuming you mean Visual C++ here, since cmake is not a compiler.
3) Same as 2, with the qualifier that there are known bugs that make things a bit unstable and thus is not used for debugging purposes.
4) Low priority amongst the devs so who knows.

So far amongst the team, no one seems to have any difficulty getting a build going, but then we're only using it for debugging user mode modules. Regression testing is only run against GCC builds. You keep insisting that you can't get it to work, but we haven't been given sufficient/precise enough information with which to try to replicate your problems.

And please be more precise in your terminology. You keep treating the names of a compiler, a build system, and a build generator as interchangeable. They are not, which only adds to the confusion whenever you report a problem.

[erkinalp]

We require C89 for all C code, so VC++'s lack of support for newer versions of C is irrelevant. Several developers are already using VC++ to do much of their work. The only thing that stopped them in the past was our build configuration system could not correctly support it. With CMake (plus a few patches of our own), we now can. It's a moot point however as not everyone can run VC++, so we maintain compatibility with GCC for practical reasons.

If we cease Visual Studio support, lack of C99/C11 will become important, new C APIs has multithreading and safe functions, and we can attract much more developers from *nix to ReactOS (I mean user side applications).

[BlackRabbit]

I decided to do everything from scratch so that we are all on the same wavelength:

1. I am using Visual C++ Express 2010.
2. I pull the ReactOS source tree from the ReactOS server.
3. I go to the root of my ReactOS tree and type configure VSSolution. The configure command does its thing, generating the Visual Studio solution and project files.
4. I load the solution for the host tools and do a build inside Visual Studio. The build completes successfully, with no errors whatsoever.
5. I load the solution for ReactOS proper, and do a build all. As you mentioned, I get a relatively small number of errors:

Some errors are related to browseui.dll:

------ Rebuild All started: Project: browseui, Configuration: Debug Win32 ------
Building Custom Rule C:/Users/BlackRabbit/Desktop/reactos/dll/win32/browseui/CMakeLists.txt
CMake does not need to re-run because C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\browseui\CMakeFiles\generate.stamp is up-to-date.
Generating browseui.def, browseui_stubs.c
aclmulti.cpp
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_AddNewPrograms already defined in shell32.lib(shguid.obj)
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_AdminTools already defined in shell32.lib(shguid.obj)
...
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_Windows already defined in shell32.lib(shguid.obj)
Creating library C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/browseui/Debug/browseui.lib and object C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/browseui/Debug/browseui.exp
C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\browseui\Debug\browseui.dll : fatal error LNK1169: one or more multiply defined symbols found

Some errors are related to shell32.DLL:

------ Rebuild All started: Project: shell32, Configuration: Debug Win32 ------
Building Custom Rule C:/Users/BlackRabbit/Desktop/reactos/dll/win32/shell32/CMakeLists.txt
CMake does not need to re-run because C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\shell32\CMakeFiles\generate.stamp is up-to-date.
Generating shell32.def, shell32_stubs.c
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_AddNewPrograms already defined in shell32.lib(shguid.obj)
...
uuid.lib(shguids.obj) : error LNK2005: _FOLDERID_Windows already defined in shell32.lib(shguid.obj)
Creating library C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/shell32/Debug/shell32.lib and object C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/dll/win32/shell32/Debug/shell32.exp
C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\dll\win32\shell32\Debug\shell32.dll : fatal error LNK1169: one or more multiply defined symbols found

And some errors are related to the HAL.

------ Rebuild All started: Project: hal, Configuration: Debug Win32 ------
Building Custom Rule C:/Users/BlackRabbit/Desktop/reactos/hal/halx86/CMakeLists.txt
CMake does not need to re-run because C:\Users\BlackRabbit\Desktop\reactos\output-VS10-i386\reactos\hal\halx86\CMakeFiles\generate.stamp is up-to-date.
Generating hal.def, hal_stubs.c
hal.def : error LNK2001: unresolved external symbol KeStallExecutionProcessor
C:/Users/BlackRabbit/Desktop/reactos/output-VS10-i386/reactos/hal/halx86/Debug/hal.lib : fatal error LNK1120: 1 unresolved externals
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(268,5): error MSB6006: "link.exe" exited with code 1120.

As you stated, the total number of projects that fail to build is relatively small:

------ Skipped Rebuild All: Project: ALL_BUILD, Configuration: Debug Win32 ------
Project not selected to build for this solution configuration
========== Rebuild All: 813 succeeded, 7 failed, 4 skipped ==========

First clarification: I think that it is very important to make it clear that it is not yet possible to build ReactOS using Visual Studio. It is possible to build most of the components of ReactOS using Visual Studio. This distinction is very important for those who prefer Visual Studio but are not yet familiar with the build system, especially new developers, because it removes any expectations that they are going to be able to generate a livecd using Visual Studio. When you say, that it is possible to build ReactOS using cmake-Visual Studio method, some people might get the impression that, if they follow the steps, a livecd will be generated, which they can then use to play with.

Second clarification: I went to the ntoskrnl project, opened shutdown.c, right-clicked on NtSetSystemPowerState, and selected Go To Declaration:

[ external image ]

I get the following error:

[ external image ]

It is true that mousing over NtSetSystemPowerState, for example, will show the function prototype in a pop-up. But being able to browse-around by doing Go To Declaration does not seem to work.

[BlackRabbit]

If we cease Visual Studio support, lack of C99/C11 will become important, new C APIs has multithreading and safe functions, and we can attract much more developers from *nix to ReactOS (I mean user side applications).

If we continue with Visual Studio support, we would attract far more developers to ReactOS, since there are far more Windows-oriented developers who understand a Windows-like operating system, than *nix-oriented developers who understand a Windows-like operating system.

[Z98]

Amine is looking into the issue, though he would like to know if you are using the cmake we distribute or the vanilla cmake.

Regarding C11, its improvements are for the most part irrelevant to us. To support its newer, higher level functionality, your operating system has to provide a certain level of infrastructure. Since we're writing the OS, that infrastructure isn't there. As such, we wouldn't be able to use the new stuff anyway.

Also, we don't have a pressing need for user applications. The entire software world has done a pretty damn good job producing software for Windows already.

[BlackRabbit]

Amine is looking into the issue, though he would like to know if you are using the cmake we distribute or the vanilla cmake.

I am using the one that I got from Amine, in fact:

[ external image ]

[hbelusca]

Hi all !

It's the first time I'm testing compilation of ReactOS via Visual Studio (the IDE of course).

I have two remarks:
- I can correctly find the definition of the NtSetSystemPowerState function : it is in ntpoapi.h (see the screen-shot).
- I get the same shell32 linking errors as BlackRabbit.

[ external image ]

(sorry for its big size)

[hbelusca]

Amine just tried to fix HAL compilation in revision 58862. Can you retest its compilation please ?
Note that it is a regression, as the boot-cd and the live-cd used to compile fine with Visual Studio IDE (according to Amine).

[BlackRabbit]

Done. No more errors on build of HAL.

The only two projects with remaining errors are browseui.dll and shell32.dll:

------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
Build all projects
========== Build: 29 succeeded, 2 failed, 762 up-to-date, 0 skipped ==========