forked from premake/premake-core
-
Notifications
You must be signed in to change notification settings - Fork 1
/
BUILD.txt
103 lines (70 loc) · 3.88 KB
/
BUILD.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
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/gmake.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:
$ git submodule init
$ git submodule update
$ 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 gmake # 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.