What's the moral difference between using a preprocessor extension, and extending the preprocessor?
RFC Review Question
What's the moral difference between using a preprocessor extension, and extending the preprocessor?
WiX Engineering Principles
Well not a moral difference but a difference in engineering principles and trade-offs.
Root Assertion:
Experience shows there are many, many different ways people build and many more to the way they release.
Systems Engineering Analysis:
Building in every build and release system paradigm is problematic engineering exercise as a tool set ages. Over time, each new feature added to the tool set would have to consider instances of build and release systems they do not understand or even philosophically disagree with. WiX itself does not choose to favor a particular build or release system but aspires to provides sockets (called extensions) for each build and release system to link itself with the WiX tool set. The stability of the core from this approach is substantial as the core can perform feature work and maintain its accounting for build and release systems to just the APIs of the extension points.
Dependency Analysis
On the dependency front, this extension model does push two things:
- WiX needs to provide sufficient flexibility to alter the system via extensions
- The burden of evaluating compatibility of a new release is now owned by the folks with the extensions rather than the folks writing the new features in the core.
The latter one is most important because…
Time/Value Analysis:
WiX’s Core Team of Devs is all volunteers. That means that toolset must have a high degree of personal value derived for the time spent because no one is getting paid for these tools. Folks that take dependencies on these tools are more than likely getting paid than the volunteers to solve the problems that WiX is great at solving. That taking a new WiX drop has costs for those getting paid to manage the problem is much more viable in the long term. Put another way, if for every feature in the WiX toolset, one had to run hours or even days of regression testing against a forest of build and release paradigms, the volunteers would abandon the toolset for lack of personal value returned.
Some Other Examples:
The following references real teams and people but I have altered their names as they prefer to remain anonymous
Large Product Unit 6 (LPU6) is currently in the process of shifting their process to WiX. They looked at the Large Product Unit 4 (LPU4) build and release system (already using WiX), compared it to their build and release systems and determined they were incompatible. With this recognition in hand, they evaluated the fitness of a preprocessor extension vs a binder extension vs a wixout post-processor. LPU6 chose a wixout postprocessor model rather than LPU4 preprocessor extension model. The Small Product Unit 2 (SPU2) and Large Product Unit 3 (LPU3) also have different build and release processes thus different solutions for integration. As Small Product Unit 1 (SPU1) indicated earlier, he had a different tweak again to the source files to accommodate his build and release system.
Toolset is Flexible to Extension Requests
When LPU6 choose the wixout postprocessor model, they had some needs of the wixout files that were not provided within the existing wixout. Costello, a LPU6 developer, has been consulting with the wix volunteers on the right way to extend the toolset to provide that little bit extra to solve LPU6’s needs. Costello has then gone off to work on that feature and has submitted the changes to the WiX team for collaborative review and improvement. Through efforts such as this, the tool set grows and folks various needs are serviced.
Contributions Welcome
LPU4 opted not to provide back the code for their preprocessor extension solution to integrate into their build and release process but that doesn’t mean you couldn’t. Someone else built up the compiler extension functionality, I then built a help compiler extension contributed it back after which Bo then improved it to make it more useful for LPU4 too. The preprocessor was actually contributed by Small Product Unit 5, I added the preprocessor extension framework, and then Bo improved the framework to make it more useful for LPU4. The framework for decompiler extensions were also added (by Reid I believe) with the expectation that some day someone may want to roundtrip non-standard tables out of MSIs and into wxs files.
Back to your RFC. There appears to be a lot of thinking to get this RFC to this point. SPU1 has expressed interest. It does seem clear to me that building an extension to provide this functionality appears to be interesting for you (and maybe SPU1) to pursue for the value it provides you. After or during implementation you can share your work and get collaborative feedback on the work. Heck, someone may even sign-up and pitch in when they recognize through the dialog that they need the same problem solved too.
Well, at least, that’s the way I’ve come to understand the spirit behind WiX,