[Mono-list] Premake now on SourceForge

J. Perkins jason@379.com
17 Jan 2003 08:50:12 -0500


On Thu, 2003-01-16 at 21:44, Miguel de Icaza wrote:
>    It might be useful if you posted a small summary of how to build
> these pre-make files, because the project looks interesting, but am sure
> others would like to see a small overview on the list.

There is a short example on the website (http://premake.sf.net/), as
well as a complete list of the supported XML tags. But I'll try to give
a quick overview here.

(Actually, this turned out to be pretty long, hey I got on a roll...)

You set up your project in a similar fashion to MSVS: a "project" file
that lists the parts you need to build (like a .dsw/.sln file), and then
"packages" that describe each individual binary target (like the
.dsp/.csproj files).

I am currently playing around with a .NET wrapper for wxWindows. For
this project I have three parts: a DLL written in C which wraps the
wxWin C++ library, a C# library that exposes this API as .NET objects,
and finally a C# executable that tests the whole thing out. It look like
this:

  wx.NET/
    Samples/
      Minimal/
        Minimal.cs
    Src/
      wx.NET/
        Application.cs
        Frame.cs
        Object.cs
        Window.cs
      wx-C/
        application.cxx
        build_environ.h
        frame.cxx
        object.cxx
        window.cxx

At the top level of the project, I create a file called "project.xml"
(you can change the name, but premake looks for this by default) that
looks like this:

  <project>
    <name>wx.NET</name>
    <bindir>Bin</bindir>
    <uses>Src/wx-C</uses>
    <uses>Src/wx.NET</uses>
    <uses>Samples/Minimal</uses>
  </project>

That's pretty easy. The <name> gets used as a file name for the MSVS
workspace/solution file. <bindir> specifies where the compiled binaries
should go (wx.NET/Bin). And then a list of the packages to build.

In Samples/Minimal I create a file called "package.xml" that's just as
short:

  <package>
    <name>Minimal</name>
    <language>c#</language>
    <type>winexe</type>
    <target>minimal</target>
    <link>System.Drawing</link>
    <link>wx.NET</link>
    <file>Minimal.cs</file>
  </package>

Again, <name> is used as a file name. Language and type are obvious.
<target> specifies the target filename (minimal.exe) and can include
subdirectories. <link> lists referenced assemblies or dependent
packages. If <link> uses the name of a sibling package, premake will
automatically figure out the right filename to reference and set up the
proper dependencies in the build script. Finally, <file> lists all of
the source files to build.

The Src/wx.NET package.xml file looks very similar, but now I am
building a library:

  <package>
    <name>wx.NET</name>
    <language>c#</language>
    <type>library</type>
    <link>System.Drawing</link>
    <link>wx-C</link>
    <file>Application.cs</file>
    <file>Frame.cs</file>
    <file>Object.cs</file>
    <file>Window.cs</file>
  </package>

I list wx-C, an unmanaged C DLL, in the list of links. In this case,
premake will just set up the proper dependency in the build script, it
won't actually tell the C# compiler to reference it.

The wx-C/package.xml if kind of long because of all the wxWin settings,
so I'll just do a subset here:

  <package>
    <name>wx-C</name>
    <language>c++</language>
    <type>dll</type>

    <build-flag>no-64bit-checks</build-flag>

    <linux>
      <build-option>`wx-config --cflags`</build-option>
      <link-option>`wx-config --libs`</link-option>
    </linux>

    <windows>
      <define>WIN32</define>
      <define>wxUSE_GUI=1</define>
      <link>comctl32</link>
      <debug>
        <define>_DEBUG</define>
        <define>WXDEBUG=1</define>
        <link>wxmswd</link>
      </debug>
      <release>
        <define>NDEBUG</define>
        <link>wxmsw</link>
      </release>
    </windows>

    <file>build_environ.h</file>
    <file>application.cxx</file>
  </package>

Alright, quickly: <build-flag> is for compiler flags, it gets translated
to the proper command line flags for the platform's compiler.
<build-option> just sticks the enclosed text onto the compiler command
line and assumes that you know what you're doing. <link-option> is the
same for the linker. <linux> and <windows> enclose platform specific
build settings. <debug> and <release> allow different settings for those
builds. <define> sets preprocessor symbols. 

There you go. To make the build scripts, you cd to the top directory and
type one of 'premake -gnu', 'premake -vs6', or 'premake -vs7'. The
command 'premake --clean' removes all build scripts, intermediate files,
and binaries.
  
Sorry for the long post, hope it was helpful.

Jason
379