Create design spec. for configurations and evaluate possible impact on the settings
infrastructure. This needs to be done soon to ensure that it will be possible to extend the
settings infrastructure in a compatible way to support configurations or to include the
configurations in the contract (api, format of project file, ..)
Dirk's comment: Finalize the relationship between targets and configurations. Are configurations the
only way to change settings for different targets?
Two use cases which should be supported (probably) by configurations:
1.) user has project and want to build it against different
versions of the same library for different platforms, eg. solaris6.lib
for Solaris 6 platform, solaris7.lib, solaris8.lib, solaris9.lib, etc.
Should different configurations be used for this project and how? (is
it something similar to java platform?)
2.) build dependency is defined as [project, configuration, target].
What to do if project referenced by build dependency is in different
configuration when the build is running? Should the project
configurations be switched during the build? Other use case is that
user want to build project in all configurations. How it will work?
not completed for M2, reassigning to M3, also reassigning to Vita
Must-have features for milestone3, have impact on APIs (at least potential).
reassinging to Tor
I think it's done now.