Premake

There has been some discussion on the mailing list about the direction for this new version of Premake; enough to even draw a few folks from the woodwork which is nice to see. Particularly, people seem to be concerned that I am focusing on syntax to ... [More] the exclusion of feature improvements and bug fixes. Let me set the record straight by listing what I’m really focusing on in this new version. The main driver for starting a new major version and breaking backward compatibility is the poor support for setting and tracking relative paths between project components. This support evolved over a long period of time, and I did not do as good a job of staying on top of it as I should have. I have not yet documented how the new system will work, but my goal is that all path references will be relative to the script that contains them. This is a major, breaking change from Premake 3. Since I’m breaking compatibility anyway, now is the time to revisit the script syntax. If I never have to type package.config[‘Debug’] again it will be too soon. I find the current syntax clumsy, excessively verbose, and error prone. I have documented my current thoughts on syntax. I rewriting the code from scratch (with some liberal cut-and-paste) in order to improve the readability and maintainability. This is already underway, and you can see the results in the development branch in Subversion. In particular, I am splitting things up into smaller parts with more formal and consistent interfaces. I am unit testing everything with UnitTest . There is much more internal documentation, and I am using Doxygen-style comments so folks can generate an API guide. I hope to make it easier to add new toolset and language support. I’m still working through exactly how to make this happen. I want to improve support for applying the same settings across multiple projects. My current approach is to use model projects. This should allow people to create a model project for a library that they plan to distribute to others, or for a third-party library. The model can then be easily reused, and any changes are automatically propagated throughout the solution. Speaking of solutions, I’ve noticed that several of the IDEs supported by Premake are moving toward the terms “solution” and “project”. There are couple of different names for the “solution” part, but pretty much everyone uses the term “project” to refer to what Premake calls a “package”. I want to adjust the Premake terminology to match: “solution” and “project”. I also plan to improve the documentation. I want to break of the current monolithic pages into smaller sections that are easier to read and navigate. Each configuration setting will have its own page. Finally, I am moving the website off of SourceForce, which has frequently experienced performance issues. I am also setting up more community-building features, such as the new forums. I may also experiment with community editing of the documentation. Feel free to voice your questions or concerns on the list or over on the forums. Your feedback is going to determine what the next version of Premake looks like. [Less]

I’ve created a branch in Subversion for the new version 4.0 development code. Find it at https://premake.svn.sourceforge.net/svnroot/premake/branches/premake4

Ever since I released Premake version 1.0 I have been adamant about keeping backward compatibility on a script level, and for the most part I’ve done a good job. But there have been some annoyances (and a few early bad decisions) that have finally ... [More] gotten the best of me and I’ve decided that it is time to make a break. And if I’m going to break compatibility, I might as well go all the way and fix everything. I will be using this website to document the new version. Eventually this will become the official site and the old one will be retired. Right now I am working on an improved project skeleton with better unit testing support. I’m using UnitTest this time, instead of NUnit, which should make it easier for code contributors to both run the existing tests and create new ones. I am also upgrading to the latest version of Lua and looking to improve the internal interface to make future updates easier to manage. While development is underway, check out the new documentation section where I will be laying out my ideas for this new version. I hope to document everything at least a week or two before it gets coded so people will have time to comment. Anything written in styled text (like this paragraph) is something that is still in the planning stage and has not yet reached the code. These are the features and ideas that are up for comment. [Less]