diff options
Diffstat (limited to 'premake5.lua')
| -rw-r--r-- | premake5.lua | 251 |
1 files changed, 159 insertions, 92 deletions
diff --git a/premake5.lua b/premake5.lua index b963d44df..0b4f4bd42 100644 --- a/premake5.lua +++ b/premake5.lua @@ -264,6 +264,9 @@ end -- First, we will define a helper routine for adding all -- the relevant files from a given directory path: -- +-- Note that this does not work recursively +-- so projects that spread their source over multiple +-- directories will need to take more steps. function addSourceDir(path) files { @@ -287,6 +290,10 @@ end -- -- baseSlangProject("slangc", "source/slangc") -- +-- NOTE! This function does not add any source from the sourceDir +-- add the source after calling this function with 'addSourceDir', or +-- use `baseSlangProjectAddFiles` +-- function baseSlangProject(name, sourceDir) -- Start a new project in premake. This switches @@ -331,15 +338,6 @@ function baseSlangProject(name, sourceDir) -- language "C++" - -- Since we know the project directory, we can go ahead - -- and add any source files locate there. - -- - -- Note that we do *not* recurse into subdirectories, - -- so projects that spread their source over multiple - -- directories will need to take more steps. - -- - addSourceDir(sourceDir) - -- By default, Premake generates VS project files that -- reflect the directory structure of the source code. -- While this is nice in principle, it creates messy @@ -372,7 +370,23 @@ function baseSlangProject(name, sourceDir) end end --- We can now use the `baseSlangProject()` subroutine to +function baseSlangProjectAddFiles(name, sourceDir) + + -- + -- Set up the base project + -- + + baseSlangProject(name, sourceDir) + + -- + -- Add the files in the sourceDir + -- NOTE! This doesn't recursively add files in subdirectories + -- + + addSourceDir(sourceDir) +end + +-- We can now use the `baseSlangProjectAddFiles()` subroutine to -- define helpers for the different categories of project -- in our source tree. -- @@ -395,8 +409,8 @@ function tool(name) -- Now we invoke our shared project configuration logic, -- specifying that the project lives under the `tools/` path. -- - baseSlangProject(name, "tools/" .. name) - + baseSlangProjectAddFiles(name, "tools/" .. name) + -- Finally, we set the project "kind" to produce a console -- application. This is a reasonable default for tools, -- and it can be overriden because Premake is stateful, @@ -420,14 +434,14 @@ function standardProject(name) -- A standard project has its code under `source/` -- - baseSlangProject(name, "source/" .. name) + baseSlangProjectAddFiles(name, "source/" .. name) end function toolSharedLibrary(name) group "test-tool" -- specifying that the project lives under the `tools/` path. -- - baseSlangProject(name .. "-tool", "tools/" .. name) + baseSlangProjectAddFiles(name .. "-tool", "tools/" .. name) defines { "SLANG_SHARED_LIBRARY_TOOL" } @@ -441,7 +455,7 @@ function example(name) group "examples" -- They have their source code under `examples/<project-name>/` - baseSlangProject(name, "examples/" .. name) + baseSlangProjectAddFiles(name, "examples/" .. name) -- By default, all of our examples are GUI applications. One some -- platforms there is no meaningful distinction between GUI and @@ -465,6 +479,30 @@ function example(name) links { "slang", "core", "gfx" } end +-- +-- Create a project that is used as a build step, typically to +-- build items needed for other dependencies +--- + +function generatorProject(name, sourcePath) + -- We use the `group` command here to specify that the + -- next project we create shold be placed into a group + -- named "generator" in a generated IDE solution/workspace. + -- + -- This is used in the generated Visual Studio solution + -- to group all the tools projects together in a logical + -- sub-directory of the solution. + -- + group "generator" + + -- Set up the project, but do NOT add any source files. + baseSlangProject(name, sourcePath) + + -- For now we just use static lib to force something + -- to build. + kind "StaticLib" +end + if isTargetWindows then -- -- With all of these helper routines defined, we can now define the @@ -521,7 +559,7 @@ standardProject "core" -- We need the core library to be relocatable to be able to link with slang.so filter { "system:linux" } buildoptions{"-fPIC"} - + -- -- The cpp extractor is a tool that scans C++ header files to extract -- reflection like information, and generate files to handle @@ -696,78 +734,41 @@ standardProject "slangc" uuid "D56CBCEB-1EB5-4CA8-AEC4-48EA35ED61C7" kind "ConsoleApp" links { "core", "slang" } - --- --- TODO: Slang's current `Makefile` build does some careful incantations --- to make sure that the binaries it generates use a "relative `RPATH`" --- for loading shared libraries, so that Slang is not dependent on --- being installed to a fixed path on end-user machines. Before we --- can use Premake for the Linux build (or eventually MacOS) we would --- need to figure out how to replicate this incantation in premake. --- - --- --- Now that we've gotten all the simple projects out of the way, it is time --- to get into the more serious build steps. --- --- First up is the `slang` dynamic library project: --- - -standardProject "slang" - uuid "DB00DA62-0533-4AFD-B59F-A67D5B3A0808" - kind "SharedLib" - links { "core" } - warnings "Extra" - flags { "FatalWarnings" } - - -- The way that we currently configure things through `slang.h`, - -- we need to set a preprocessor definitions to ensure that - -- we declare the Slang API functions for *export* and not *import*. - -- - defines { "SLANG_DYNAMIC_EXPORT" } - - includedirs { "external/spirv-headers/include" } - - -- On some tests with MSBuild disabling these made build work. - -- flags { "NoIncrementalLink", "NoPCH", "NoMinimalRebuild" } - - -- The `standardProject` operation already added all the code in - -- `source/slang/*`, but we also want to incldue the umbrella - -- `slang.h` header in this prject, so we do that manually here. - files { "slang.h" } - - files { "source/core/core.natvis" } - - -- - -- The most challenging part of building `slang` is that we need - -- to invoke the `slang-generate`tools to generate the version - -- of the Slang standard library that we embed into the compiler. - -- We need to build the `slang-cpp-extractor` for similar reasons. - -- + + +generatorProject("run-generators", "source/slang/") + + -- We make 'source/slang' the location of the source, to make paths to source + -- relative to that + + -- We include these, even though they are not really part of the dummy + -- build, so that the filters below can pick up the appropriate locations. + + files + { + "source/slang/*.meta.slang", -- The stdlib files + "source/slang/slang-ast-reflect.h", -- The C++ reflection + + -- + -- To build we need to have some source! It has to be a source file that + -- does not depend on anything that is generated, so we take something + -- from core that will compile without any generation. + -- + + "source/core/slang-string.cpp", + } + -- First, we need to ensure that `slang-generate`/`slang-cpp-extactor` -- gets built before `slang`, so we declare a non-linking dependency between -- the projects here: -- dependson { "slang-cpp-extractor", "slang-generate" } - -- If we are not building glslang from source, then be - -- sure to copy a binary copy over to the output directory - if not buildGlslang then - filter { "system:windows" } - postbuildcommands { - "{COPY} ../../external/slang-binaries/bin/" .. targetName .. "/slang-glslang.dll %{cfg.targetdir}" - } - - filter { "system:linux" } - postbuildcommands { - "{COPY} ../../../external/slang-binaries/bin/" .. targetName .. "/libslang-glslang.so %{cfg.targetdir}" - } + local executableSuffix = ""; + if(os.target() == "windows") then + executableSuffix = ".exe"; end - - filter { "system:linux" } - -- might be able to do pic(true) - buildoptions{"-fPIC"} - + -- We need to run the C++ extractor to generate some include files if executeBinary then filter "files:**/slang-ast-reflect.h" @@ -795,11 +796,6 @@ standardProject "slang" -- buildoutputs { sourcePath .. "slang-ast-generated.h", sourcePath .. "slang-ast-generated-macro.h"} - local executableSuffix = ""; - if(os.target() == "windows") then - executableSuffix = ".exe"; - end - -- Make it depend on the extractor tool itself local buildInputTable = { "%{cfg.targetdir}/slang-cpp-extractor" .. executableSuffix } for key, inputFile in ipairs(inputFiles) do @@ -820,7 +816,7 @@ standardProject "slang" filter "files:**.meta.slang" -- Specify the "friendly" message that should print to the build log for the action buildmessage "slang-generate %{file.relpath}" - + -- Specify the actual command to run for this action. -- -- Note that we use a single-quoted Lua string and wrap the path @@ -835,7 +831,15 @@ standardProject "slang" -- This needs to be specified because the custom action will only -- run when this file needs to be generated. -- - buildoutputs { "%{file.relpath}.h" } + -- Note the use of abspath here, this ensures windows tests the correct file, otherwise + -- triggering doesn't work. The problem still remains on linux, because abspath *isn't* an + -- absolute path, it remains relative. + -- + -- TODO(JS): + -- It's not clear how to determine how to create the absolute path on linux, using + -- path.absolutepath, requires knowing the path to be relative to, and it's neither + -- the current path, the source path or the targetpath. + buildoutputs { "%{file.abspath}.h" } -- We will specify an additional build input dependency on the `slang-generate` -- tool itself, so that changes to the code for the tool cause the generation @@ -845,16 +849,79 @@ standardProject "slang" -- that the target platform will use. Premake might have a built-in way to -- query this, but I couldn't find it, so I am just winging it for now: -- - local executableSuffix = ""; - if(os.target() == "windows") then - executableSuffix = ".exe"; - end -- buildinputs { "%{cfg.targetdir}/slang-generate" .. executableSuffix } end + + +-- +-- TODO: Slang's current `Makefile` build does some careful incantations +-- to make sure that the binaries it generates use a "relative `RPATH`" +-- for loading shared libraries, so that Slang is not dependent on +-- being installed to a fixed path on end-user machines. Before we +-- can use Premake for the Linux build (or eventually MacOS) we would +-- need to figure out how to replicate this incantation in premake. +-- +-- +-- Now that we've gotten all the simple projects out of the way, it is time +-- to get into the more serious build steps. +-- +-- First up is the `slang` dynamic library project: +-- +standardProject "slang" + uuid "DB00DA62-0533-4AFD-B59F-A67D5B3A0808" + kind "SharedLib" + links { "core" } + warnings "Extra" + flags { "FatalWarnings" } + + -- The way that we currently configure things through `slang.h`, + -- we need to set a preprocessor definitions to ensure that + -- we declare the Slang API functions for *export* and not *import*. + -- + defines { "SLANG_DYNAMIC_EXPORT" } + + includedirs { "external/spirv-headers/include" } + + -- On some tests with MSBuild disabling these made build work. + -- flags { "NoIncrementalLink", "NoPCH", "NoMinimalRebuild" } + + -- The `standardProject` operation already added all the code in + -- `source/slang/*`, but we also want to incldue the umbrella + -- `slang.h` header in this prject, so we do that manually here. + files { "slang.h" } + + files { "source/core/core.natvis" } + + -- + -- The most challenging part of building `slang` is that we need + -- to invoke generators such as slang-cpp-extractor and slang-generate + -- to generate. We do this by executing the run-generators 'dummy' project + -- which produces the appropriate source + + dependson { "run-generators" } + + -- If we are not building glslang from source, then be + -- sure to copy a binary copy over to the output directory + if not buildGlslang then + filter { "system:windows" } + postbuildcommands { + "{COPY} ../../external/slang-binaries/bin/" .. targetName .. "/slang-glslang.dll %{cfg.targetdir}" + } + filter { "system:linux" } + postbuildcommands { + "{COPY} ../../../external/slang-binaries/bin/" .. targetName .. "/libslang-glslang.so %{cfg.targetdir}" + } + end + + filter { "system:linux" } + -- might be able to do pic(true) + buildoptions{"-fPIC"} + + if enableProfile then tool "slang-profile" uuid "375CC87D-F34A-4DF1-9607-C5C990FD6227" |