Premake

I am doing some really rather drastic refactorings to Premake's configuration system, splitting the whole thing up into smaller, more focused (and maintainable and optimizable) "classes". Currently only string and path values are using the new ... [More] system. I will be porting the other field types, hopefully this afternoon, and then beginning the process of yanking out several metric tons of dead and deprecated code. If you have a project that can use Premake-dev, please take this opportunity to start pulling the new changes and reporting any problems you find. In theory, the refactored system should behave the same as the old one. There are a few changes to watch out for though: Solution- and project-level values now take the active configuration filter into account. The location() and language() calls are the big ones here. These used to be pushed directly to the project object, ignoring any active configuration. This was a bug that prevented project-level settings from being modified based on system or action. If you have code like the following it will now be broken; fix it by moving the location() call above the configuration, or by resetting the configuration filter. project "MyProject"   configuration "Debug" flags { "Symbols" }   -- this now gets rolled up into the configuration; -- will be ignored while generating project location "build" Direct property access may return different results. If you try to directly get or set a value on the project or configuration objects things might behave differently. -- examples of direct propery access local prjname = prj.name prj.language = "C#" For backward compatibility I've done my best to maintain the previous behavior of this kind of code. But under the hood, all property get and set operations are now taking the active configuration filter into account, so your results may be unexpected. Really, direct access of properties in this way is discouraged, and you shouldn't be doing it. I know Premake has had few historical shortcomings that made it necessary. The new token support should solve most of those problems. If you have other use cases that require direct property access, please let me know so I can make sure they get addressed. And finally… Actions that have not yet been ported to new APIs are going away. I did my best to keep the two systems up and running in parallel while development on the new platforms-related stuff matured, but things have reached the point where I need to turn off the old system to keep progress going. That means the following actions are going away in Premake-dev: Visual Studio 2002 and 2003 Xcode 3 and 4 CodeBlocks CodeLite The new, "next-generation" (i.e. "vs2008ng", "vs2010ng", "gmakeng") will be replacing their previous counterparts. I will definitely be bringing Xcode 4 back as soon as I can. The fate of the others is undecided: I would love to keep them, but I'm not sure any of them are important enough to hold up the eventual 5.0 release. I may leave it up to interested members of the community to port them. Thanks everyone! [Less]

I am doing some really rather drastic refactorings to Premake's configuration system, splitting the whole thing up into smaller, more focused (and maintainable and optimizable) "classes". Currently only string and path values are using the new ... [More] system. I will be porting the other field types, hopefully this afternoon, and then beginning the process of yanking out several metric tons of dead and deprecated code. If you have a project that can use Premake-dev, please take this opportunity to start pulling the new changes and reporting any problems you find. In theory, the refactored system should behave the same as the old one. There are a few changes to watch out for though: Solution- and project-level values now take the active configuration filter into account. The location() and language() calls are the big ones here. These used to be pushed directly to the project object, ignoring any active configuration. This was a bug that prevented project-level settings from being modified based on system or action. If you have code like the following it will now be broken; fix it by moving the location() call above the configuration, or by resetting the configuration filter. project "MyProject"   configuration "Debug" flags { "Symbols" }   -- this now gets rolled up into the configuration; -- will be ignored while generating project location "build" Direct property access may return different results. If you try to directly get or set a value on the project or configuration objects things might behave differently. -- examples of direct property access local prjname = prj.name prj.language = "C#" For backward compatibility I've done my best to maintain the previous behavior of this kind of code. But under the hood, all property get and set operations are now taking the active configuration filter into account, so your results may be unexpected. Really, direct access of properties in this way is discouraged, and you shouldn't be doing it. I know Premake has had a few historical shortcomings that made it necessary. The new token support should solve most of those problems. If you have other use cases that require direct property access, please let me know so I can make sure they get addressed. And finally… Actions that have not yet been ported to new APIs are going away. I did my best to keep the two systems up and running in parallel while development on the new platforms-related stuff matured, but things have reached the point where I need to turn off the old system to keep progress going. That means the following actions are going away in Premake-dev: Visual Studio 2002 and 2003 Xcode 3 and 4 CodeBlocks CodeLite The new, "next-generation" (i.e. "vs2008ng", "vs2010ng", "gmakeng") will be replacing their previous counterparts. I will definitely be bringing Xcode 4 back as soon as I can. The fate of the others is undecided: I would love to keep them, but I'm not sure any of them are important enough to hold up the eventual 5.0 release. I may leave it up to interested members of the community to port them. Thanks everyone! [Less]

