Update build instructions for new embedding logic
This commit is contained in:
parent
67f6fba149
commit
37e564b23c
157
BUILD.txt
157
BUILD.txt
@ -1,127 +1,90 @@
|
||||
PREMAKE BUILD INSTRUCTIONS
|
||||
|
||||
Premake is written in a mix of C and Lua. This mix enables many new
|
||||
features, but also makes building Premake a bit more complicated than
|
||||
your typical application.
|
||||
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 downloaded a source code package from SourceForge (as opposed
|
||||
to pulling the sources from the repository), you will find project
|
||||
files for all of the currently supported toolsets in the build/ folder.
|
||||
Build the release configuration (the default for the makefiles) and you
|
||||
will find the executable in bin/release ready to go.
|
||||
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
|
||||
$ make config=release
|
||||
|
||||
The binaries will be left in the bin/release directory.
|
||||
|
||||
If you want to use a debug build instead, or if you pulled the sources
|
||||
from BitBucket instead of a SourceForge release, or if you plan on
|
||||
making changes to Premake, read the next section to learn how to
|
||||
prepare the project files.
|
||||
|
||||
If you find all of this very confusing and need some help, see the end
|
||||
of this document for contact information. I'll be glad to help. And if
|
||||
you have any suggestions for improving this process, I'd be glad to
|
||||
hear them too.
|
||||
The binaries will be placed in the ./bin/release directory.
|
||||
|
||||
|
||||
GENERATING THE PROJECT FILES
|
||||
BUILDING FROM THE REPOSITORY
|
||||
|
||||
If you downloaded a source code package from SourceForge, the project
|
||||
files are already included (in build/) and you can skip ahead to the
|
||||
next section.
|
||||
If you have pulled sources from the Premake source repository, 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.
|
||||
|
||||
If you pulled the sources from BitBucket, you'll need to generate your
|
||||
own project files before you can build.
|
||||
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.
|
||||
|
||||
We use Premake to generate the project files for Premake (bootstrapping,
|
||||
or eating our own dog food). So in order to generate the project files,
|
||||
you need to have a working version of Premake 5.x installed on your
|
||||
system. You can get it as source code (with pre-generated project files
|
||||
ready to build) or a prebuilt binary from the SourceForge download page.
|
||||
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:
|
||||
|
||||
Once you have a working Premake 5.x installed, the first thing you need
|
||||
to do is to embed the Lua scripts into the application by running this
|
||||
command 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
|
||||
|
||||
premake5 embed
|
||||
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 one executable and whole bunch of scripts. See EMBEDDING THE SCRIPTS,
|
||||
below, for more information.
|
||||
of a whole bunch of scripts.
|
||||
|
||||
Now you can generate project files for your toolset of choice by running
|
||||
a command like:
|
||||
|
||||
premake5 gmake -- for GNU makefiles using GCC
|
||||
premake5 vs2008 -- for a Visual Studio 2008 solution
|
||||
|
||||
Use the "--help" option to see all of the available targets.
|
||||
|
||||
This will create a solution/makefile/workspace in the top-level folder,
|
||||
which you can now go ahead and build.
|
||||
You should now have a solution/makefile/workspace in the top-level folder,
|
||||
which you can go ahead and build.
|
||||
|
||||
|
||||
RELEASE vs. DEBUG BUILDS
|
||||
RUNNING THE TESTS
|
||||
|
||||
Premake can be built in either "release" or "debug" modes. Makefile users
|
||||
can choose which configuration to build with the "config" argument:
|
||||
Once you have built an executable, you can verify it by running Premake's
|
||||
unit test suites. From the top-level Premake folder, run:
|
||||
|
||||
make config=debug -- build in debug mode
|
||||
make config=release -- build in release mode
|
||||
|
||||
IDEs like Visual Studio provide their own mechanism for switching build
|
||||
configurations.
|
||||
|
||||
In release mode you can build and run Premake like any other C application
|
||||
(once you've embedded the scripts, see the next section).
|
||||
|
||||
In debug mode, Premake ignores the embedded Lua scripts and instead reads the
|
||||
latest versions from the disk at runtime. This allows you to change a script,
|
||||
and then immediately test it without having to embed or compile first. Speedy!
|
||||
But Premake needs some help to find the scripts.
|
||||
|
||||
You can specify the location of the scripts in one of two ways: using
|
||||
the /scripts command line argument, like so:
|
||||
|
||||
premake5 /scripts=~/Code/premake5/src gmake
|
||||
|
||||
Or by setting a PREMAKE_PATH environment variable.
|
||||
|
||||
PREMAKE_PATH=~/Code/premake5/src
|
||||
|
||||
As you can see, you need to specify the location of the Premake "src"
|
||||
directory, the one containing "_premake_main.lua".
|
||||
$ bin/release/premake5 test
|
||||
|
||||
|
||||
EMBEDDING THE SCRIPTS
|
||||
RUNTIME SCRIPT LOADING
|
||||
|
||||
One of the nice things about Premake is that it comes as a single file,
|
||||
easy to install or move around. To manage this, we need to embed all of
|
||||
the Lua scripts into the executable, so we can deliver just the one file,
|
||||
rather than an executable and a whole bunch of scripts.
|
||||
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.
|
||||
|
||||
Scripts are embedded by running the command
|
||||
Assuming you have already built an executable, you just need to tell
|
||||
Premake where to look for the scripts. If, for example, you wanted to
|
||||
run from the top-level Premake folder, you could do this:
|
||||
|
||||
premake5 embed
|
||||
$ bin/release/premake5 --scripts=src test
|
||||
|
||||
This copies all of the scripts listed in _manifest.lua into the file
|
||||
src/host/scripts.c, where they are represented as a set of static C
|
||||
string buffers. This file is then compiled as part of Premake's release
|
||||
builds.
|
||||
If you are running from a different location, adjust value for the scripts
|
||||
argument accordingly.
|
||||
|
||||
So: very important to embed the scripts before each release build!
|
||||
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.
|
||||
|
||||
|
||||
CONFUSED?
|
||||
|
||||
I'll be glad to help you out. Stop by the main project website where
|
||||
you can leave a note in the forums (the preferred approach), join the
|
||||
mailing list, or contact me directly.
|
||||
|
||||
http://industriousone.com/premake
|
||||
|
||||
Enjoy!
|
||||
|
Loading…
Reference in New Issue
Block a user