Premake

As previously discussed in the previous Repository Reshuffling post: I am renaming premake-stable to premake-4.x, making the new URL https://bitbucket.org/premake/premake-4.x. If you have cloned this repository locally, you can repoint it by ... [More] editing your .hg/hgrc file to reference the new URL. CHANGE: I am dropping premake-main. At the time, I thought it would be easier to create a new repository "above" premake-dev and move the support files and modules up while keeping the core core where it was. Several weeks of working with this setup has changed my mind: it will be significantly easier to keep Premake-dev as the "top" repository and push things down from there. If you are using premake-main, you can simply drop it and go back to using Premake-dev (the "core" folder in that arrangement) instead. My apologies for the false start. Premake-dev will be getting some new sub-repositories, starting with the work-in-progress Xcode module (h/t neo2buha). This will be transparent: the sub-repositories will be included in your next pull and updated along with the core code. Let me know if you have any questions or comments—full speed ahead to 5.0! [Less]

As previously discussed in the previous Repository Reshuffling post: I am renaming premake-stable to premake-4.x, making the new URL https://bitbucket.org/premake/premake-4.x. If you have cloned this repository locally, you can repoint it by ... [More] editing your .hg/hgrc file to reference the new URL. CHANGE: I am dropping premake-main. At the time, I thought it would be easier to create a new repository "above" premake-dev and move the support files and modules up while keeping the core core where it was. Several weeks of working with this setup has changed my mind: it will be significantly easier to keep Premake-dev as the "top" repository and push things down from there. If you are using premake-main, you can simply drop it and go back to using Premake-dev (the "core" folder in that arrangement) instead. My apologies for the false start. Premake-dev will be getting some new sub-repositories, starting with the work-in-progress Xcode module (h/t neo2buha). This will be transparent: the sub-repositories will be included in your next pull and updated along with the core code. Let me know if you have any questions or comments—full speed ahead to 5.0! [Less]

For anyone interested, I've posted a Premake 5.0 Development Roadmap over on the wiki. Feel free to discuss it here. Contributions much appreciated!

For anyone interested, I've posted a Premake 5.0 Development Roadmap over on the wiki. Feel free to discuss it here. Contributions much appreciated!

Hey everyone, In preparation for moving Premake officially into a module-based development approach, I'm going to be making some changes to the source code repositories. The first big change is the addition of a new "meta-repository", premake-main ... [More] , to eventually supersede premake-dev. Those of you tracking premake-dev should try and switch over when you conveniently can. Right now, premake-main is just a shell which links premake-dev as a sub-repository. Eventually, the plan is to have something that looks more like this: premake-main/ core/ (sub-repo: premake-dev) modules/ xcode/ (sub-repo: premake-dev-xcode) d/ (sub-repo: premakeext/d) -- etc. etc. That is, a collection of sub-repositories, one for the core code, and then a bunch more for each of the officially supported modules. And from there we'll figure out how to integrate the modules into the official builds so we can continue to ship a single executable. Future source packages will mirror this file layout, so a single download will get you all the modules as well as the core code. At some point in the future, I'd like to rename the existing premake-stable repository to premake-4.x, and premake-dev to premake-core. And it would also make sense to bring the officially supported modules into the Premake team account on BitBucket. For folks tracking premake-main, all of these moves (except for premake-stable) will be transparent. Instead of separate repositories, I'd like to switch to stable and development branches within a single repository. Or rather, a 5.x branch across all the repositories, with feature branches used for in-progress work. I think a single issue tracker at the premake-main level is probably the way to go (read: people will log issues there regardless, so might as well go with the flow). Each module repository can maintain their own wiki though, and we can just link them together. I'm not in a big rush to rename things, so the existing repositories will be active for a while yet (and after the move, you will only have to update your default remote in .hg/hgrc to keep right on working). Feedback welcome as always. [Less]

