Closed dumblob closed 7 years ago
Well, I don't really know how to respond to that ;) I'm sure like many other tools Premake has its pros and cons. And ultimately it is up to you to decide what is the best tool for the best job...
That said, from my humble point of view... Premake is very easy to extent, modify and the community is very receptive of changes and merging Pull Request. So looking at the above 4 year old quote, if the person had contributed his extensive modifications, we could have all benefited from it, and maybe Premake would have been even more mature then it is today.
So, the comment is from 4 years ago, in that time a lot has happened. Blizzard Entertainment for example (where I currently work) decided to give it a shot, and we have heavily contributed to many areas of improvement. Other companies have done similar things. Starcraft 2 is a project of over 18000 files distributed over 163 projects (just looking in VS2015 right now). And Premake takes about 34 seconds to generate that solution. That isn't great, and we're certainly very interested in performance improvements, however it's also not bad enough that we are actively looking at that right now. It's one of those things where we're in "some day it would be nice" mode.
Mind you, premake scales almost linearly based on number of files * number of configurations * number of platforms
. SC2 has 4 configs, 2 platforms, and about 18000 files. Premake times go down significantly if we only generate the solution for 1 config, for which we added a command line option in our premake scripts.
If we miss a feature, such as LTO, we add it, make a pull request, get it reviewed, and merge it. Now everyone has LTO. Which seems a more responsible approach then complaining about it on Reddit.
Anyway, to respond to the specific issues:
filter { 'files:specificfile.cpp' }
buildcommands { "do something here" }
There is always room for improvements, suggestions are welcome.
Specific examples would have been nice, so these could have been fixed. That said, we do have some modifications here at Blizzard to the "getvpath" implementation which gave us a 4x performance improvement in cases where the vpaths API is used extensively.
These are generally just compiler options, so Premake always has the buildoptions and linkoptions API's to just send raw options to the compiler or linker. But the premake override API, allows you to inject code anywhere and everywhere, and so the ability to completely customize the build output is very powerful, adding LTO if Premake didn't already have it, would have been 5-6 lines of lua.
Thanks for taking the time, Tom. We should save your response for the next time that Reddit post comes up.
Marking as closed.
And just to add... I'm not sure what a "complex project" really entails in everyone's opinion. However in my opinion Starcraft 2 as well as Heroes of the Storm are reasonably 'complex', in that they are not pure C/C++ project, they are reasonably 'large', build across multiple platforms, and employ several languages and tools during the build process.
@tvandijck I've almost lost my breath. Thank you very much for a detailed answer! This answers my question and proves what I believed in already several years ago - Premake ecosystem is a really good choice.
And yes, I consider Starcraft 2 and Heroes of the Storm as definitely complex projects.
I didn't follow Premake development for some time and today stumbled upon the following comment on reddit:
I've found just the LTO issue solved. My question is how about the others?