Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
0.7
-
None
-
WinSDK build
Description
In the current WinSDK the \bin directory has become overloaded and difficult to use.
The directory currently holds:
- Boost (debug and release)
- Qpid libraries (debug and release)
- MSVC runtime (release)
- .NET Messaging Binding libraries (debug)
A user may:
1. To Compile/Run Debug
1a. C++ - Load the project and go
1b. .NET - Load the project and go.
2. To Compile/Run Release
2a. C++ - Load the project, flip the settings, and go
2b. .NET - Unpack the release libraries from zip, load the project, flip settings and references, and go
After building the examples the \bin directory has 78 files in it.
As a developer this isn't really that bad. But for a new user it gets harder to explain, particularly for the .NET examples. Between debug and release, C++ (.vcproj) projects have a simple way to specify differently-named libraries and differently named output files. .NET (.csproj) projects are not so simple: changing the names of a dependent library involve removing a reference and adding a references to the new file, and there is no great way at all to change the name of an output file.
Currently the bld-winsdk procedure produces two zip files, one each for x86 and x64 platforms. I propose to change the build to produce four zip files: x86-debug, x86-release, x64-debug, and x64-release. This has advantages and disadvantages:
Advantages:
- Each \bin directory is smaller and more easily understood
- The directory arrangement prevents a user from mixing libraries from incompatible (debug vs release) component builds.
- Customer's will have an easier time copying the kit's basic binary distribution as the debug and release parts are separate, and
- Customer will not have to unzip and manage debug and release versions of a files that share the same name.
- Kit consumers have already asked for this.
Disadvantages: - There will be extra copies of identical example source files and project setting files.
Implementing this will involve NO CHANGE to the qpid messaging library compile settings, minor changes to the .NET binding settings, and some moderate hacking in the bld-winsdk.ps1 script.