Home » Premake » Forums » News & Announcements

Platforms 2.0

starkos | 25 Jan 2012

Thanks to a new client with a fantastically complicated multi-platform, multi-architecture build, I've had the opportunity to begin work on a new platform configuration API for Premake. The first set of changes are now in premake-dev, and I've posted an overview of the new system to the premake-dev wiki.

The old API solved the most common cases and allowed Premake to support game consoles, but in "real world" use proved terribly limited and inflexible. And the code to support it was messy—I hated working on those bits.

The new system is...ambitious, and it is going to take some time to get it fully implemented, so bear with me. But it is also more intuitive and far more flexible. It will make it much easier to support new platforms (iOS anyone?). And since it requires a rewrite of much of Premake's configuration building code, I have the opportunity to address some long-standing issues (such as the inability to query settings from within a project script).

Feedback, as always, is welcomed. As are your questions, though I may not have answers for everything yet.

Have a look, and enjoy!

Premake 4.4-beta4 released ›
Anonymous | 01 Feb 2012 11:52

How long will the transition take? We're planning to write our own version of the Xcode plugin for iOS builds; should we put off our plans until the new API is done, or can we easily translate the old plugin to the new one?

starkos | 01 Feb 2012 14:15

I don't know how long it will take. The Visual Studio work is being funded by a client, so that will happen quickly. But then I will be moving into tool and configuration work, so Make and Xcode support is likely to lag. Also, I don't have a good sense of how I'm going to shoehorn this approach into Xcode; some discovery work is needed.

If you have the time and resources, I would definitely take a look at the new API. I would happy to answer questions and help you get started. But it will certainly be more work than retrofitting the current premake-stable code.

DonOlmstead | 24 Feb 2012 21:48

Glad to hear the platform stuff is getting an overhaul.

One concern I have is this example.

configuration { "Debug", "Release" }
platforms { "Static", "DLL" }
 
configuration { "Static" }
    kind "StaticLib"
 
configuration { "DLL" }
    kind "SharedLib"
    defines { "DLL_EXPORTS" }

Is Static and DLL really a platform? I get that it'd be nice to define DLL_EXPORTS for a DebugDLL and ReleaseDLL in one place, but it seems to muddy the concept of a platform. Is there maybe a more expressive way of doing this? For the DLL maybe there's a generic configuration that can be descended from so for example.

configuration { "Debug DLL" }
   descends "DLL"
annulen | 25 Feb 2012 11:12

>I get that it'd be nice to define DLL_EXPORTS for a DebugDLL and ReleaseDLL in one place

configuration "*DLL"
    kind "SharedLib"
    defines { "DLL_EXPORTS" }
Liam | 25 Feb 2012 12:42

+1 "but it seems to muddy the concept of a platform"

starkos | 25 Feb 2012 15:45

Here's a use case: "Debug", "Profile", and "Release" configurations, targeting:

  • Win32, with libraries compiled as DLLs, dynamic linking the CRT
  • WIn32, with libraries compiled as static, static linking the CRT
  • WIn32, with libraries compiled as static, dynamic linking the CRT
  • Win64, with the same variations as above
  • PS3, both PPU and SPU, using GCC
  • PS3, PPU and SPU, using SNC
  • Xbox360
sajty | 13 May 2012 10:40

Hi!
I think that the new API is still not scalable.
What if I want to separate win32 release DLL from win64 release DLL?
How can I separate win32 release DLL with debug symbols and win32 release DLL without debug symbols?

Will it work like this?

configurations { "Debug", "Release" }
configuration { "Debug", "Release" }
    platforms { "Win32", "Win64" }
configuration { "Win32", "Win64" }
    platforms { "DLL", "Static" }

I would prefer this:

configurations { "Debug", "Release", "DLL", "Static", "Win32", "Win64" }
platforms {
    "Win32DebugDLL" = { "Win32", "Debug", "DLL"},
    "Win64DebugDLL" = { "Win64", "Debug", "DLL" } ,
    "Win32ReleaseDLL" = { "Win32", "Release", "DLL"},
    "Win64ReleaseDLL" = { "Win64", "Release", "DLL" } 
}
starkos | 14 May 2012 14:04

> What if I want to separate win32 release DLL from win64 release DLL?

configurations { "Debug", "Release" }
platforms { "x32", "x64" }
 
configuration { "Release", "x32" }
   -- Win32 release stuff
 
configuration { "Release", "x64" }
   -- Win64 release stuff

> How can I separate win32 release DLL with debug symbols and win32 release DLL without debug symbols?

configurations { "Debug", "ReleaseWithSymbols", "Release" }
 
configuration "ReleaseWithSymbols"
   -- release build with debugging symbols stuff
 
configuration "Release"
   -- release build without symbols stuff
sajty | 14 May 2012 15:18

I mean what if you want to separate Debug from Release and x32 from x64 and static from DLL?
The first example is separating Release from Debug and x32 from x64, but not static from DLL.

HiroshimaCC | 15 May 2012 16:12

I think you can add two mores configurations, DebugDLL and ReleaseDLL to the preview example and then you have all your distinctions.

starkos | 16 May 2012 14:45

I'm not sure I see the advantage of your proposed approach @sajty, since you still have to list out all of the platforms anyway. I would just write it like:

configurations { "Debug, "Release" }
platforms { "Win32 DLL", "Win32 Static", "Win64 DLL", "Win64 Static" } -- and so on
 
configuration { "*DLL" }
   -- common DLL stuff
 
configuration { "*Static" }
   -- common static stuff
 
configuraiton { "Win32*" }
   -- common Win32 stuff
 
configuration { "Win64*" }
   -- common Win64 stuff
sajty | 16 May 2012 15:44

I know, that it can be solved (even in multiple different ways).
I just wanted to point out, that this is not the optimal solution for a new design.
I would like to have all settings separated somehow, but I can live with the current one anyways. :)
I don't prefer to parse a string for substring matches.