I noticed that the new MSBuild multi-targetting feature for 2010 wasn't supported yet and figured I'd add it to get my feet wet in premake (and because I need it).
Before I started work on it I wanted to make sure the approach I was thinking of makes sense to others more familiar with the project before I just went for it.
Essentially what I was thinking of was to have a special user-defined script that would define which toolsets are available on a per-platform basis, which would be either placed in the scripts (--scripts) directory or directly specified from the command line via --toolsets="path to script". The reason for using a user-defined script rather than having premake determine which toolsets are available is that the toolsets are so highly dependent on which platforms/versions the developer is using that it wouldn't make sense to make them 'global'. This would essentially just be a simple script containing something along the lines of
toolsets()
toolset( "x32", { "v90", "v100", "Windows7.1SDK" } )
toolset( "xbox360", { "v90", "2010-01" } )
toolset( "ps3", { "SNC", "SPU", "GCC" } )
where each platform (that is being built in VS) would give a list of the toolsets that it can build for, which would be used to validate the toolset specified in any solution/project/configuration.
While I could do code to automatically generate this based upon the toolsets that are installed, this would of course mean that projects could only be generated on a machine with the proper toolsets, and since toolsets are going to change relatively infrequently it seemed like that would be mostly wasted effort.
Questions/comments?
Share
We're really going to need both: the most common tools defined globally, with a way to add new toolsets locally. Assuming that the most common tools are built-in, I don't think an external script is needed. If a project wants to support a new tool, it can just dofile() in the script it needs to support it.
The scripts directory (--scripts) is used to locate Premake's sources during debugging. So this isn't an appropriate use of it.
Really, the interesting part is what happens after this: how to tie toolsets, platform, and architecture information to the build configurations, in a reasonably compatible way?
>Really, the interesting part is what happens after this: how to tie toolsets, platform, and architecture information to the build configurations, in a reasonably compatible way?
For any incompatible changes you can borrow a solution from CMake: every time CMake developers want to change behavior, they add new "CMake Policy", and then if CMake user wants to use new features he explicitly turns it on in the project and deals with all of incompatibilities it brings, while unchanged projects remain working.
OK, so provide support for the common ones out of the box does make sense, I was just concerned with a new toolset coming out and premake support for it lagging behind, but I suppose if users can add new toolsets in an easy enough manner that isn't really an issue.
I'm not sure what you mean about tying them together, maybe this is naive, but I thought it would just be something like...
configuration "x32"
toolset "v90"
configuration "ps3"
-- Uses 'SNC' or whichever configuration is set as the default
toolset "default"
configuration "xbox360"
toolset "Windows7.1SDK"
-- error, platform 'xbox360' does not support a toolset named 'Windows7.1SDK'
since each toolset is platform specific.