Premake 4.4 continues to be dragged, kicking and screaming, toward its inevitable release, with today's release of the fourth, and last, beta. Get it here Last beta means no new features from this point out, just bug fixes and more bug fixes. Please ... [More] test the heck out of it, and file bugs for any problems you find. The current change list looks like this: Feature 1590022: Source file filtering and grouping Feature 3100379: C# support for Visual Studio 2010 Feature 1657833: Set working directory for debugging Added support for Haiku OS (Yuriy O'Donnell) Patch 2963313: Enable setting .NET framework version (Justen Hyde) Switched PS3 builds from GCC to SNC Ignore NoRTTI flag for Managed C++ projects (Nick Darnell) Added host.is64bit Added os.getversion Patch 3140456: Explicitly specify architecture for VS StaticLib (Brian Mazza) Bug 3119793: Fixed ClCompile blocks with vs10 and PCH (Dan Dunham) Bug 2920784: Symbol visibility in Xcode3 libraries (burnson2) Bug 3133743: Sets ONLY_ACTIVE_ARCH = YES in Xcode debug builds (James Wynn) Properly pass return codes back to shell in release builds Bug 3135734: Remove WholeProgramOptimization setting in vs10 (doug) Bug 3138377: Link dependencies ignored within "SharedLib" configuration Bug 3163703: pdb file being set in the wrong section. (hodsondd) Bug 3157645: Full path for xcode frameworks Bug 3232160: Environment variables are cut off Patch 3043933 Allow gmake to use static lib when shared lib of same name exists (Jonathan Derque) Bug 3294459: vs10 x86_64 using incorrect debug format for minimal rebuild (learner) Bug 3297634: Special characters in directory name Xcode3 (jdale) Feature 3100194: English aliases for Optimize flags Bug 3308203: Incorrect relative paths for gmake sibling static libraries (Adam) Bug 3277343: SM_SERVERR2 is not always defined by default (Martin Ridgers) Added os.stat Bug 3381149: Path of PCH source file in VS10 not being translated (intyuh) Patch 3021550: Add Wii homebrew platform (Pathogen David) Patch 3035550: Make/Distcc outputs dependencies to wrong location Patch 3138574: NoImportLib ignored in Windows makefiles dependencies (rjmyst3) Patch 3367641: Remove warnings in Xcode 4 Patch 3372345: Gmake action's PCHs don't work with Mingw (Martin Ridgers) Patch 3317329: Support vstudio CompileAs for mixed-language projects (xpol) Patch 3337372: Improved precompiled header support (Anders Ericsson) Patch 3401184: Fix Gmake LDFLAGS generation order (Adam Petrone) Patch 3381066: Fix VS2010 project references Added debug environment variable support for Visual Studio Added debug environment variable support for Codeblocks using gdb Bug: Visual Studio 2010 forces x86 when platform is Native Patch 3351583: _PREMAKE_COMMAND variable (Konstantin Tokarev) Added new global _WORKING_DIR Patch 3451928: VS2008 trying to build *.h files in C projects Patch 3429777: Support for DragonFly BSD (Joachim de Groot) Patch 3445049: Build fix for FreeBSD (Konstantin Tokarev) Bug 3121217: Test suite fails on Linux x86_64: os.findlib broken Patch 3428348: Add .gitignore file (Konstantin Tokarev) Patch 3430158: Reorder LINKCMD for Gmake (rjmyst3) Patch 3451212: Fix Visual Studio MFC with StaticRuntime Patch 3463020: Add windres environment variable for makefiles (icebreaker) Bug 3413866: Incorrect VS200x .csproj relative source paths Patch 3111264: Allow path.join() to accept any number of args Patch 3353975: Support usage of premake as a library (Konstantin Tokarev) [Less]