Hey everyone, In preparation for moving Premake officially into a module-based development approach, I'm going to be making some changes to the source code repositories. The first big change is the addition of a new "meta-repository", premake-main ... [More] , to eventually supersede premake-dev. Those of you tracking premake-dev should try and switch over when you conveniently can. Right now, premake-main is just a shell which links premake-dev as a sub-repository. Eventually, the plan is to have something that looks more like this: premake-main/ core/ (sub-repo: premake-dev) modules/ xcode/ (sub-repo: premake-dev-xcode) d/ (sub-repo: premakeext/d) -- etc. etc. That is, a collection of sub-repositories, one for the core code, and then a bunch more for each of the officially supported modules. And from there we'll figure out how to integrate the modules into the official builds so we can continue to ship a single executable. Future source packages will mirror this file layout, so a single download will get you all the modules as well as the core code. At some point in the future, I'd like to rename the existing premake-stable repository to premake-4.x, and premake-dev to premake-core. And it would also make sense to bring the officially supported modules into the Premake team account on BitBucket. For folks tracking premake-main, all of these moves (except for premake-stable) will be transparent. Instead of separate repositories, I'd like to switch to stable and development branches within a single repository. Or rather, a 5.x branch across all the repositories, with feature branches used for in-progress work. I think a single issue tracker at the premake-main level is probably the way to go (read: people will log issues there regardless, so might as well go with the flow). Each module repository can maintain their own wiki though, and we can just link them together. I'm not in a big rush to rename things, so the existing repositories will be active for a while yet (and after the move, you will only have to update your default remote in .hg/hgrc to keep right on working). Feedback welcome as always. [Less]

Hat tip to Richard Geary for a new feature: an interactive REPL prompt, executing in the current Premake scripting environment. You can access the prompt one of two ways: by specifying the new --interactive command line flag, which opens the prompt ... [More] after executing your project scripts and "baking" them for the current environment… $ premake5 --interactive vs2012 …or by calling the new debug.prompt() function anywhere in your scripts. Script execution will stop at the point of the call, and you will be able to examine the current state of the environment. The prompt behaves just like the regular Lua REPL (and in fact runs the exact same code). Use ^C to exit, and prefix expressions with "=" to output the result. > =2+2 4 Thanks again to Richard for the contribution! [Less]

Hat tip to Richard Geary for a new feature: an interactive REPL prompt, executing in the current Premake scripting environment. You can access the prompt one of two ways: by specifying the new --interactive command line flag, which opens the prompt ... [More] after executing your project scripts and "baking" them for the current environment… $ premake5 --interactive vs2012 …or by calling the new debug.prompt() function anywhere in your scripts. Script execution will stop at the point of the call, and you will be able to examine the current state of the environment. The prompt behaves just like the regular Lua REPL (and in fact runs the exact same code). Use ^C to exit, and prefix expressions with "=" to output the result. > =2+2 4 Thanks again to Richard for the contribution! [Less]

Or rather, a new take on an existing feature. The configuration() function has now been superseded by filter(). Filters work just like configuration(), but require the use of a field prefix on all keywords. -- This... configuration { "Linux or ... [More] MacOSX", "SharedLib" }   -- Becomes... filter { "system:Linux or MacOSX", "kind:SharedLib" }   -- Configuration is the default so you can do either of these filter "configurations:Debug" filter "Debug" See the new docs for more examples and the list of valid prefixes. This new approach has two big advantages over the old one: it is more specific, so there is less chance of inadvertently applying settings to the wrong configuration/file (the latter has been a problem), and it is faster, since it knows exactly what to test. If you have a lot of configurations and files in your projects, you will see a significant speed-up. Oh, and it supports negations on file tests too, so you can do: filter "not **.cc" ...which wasn't possible before. The configuration() function is still in place, behaves just as it always has, will be included in Premake 5.0, and probably for some time after that. But it will eventually be deprecated, so you should start moving off it when you can. Comments, questions, and complaints are welcomed. [Less]

Or rather, a new take on an existing feature. The configuration() function has now been superseded by filter(). Filters work just like configuration(), but require the use of a field prefix on all keywords. -- This... configuration { "Linux or ... [More] MacOSX", "SharedLib" }   -- Becomes... filter { "system:Linux or MacOSX", "kind:SharedLib" }   -- Configuration is the default so you can do either of these filter "configurations:Debug" filter "Debug" See the new docs for more examples and the list of valid prefixes. This new approach has two big advantages over the old one: it is more specific, so there is less chance of inadvertently applying settings to the wrong configuration/file (the latter has been a problem), and it is faster, since it knows exactly what to test. If you have a lot of configurations and files in your projects, you will see a significant speed-up. Oh, and it supports negations on file tests too, so you can do: filter "not **.cc" ...which wasn't possible before. The configuration() function is still in place, behaves just as it always has, will be included in Premake 5.0, and probably for some time after that. But it will eventually be deprecated, so you should start moving off it when you can. Comments, questions, and complaints are welcomed. [Less]