CORE-9069, CORE-13525, RELEASE-11
This new BootCD contains the functionality of both the original bootcd
(text-mode 1st-stage installer) and the livecd (that will include the
1st-stage GUI installer later).
Our separate livecd ISOs become obsolete, and this completely removes
the need for the so-called "hybridcd" ISO.
Some details:
- The "hybridcd" build target is completely removed, since now the new
BootCD *is* basically what we used to call "hybridcd".
- The "livecd" build target is kept so far (to minimize the code changes),
but internally I start to refer to it as "LiveImage", and is reduced
to a minimum.
A minimal non-bootable "liveimg.iso" is built (but currently not
included within the BootCD). Its purpose will be to implement the
"ReactOS Live" functionality as a RAMDISK.
(We currently don't support other file formats apart from ISO and
flat disk for a RAMDISK).
The "ReactOS Live" (non-RAMDISK) is implemented by adding to the
BootCD file tree the files from the LiveImage.
These files add two root directories, "Profiles" and "reactos"
(which is the SystemRoot for the non-ramdisk LiveImage).
- The minimal text-mode ReactOS installation used for the 1st-stage
installer, including USETUP itself, and the executable for the
1st-stage GUI installer and the reactos.cab (installation source),
are moved to the root directory called "i386" (ideally, one directory
per architecture).
- The "bootcdregtest" target, i.e. the ISOs we feed our testbots with,
are left untouched, i.e. they are only constituted of the 1st-stage
text-mode installation only, but placed in a per-architecture root
directory ("i386", etc. as for the bootcd).
- Remove the ACPI APIC/SMP entries from bootcd.ini. They will be made
available via the Advanced Boot Options F8 menu in Debug builds, for
testing purposes only, in a subsequent commit.
This commit is based upon an older SVN one:
svn path=/branches/setup_improvements/; revision=75273
- [PSDK] Introduce our own Microsoft compatible and MIT-licensed shlwapi.h and fix breaking changes
- [INCLUDE/WINE] Import shlwapi.h from wine-10.0 for use with Wine compatible code
- [CMAKELISTS.TXT] Bump up IE version from IE60 to IE60SP2. This is required because we are already using IE60SP2 guarded functionality; the new header unhides this.
- [SHLWAPI] Fix breaking changes, including a typo for 'SHGVSPB_GLOBALDEAFAULTS' (should be 'SHGVSPB_GLOBALDEFAULTS')
- [MSI] Use wine's shlwapi.h instead of our own in automation.c, don't precompile shlwapi.h.
- [URLMON_WINETEST] Primarily use wineheaders for this test
- Move sdk\include\reactos\wine to sdk\include\wine
- Reorder the directories in include_directories() to be closer to alphabetical. This should make it easier to determine what global include directories can be removed in the future.
Follow-up of #8057. Generally, the IDL
file is a higher level than the header file.
JIRA issue: CORE-19361
- Modify CMakeLists.txt.
- Add sdk/include/reactos/CMakeLists.txt.
- Add reactos_idls CMake target in
- sdk/include/reactos/CMakeLists.txt
to process IDL files.
- Add reactos_idls dependency to cicero.
- Delete msctf_undoc.h and add
msctf_undoc.idl.
Re-trial of #7800. Deleting __WINESRC__
hacks.
JIRA issue: CORE-5743
- Add sdk/cmake/set_wine_module.cmake.
- Load set_wine_module.cmake at
top-level CMakeLists.txt.
- Use set_wine_module cmake function
and delete __WINESRC__ as possible.
- Delete many include_directories.
It's purpose was to create x64 unwind information from DWARF debug info, but it was never fully working and is pointless now anyway, because x64 GCC does this itself properly.
These headers come with the MS compiler. Some of them are standard, like emmintrin.h, others are MS specific like crtdefs.h
This separation will allow using MS CRT headers. Eventually it can allow compiling with the compilers' runtime headers.
- Add some of the missing CMake adjustments to continue the configure and compile process with ARM64 MSVC
- Created quick stubs for the functions in SDK needed to finish the configuration process
- Put in an ARM64 option for spec2def
CORE-17518 CORE-17615
Having conditional statements with CMAKE_BUILD_TYPE is an antipattern
See https://stackoverflow.com/questions/66079007/having-conditional-statements-on-build-type-variable-a-good-design
We use both single- and multi-config generators (Ninja and VS), so we
can't really rely on CMAKE_BUILD_TYPE, because it's not always set.
This commit alters some conditional flags to use <$CONFIG:...>
generator expression, but is still not complete. Also, our default
optimization level (4) now has what was always a de-facto flags
config*.cmake files are constantly getting out of sync between
each other. Besides that, the parameters are not really dependent
on a target architecture, but rather on a compiler (except *ARCH)
This approach seems to be more future-prone, and allows to see
all the options in one file (there are really not that many of them)
That way, we won't use whatever standard is the default on whatever compiler we are using.
This should also prevent using more recent features without warning.
- Updated toolchain file
- set GCC variable when using CLang in "GCC mode"
- Properly retrieve GCC support libraries
- Various flags needed to get this going
Timo Kreuzer