Premake 4.4 continues to be dragged, kicking and screaming, toward its inevitable release, with today's release of the fourth, and last, beta. Get it here Last beta means no new features from this point out, just bug fixes and more bug fixes. ... [More] Please test the heck out of it, and file bugs for any problems you find. The current change list looks like this: Feature 1590022: Source file filtering and grouping Feature 3100379: C# support for Visual Studio 2010 Feature 1657833: Set working directory for debugging Added support for Haiku OS (Yuriy O'Donnell) Patch 2963313: Enable setting .NET framework version (Justen Hyde) Switched PS3 builds from GCC to SNC Ignore NoRTTI flag for Managed C++ projects (Nick Darnell) Added host.is64bit Added os.getversion Patch 3140456: Explicitly specify architecture for VS StaticLib (Brian Mazza) Bug 3119793: Fixed ClCompile blocks with vs10 and PCH (Dan Dunham) Bug 2920784: Symbol visibility in Xcode3 libraries (burnson2) Bug 3133743: Sets ONLY_ACTIVE_ARCH = YES in Xcode debug builds (James Wynn) Properly pass return codes back to shell in release builds Bug 3135734: Remove WholeProgramOptimization setting in vs10 (doug) Bug 3138377: Link dependencies ignored within "SharedLib" configuration Bug 3163703: pdb file being set in the wrong section. (hodsondd) Bug 3157645: Full path for xcode frameworks Bug 3232160: Environment variables are cut off Patch 3043933 Allow gmake to use static lib when shared lib of same name exists (Jonathan Derque) Bug 3294459: vs10 x86_64 using incorrect debug format for minimal rebuild (learner) Bug 3297634: Special characters in directory name Xcode3 (jdale) Feature 3100194: English aliases for Optimize flags Bug 3308203: Incorrect relative paths for gmake sibling static libraries (Adam) Bug 3277343: SM_SERVERR2 is not always defined by default (Martin Ridgers) Added os.stat Bug 3381149: Path of PCH source file in VS10 not being translated (intyuh) Patch 3021550: Add Wii homebrew platform (Pathogen David) Patch 3035550: Make/Distcc outputs dependencies to wrong location Patch 3138574: NoImportLib ignored in Windows makefiles dependencies (rjmyst3) Patch 3367641: Remove warnings in Xcode 4 Patch 3372345: Gmake action's PCHs don't work with Mingw (Martin Ridgers) Patch 3317329: Support vstudio CompileAs for mixed-language projects (xpol) Patch 3337372: Improved precompiled header support (Anders Ericsson) Patch 3401184: Fix Gmake LDFLAGS generation order (Adam Petrone) Patch 3381066: Fix VS2010 project references Added debug environment variable support for Visual Studio Added debug environment variable support for Codeblocks using gdb Bug: Visual Studio 2010 forces x86 when platform is Native Patch 3351583: _PREMAKE_COMMAND variable (Konstantin Tokarev) Added new global _WORKING_DIR Patch 3451928: VS2008 trying to build *.h files in C projects Patch 3429777: Support for DragonFly BSD (Joachim de Groot) Patch 3445049: Build fix for FreeBSD (Konstantin Tokarev) Bug 3121217: Test suite fails on Linux x86_64: os.findlib broken Patch 3428348: Add .gitignore file (Konstantin Tokarev) Patch 3430158: Reorder LINKCMD for Gmake (rjmyst3) Patch 3451212: Fix Visual Studio MFC with StaticRuntime Patch 3463020: Add windres environment variable for makefiles (icebreaker) Bug 3413866: Incorrect VS200x .csproj relative source paths Patch 3111264: Allow path.join() to accept any number of args Patch 3353975: Support usage of premake as a library (Konstantin Tokarev) [Less]

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 ... [More] 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! [Less]

Just a heads up: I am going to drop a big set of changes—the beginnings of a new and improved platforms API—into premake-dev tomorrow. Ideally, it should all be backward compatible, but changes are changes. More information coming tomorrow.

