WIP Drop Premake (#3703)

* Remove premake lua

* Remove premake generated vs project

* remove deps file

* Remove premake driving bat files

* Full test matrix under CMake

* Remove premake based ci workflows

* Wiggle CI

* remove cmake from ci name

* find frameworks correctly on osx

* remove cmake from ci name

* Cope with sccache not being available

* cmake based falcor tests

* ci wobble

* only install ninja if necessary

* more appropriate cache name

* Remove premake from build instructions

* Add some docs on ci setup

* remove premake from regression tests

* remove premake from perf test

* Set SLANGC_PATH

* ci wobble

* bump slang-binaries

* ci wobble

* Bump spirv tools

* dont use timestamp in cache

* remote debug code

* cache key wobble

* Install sccache after building llvm

* Do not build llvm tools

* ci wobble

* ci wobble

* ci wobble

* ci wobble

* ci wobble

* Tests spirv via glsl in ci

* Define SLANG_ENABLE_XLIB=1

* osx builds on aarch64

* ci wobble

* ci wobble

* ci wobble

* ci wobble

* ci wobble

* ci wobble

* package documentation and metadata with cmake

* ci wobble

* Split hlsl double intrinsic tests

* ci wobble

* Correct type for double log10

Fixes https://github.com/shader-slang/slang/issues/4549

* remove working test from expected failures

* add broken test to expected failures

* smaller build for falcor tests

* ci wobble

* A few exclusions in ci

* wip, release script

* Enable examples in ci

* neaten release script

* Correct building docs

* Only use xlib vulkan when slang_enable_xlib is true

* bump slang-llvm version

* Remove toolchain file use

* Bump slang-llvm preset version

* slash direction

* Improve build directions

* Add msvc cross build documentation

* Disable old release files

* Smaller set of releases for test

* Allow not building llvm

* simplify release matrix

* Cross releases

* formatting

* formatting

* ci wiggle

* ci wiggle

* cleaner

* neaten

* ci wobble

* formatting

* Install cross tools on linux

* do not clean build dir

* neaten ci

* neaten ci

* neaten ci

* remove unused release workflow files

* Build llvm on some platforms

* neaten ci

* notarize on osx

* s/x64/x86_64

* ci wobble

* Embed stdlib for release build

* wobble ci

* wobble ci

* s/x64/x86_64

* ci wobble

* ci wobble

* ci wobble

* vk-gl-cts on cmake

* neaten ci

* neaten ci

* bump cache action version

* Cope with windows being weird about case

* old glibc version

* old glibc version

* Correct action file

* Keep cache hot on main branch

* separate small script for old glibc releases

* ci wobble

* ci wobble

* Run cmake outside of docker

* only sign on releases

* Revert "Run cmake outside of docker"

This reverts commit a58aaba939a4aa35fe70962fd60d9512b143592f.

* python3 on build image

* less parallel

* ci wobble

* ci wobble

* ci wobble

* newer git

* ci wobble

* ci wobble

* Use newer docker image

* Use newer docker image

* sccache wobble

* permissions issue

* neaten

* build llvm in ci

* build llvm in ci

* Remove linux clang build in ci

* Only install crossbuild tools on non-aarch64 systems

* neaten ci.yml

* Correct github matrix

* Simplify github matrix

* ci wobble

* Disable broken test

See https://github.com/shader-slang/slang/issues/4589

* ci wobble

* Neater slang-llvm archive filename

* Neater path for uploading artifacts

* Neater ci names

* Use Windows SDK 10.0.19041.0 in cmake builds

2 files changed, 48 insertions, 192 deletions

diff --git a/docs/building.md b/docs/building.md
index 89ee9a998..aba486a4e 100644
--- a/docs/building.md
+++ b/docs/building.md
@@ -1,194 +1,5 @@
 # Building Slang From Source
 
-We support building with both Premake and CMake. Both systems are described below.
-
-# Building Slang with Premake
-
-## Windows Using Visual Studio
-
-If you are using Visual Studio on Windows, then you can just open `slang.sln` and build your desired platform/configuration. `slang.sln` and associated project files are actually just generated using [`premake5`](https://premake.github.io/). See instructions in premake section below for further explanation.
-
-Whilst using the provided `slang.sln` solution is a fast and easy way to get a build to work, it does not make all binary dependencies available which can add features and improve performance (such as [slang-llvm](https://github.com/shader-slang/slang-llvm)). To get the binary dependencies create the solution using [`premake5`](https://premake.github.io/) described in a later section.
-
-## Other Targets
-
-Slang uses [`premake5`](https://premake.github.io/) to generate projects (such as `Makefile`s) that can then be used to build Slang binaries from source.
-
-For Linux and other targets the section below on `premake` describes the process.
-
-Some targets below are described as 'unofficial'. In practice this means that they are not tested as part of contiguous integration. Thus unfortunately it is quite possible from time to time for them to break on a merge of a PR. That said, if broken it is likely only very minor changes are needed to make them work again.
-
-### Generated Files
-
-Slang as part of it's build process generates header files, which are then used to compile the main Slang project. If you use `premake` to create your project, it will automatically generate these files before compiling the rest of the Slang. These are the current header generations which are created via the `slang-generate` and other tools...
-
-* core.meta.slang -> core.meta.slang.h
-* hlsl.meta.slang -> hlsl.meta.slang.h
-
-Other files that are generated have `generated` as part of their name.
-
-It may be necessary or desirable to create a build of Slang without using `premake`.
-
-One way to do this would be to first compile slang-generate and then invoke it directly or as a dependency in your build. Another perhaps simpler way would be to first compile the same Slang source on another system that does support `premake`, or using a preexisting build mechanism (such as Visual Studio projects on Windows). Then copy the generated header files to your target system. This is appropriate because the generated files are indentical across platforms. It does of course mean that if `core.meta.slang` or `hlsl.meta.slang` files change the headers will need to be regenerated.
-
-## Premake
-
-Slang uses the tool [`premake5`](https://premake.github.io/) in order to generate projects that can be built on different targets. On Linux premake will generate Makefile/s and on windows it will generate a Visual Studio solution. Information on invoking premake for different kinds of targets can be found [here](https://github.com/premake/premake-core/wiki/Using-Premake).
-
-Slang includes `premake5` as part of `slang-binaries` which is in the `external` directory. For the external directory to be setup it is necessary to have updated submodules with `git submodule update --init`.
-
-If you are on a unix-like operating system such as OSX/Linux, it may be necesary to make premake5 executable. Use
-
-```
-% chmod u+x external/slang-binaries/premake/***path to premake version and os***/premake5
-```
-
-Alternatively you can download and install [`premake5`](https://premake.github.io/) on your build system.
-
-Run `premake5` with `--help` to in the root of the Slang project to see available command line options (assuming `premake5` is in your `PATH`):
-
-```
-% premake5 --help
-```
-
-To download and use binaries for a particular architecture the [slang-pack](https://github.com/shader-slang/slang-binaries/tree/master/lua-modules) package manager can be invoked via the additional `--deps` and `--arch` options. If `--arch` isn't specified it defaults to `x64`. On Windows targets, the Visual Studio platform setting should be consistent with the `--arch` option such that the appropriate binary dependencies are available. The `--deps=true` option just indicates that on invoking premake it should make the binary dependencies for the `arch` available.
-
-Supported `--arch` options are
-
-* x64
-* x86
-* aarch64
-* arm
-
-For Unix like targets that might have `clang` or `gcc` compilers available you can select which one via the `-cc` option. For example...
-
-```
-% premake5 gmake2 --cc=clang --deps=true --arch=x64
-```
-
-or
-
-```
-% premake5 gmake2 --cc=gcc --deps=true --arch=x64
-```
-
-If you want to build the [`glslang`](https://github.com/KhronosGroup/glslang) library that Slang uses, add the option `--build-glslang=true`.
-
-# Projects using `make`
-
-The Slang project does not include Makefiles by default - they need to be generated via `premake`. Please read the section on your target operating system on how to use `premake` to create Makefiles.
-
-If building a Makefile based project, for example on Linux, OSX or [Cygwin](https://cygwin.com/), the configuration needs to be specified when invoking make, the following are typical...
-
-```
-% make config=release_x64
-% make config=debug_x64
-% make config=release_x86
-% make config=debug_x86
-% make config=release_aarch64
-% make config=debug_aarch64
-```
-
-To check what compiler is being used/command line options you can add `verbose=1` to `make` command line. For example
-
-```
-% make config=debug_x64 verbose=1
-```
-
-### Windows
-
-First download and install [`premake5`](https://premake.github.io/) on your build system. Open up a command line and go to the root directory of the slang source tree (ie the directory containing `slang.h`).
-
-Assuming premake5 is in your `PATH`, you can create a Visual Studio 2017 project for Slang with the following command line
-
-```
-% premake5 vs2017 --deps=true --arch=x64
-```
-
-For Visual Studio 2019 use
-
-```
-% premake5 vs2019 --deps=true --arch=x64
-```
-
-These should create a slang.sln in the same directory and which you can then open in the appropriate Visual Studio. Building will build all of Slang, examples and it's test infrastructure.
-
-### Linux
-
-On Linux we need to generate Makefiles using `premake`. Please read the `premake` section for more details.
-
-In the terminal go to the root directory of the slang source tree (ie the directory containing `slang.h`). Assuming `premake5` is in your `PATH` use
-
-```
-% premake5 gmake2 --deps=true --arch=x64
-```
-
-To create a release build use
-
-```
-% make config=release_x64
-```
-
-You can vary the compiler to use via the --cc option with 'gcc' or 'clang' for example
-
-### Mac OSX
-
-Note that OSX isn't an official target.
-
-On Mac OSX to generate Makefiles or an XCode project we use `premake`. Please read the `premake` section for more details.
-
-```
-% premake5 gmake2 --deps=true --arch=x64
-```
-
-If you want to build `glslang` (necessary for Slang to output SPIR-V for example), then the additional `--build-glslang` option should be used
-
-```
-% premake5 gmake2 --build-glslang=true --deps=true --arch=x64
-```
-
-To build for release you can use...
-
-```
-% make config=release_x64
-```
-
-Slang can also be built within the Xcode IDE. Invoke `premake` as follows
-
-```
-% premake5 xcode4 --deps=true --arch=x64
-```
-
-Then open the `slang.xcworkspace` project inside of Xcode and build.
-
-### Cygwin
-
-Note that Cygwin isn't an official target.
-
-One issue with building on [Cygwin](https://cygwin.com/), is that there isn't a binary version of `premake` currently available. It may be possible to make this work by building `premake` from source, and then just doing `premake5 gmake2`. Here we use another approach - using the windows `premake` to create a Cygwin project. To do this use the command line...
-
-```
-% premake5 --target-detail=cygwin gmake2 --deps=true --arch=x64
-```
-
-## Testing
-
-When slang is built from source it also builds tools to be able to test the Slang compiler. Testing is achieved using the `slang-test` tool. The binaries are placed in the appropriate directory underneath `bin`. It is important that you initiate the test binary from the root directory of the slang source tree, such that all tests can be correctly located.
-
-For example to run the tests on a windows release x64 build from the command line, in the root directory of slang source tree you can use...
-
-```
-% bin\windows-x64\release\slang-test
-```
-
-Note that on windows if you want to run all of the tests from inside visual studio, it is necessary to set the `Working Directory` under "slang-test project" > "Configuration Properties" > "Debugging" > "Working Directory" to the root directory of the slang source tree. You can do this by setting it to `$(ProjectDir)/../..` for all configurations.
-
-If you only see 'unit-tests' being run (unit tests are prefixed with 'unit-tests/') then the working directory is not correctly set. Most tests are text files describing the test held in the `tests` directory in the root of the slang project.
-
-See the [documentation on testing](../tools/slang-test/README.md) for more information.
-
-# Building Slang with CMake
-
 ### TLDR
 
 `cmake --workflow --preset release` to configure, build, and package a release
@@ -230,7 +41,7 @@ cmake --build --preset release # or --preset debug
 For Visual Studio run:
 ```bash
 cmake --preset vs2022 # or --preset vs2019
-start devenv .\build\slang.sln # to optionally open the project in Visual Studio
+start devenv ./build/slang.sln # to optionally open the project in Visual Studio
 cmake --build --preset release # to build from the CLI
 ```
 
@@ -327,10 +138,11 @@ pass the install path to the cross building CMake invocation using
 # build the generators
 cmake --workflow --preset generators --fresh
 mkdir my-build-platform-generators
-unzip build/dist-release/slang-generators.zip -d my-build-platform-generators
+cmake --install build --config Release --prefix my-build-platform-generators --component generators
 # reconfigure, pointing to these generators
+# Here is also where you should set up any cross compiling environment
 cmake \
-  --preset release \
+  --preset default \
   --fresh \
   -DSLANG_GENERATORS_PATH=my-build-platform-generators/bin \
   -Dwhatever-other-necessary-options-for-your-cross-build
@@ -338,3 +150,29 @@ cmake \
 cmake --workflow --preset release
 ```
 
+### Example cross compiling with MSVC to windows-aarch64
+
+One option is to build using the ninja generator, which requires providing the
+native and cross environments via `vcvarsall.bat`
+
+```bash
+vcvarsall.bat
+cmake --workflow --preset generators --fresh
+mkdir generators
+cmake --install build --prefix generators --component generators
+vsvarsall.bat x64_arm64
+cmake --preset default --fresh -DSLANG_GENERATORS_PATH=generators/bin
+cmake --workflow --preset release
+```
+
+Another option is to build using the Visual Studio generator which can find
+this automatically
+
+```
+cmake --preset vs2022 # or --preset vs2019
+cmake --build --preset generators # to build from the CLI
+cmake --install build --prefix generators --component generators
+rm -rf build # The Visual Studio generator will complain if this is left over from a previous build
+cmake --preset vs2022 --fresh -A arm64 -DSLANG_GENERATORS_PATH=generators/bin
+cmake --build --preset release
+```
diff --git a/docs/ci.md b/docs/ci.md
new file mode 100644
index 000000000..bfb101dff
--- /dev/null
+++ b/docs/ci.md
@@ -0,0 +1,18 @@
+# Our CI
+
+There are github actions for testing building and testing slang.
+
+## Tests
+
+Most configurations run a restricted set of tests, however on some self hosted runners we run the full test suite, as well as running Falcor's test suite with the new slang build.
+
+## Building LLVM
+
+We require a static build of LLVM for building slang-llvm, we build and cache this in all workflow runs. Since this changes infrequently, the cache is almost always hit. A cold build takes about an hour on the slowest platform. The cached output is a few hundred MB, so conceivably if we add many more platforms we might be caching more than the 10GB github allowance, which would necessitate being a bit more complicated in building and tracking outputs here.
+
+For slang-llvm, this is handled the same as any other dependency, except on Windows Debug builds, where we are required by the differences in Debug/Release standard libraries to always make a release build, this is noted in the ci action yaml file.
+
+## sccache
+
+The CI actions use sccache, keyed on compiler and platform, this runs on all configurations and significantly speeds up small source change builds. This cache can be safely missed without a large impact on build times.
+