102 lines
3.9 KiB
Plaintext
102 lines
3.9 KiB
Plaintext
|
PREMAKE BUILD INSTRUCTIONS
|
||
|
|
|
||
|
|
Premake is written in a mix of C and Lua. A small host executable,
|
||
|
|
written in C, launches the app and prepares the environment, at which
|
||
|
|
point control is handed off to a Lua script. Almost all of Premake is
|
||
|
|
written in Lua scripts, which allow it to be easily extended and
|
||
|
|
customized. The catch is that it is slightly more complicated to build
|
||
|
|
it than your typical C/C++ application.
|
||
|
|
|
||
|
|
If you find all of this very confusing and need some help, visit the
|
||
|
|
Premake website for help and community links. We will be glad to help!
|
||
|
|
|
||
|
|
|
||
|
|
BUILDING FROM A SOURCE PACKAGE
|
||
|
|
|
||
|
|
If you downloaded a source code package (as opposed to pulling the sources
|
||
|
|
directory from the repository) you will find project files for all of the
|
||
|
|
officially supported toolsets in the build/ folder. Build the release
|
||
|
|
configuration and you will be ready to go. For makefiles:
|
||
|
|
|
||
|
|
$ cd build/gmake2.unix
|
||
|
|
$ make config=release
|
||
|
|
|
||
|
|
The binaries will be placed in the ./bin/release directory.
|
||
|
|
|
||
|
|
|
||
|
|
BUILDING FROM THE REPOSITORY
|
||
|
|
|
||
|
|
If you have pulled sources from the Premake source repository, you can
|
||
|
|
use `Bootstrap.mak` to generate your first premake executable:
|
||
|
|
|
||
|
|
$ make -f Bootstrap.mak PLATFORM
|
||
|
|
|
||
|
|
Where PLATFORM can be osx or linux.
|
||
|
|
On Windows with Visual Studio use nmake:
|
||
|
|
|
||
|
|
$ nmake -f Bootstrap.mak windows
|
||
|
|
|
||
|
|
Or on Windows with MinGW use mingw32-make:
|
||
|
|
|
||
|
|
$ CC=mingw32-gcc mingw32-make -f Bootstrap.mak mingw
|
||
|
|
|
||
|
|
If your toolset is not supported by the bootstrap Makefile, you will need
|
||
|
|
to embed the scripts into a C source file so they may be built into the
|
||
|
|
executable, and also generate the project files for your chosen toolset. In
|
||
|
|
order do either of these things, you will need a working Premake executable.
|
||
|
|
|
||
|
|
The easiest way to get an executable is to download one of the prebuilt
|
||
|
|
binaries from the project website. If that isn't possible, or if not binary
|
||
|
|
is provided for your platform, you can build from a source package as
|
||
|
|
described above, as they also include pre-generated project files.
|
||
|
|
|
||
|
|
Once you have a working Premake available, you can generate the project
|
||
|
|
files for your toolset by running a command like the following in the
|
||
|
|
top-level Premake directory:
|
||
|
|
|
||
|
|
$ premake5 gmake2 # for makefiles
|
||
|
|
$ premake5 vs2012 # for a Visual Studio 2012 solution
|
||
|
|
$ premake --help # to see a list of supported toolsets
|
||
|
|
|
||
|
|
If this is the first time you have built Premake, or if you have made
|
||
|
|
changes to the Lua scripts, you should prepare them to be embedded into the
|
||
|
|
Premake executable.
|
||
|
|
|
||
|
|
$ premake5 embed
|
||
|
|
|
||
|
|
This creates a C file (at src/host/scripts.c) which contains all of the
|
||
|
|
Lua scripts as static string buffers. These then get compiled into the
|
||
|
|
executable, which is how we get away with shipping a single file instead
|
||
|
|
of a whole bunch of scripts.
|
||
|
|
|
||
|
|
You should now have a solution/makefile/workspace in the top-level folder,
|
||
|
|
which you can go ahead and build.
|
||
|
|
|
||
|
|
|
||
|
|
RUNNING THE TESTS
|
||
|
|
|
||
|
|
Once you have built an executable, you can verify it by running Premake's
|
||
|
|
unit test suites. From the top-level Premake folder, run:
|
||
|
|
|
||
|
|
$ bin/release/premake5 test
|
||
|
|
|
||
|
|
|
||
|
|
RUNTIME SCRIPT LOADING
|
||
|
|
|
||
|
|
If you are modifying or extending Premake, you can skip the embedding
|
||
|
|
and compilation steps and run the scripts directly from the disk. This
|
||
|
|
removes the build from the change-build-test cycle and really speeds up
|
||
|
|
development.
|
||
|
|
|
||
|
|
If you are running Premake from the top of its own source tree (where its
|
||
|
|
premake5.lua is located) you will get this behavior automatically. If you
|
||
|
|
are running Premake from some other location, use the --scripts option to
|
||
|
|
provide the path to that top-level folder:
|
||
|
|
|
||
|
|
$ bin/release/premake5 --scripts=../path/to/premake test
|
||
|
|
|
||
|
|
If you find yourself doing this repeatedly, or if you want Premake to be
|
||
|
|
able to find other, custom scripts, you can also set a search path with the
|
||
|
|
PREMAKE_PATH environment variable. Set it just like you would set your
|
||
|
|
system PATH variable.
|