Today I've released 3 components for integrated development of Qt-based software with Premake build configuration tool. qt-support.lua 1.0 This is an add-on for Premake allowing you to use Qt 4 modules in your projects. Qt-specific code generation ... [More] steps are added automatically - all you need is to add sources, headers, *.ui, *.qrc., and *.ts files into ''files'' list! Behavior of qt-support.lua almost entirely matches behavior of qmake, allowing painless migration. As usual for Premake and opposed to qmake, by default generated Makefiles are redistributable. Documentation: Getting started with Qt and Premake Manual Current limitations Several patches for Premake are needed (see the next release header) Only gmake action is supported On Mac OS X only "framework" configuration is supported The next Qt modules are not supported yet: ActiveQt, QtDBus, QtDesigner, Phonon Downloads File is included into packages of Premake 4.4-qt-beta1. Premake 4.4-qt-beta1 This is an unofficial Premake beta release, based on premake-stable branch with extra patches needed for Qt support: Added custom makefile sections (header, config, footer, clean)* Added new functions "newapi" and "newapis"* Use debug.traceback() as error handler Support shadow builds Support usage of premake as a library Added 'isinternal' property of action* Track all dofiles executed in scriptfile Implemented post-bake hooks* Added newflag function Removed -flat_namespace* Use one define to select branch in premake.c I hope they will be included into Premake 4.4 release; however only patches marked with * are absolutely required (others are needed for Qt Creator plugin - see below). Downloads (all packages include qt-support.lua) Windows 32-bit Mac OS X Universal (10.4 and higher; PPC + i386) Linux x86 Linux x86_64 Source code PremakeProjectManager 0.2 This is a plugin for Qt Creator IDE, providing native support for premake4.lua projects. Just open premake4.lua in Qt Creator, and you'll be able to browse your project contents, build, and debug it! Plugin works with Qt Creator 2.3.x or 2.4.0 (either from QtSDK or stand-alone); older versions and master are not supported. New in version 0.2 Windows support (including pre-compiled binaries) Qt support Generated files are hidden by default Toolchain switching is possible Parsing of compiler output works Support for Qt Creator 2.4 Support for Qt Creator 2.2 was removed To debug inside IDE, you will need to browse for executable file. However, on Windows debugging is currently broken. Downloads Qt Creator 2.3.1 Windows 32-bit Qt Creator 2.4.0 Windows 32-bit Source code To install, unpack archive and copy contents (two files) into /lib/qtcreator/plugins/Nokia If you have found any issues with this software, or something is not clear in documentation, or you need additional features, or you are willing to contribute, please leave a comment in this topic or write to our mailing list (premake-users at sourceforege.net). Enjoy! starkos: Is it OK to use main bug tracker for Qt-specific issues, or they should better go to other place (e.g., tracker on GitHub in my project)? [Less]

Hi all, I've created a wiki [1] with some drafts of unofficial developer documentation. Right now it's very incomplete and can contain blatantly wrong information, however I'll try to update it while my knowledge of Premake internals is growing. Of ... [More] course, I invite anyone with some knowledge of Premake to edit and extend this wiki. [1] http://lorcode.org/wiki/Premakehttp://lorcode.org/wiki/Premake [Less]

Getting on a roll now: the third 4.4 beta is now available for download. With this release, the new virtual paths feature is complete and ready to go. Please test the heck out of it, and file bugs for any problems you find. With that out of the way ... [More] , I'll be taking a pass over the trackers, applying as many patches and fixing as many bugs as I can before the final release. And you can help! With your assistance finding and reporting bugs, testing and providing feedback on patches and submitting patches for existing bugs we can get 4.4 out the door quickly. Feedback on the new feature(s) is very much appreciated. Enjoy! [Less]

Hi all! I'm pleased to announce 0.1 version of my plugin for Qt Creator, allowing to work with Premake as native project format. "0.1" means that plugin is still far from being feature complete, but works relatively stable and already has something ... [More] interesting for general audience. What is done: premake4.lua files are opened as native project files. Visualization of project file tree is available, and you may select and edit files, just like with QMake or CMake projects. Plugin brings more thorough support of Lua in text editor: syntax highlighting on all platforms, indentation, and (very basic) autocompletion (e.g. pairs of parentheses) Plugin can build simple projects out of the box - just open premake4.lua and click "Build All" or "Build project". I've tested it on Premake project. So, if you are brave enough, get the sources (if you don't have Git you can use "download as tar.gz" link on Gitorious, build it on your favorite platform, and report here! More info about planned features @starkos: Sorry if I've chosen wrong forum for this message - feel free to move it wherever it belongs to. [Less]