Howdy,
/(1) Windows Installer / MSI
Does anybody outside of Microsoft really *like* MSI? Wouldn’t a package
format based on ZIP archives be a better cultural fit for open source
software? I know MSI is the supported method for installing SxS
assemblies. For the sake of discussion, let’s assume that isn’t an issue.
What other advantages do you see in MSI? Are those advantages worth it?
/
MSI is just more that the supported method for installing assemblies. MSI
provides us with a whole host of features that are built in to the OS that
we can’t get without a lot of extra (and completely needless) effort--- MSI
has a whole host of features that we can build on top of—not attempt to
replicate. I’m not going to sit and list every one, but the more significant:
- MSI files are recognized as installers by the OS already. Any other type
of file would require us to have software on the system *before* the first
package is installed. MSI provides us a method to transparently bootstrap
that process and requires no prior knowledge on the part of the user.
- MSI files provide transactional support around the installation of a
package. Something goes wrong? Roll ‘em back.
- a lot of enterprise management (Group Policy, etc) of software works
around MSI files—a critical feature in rolling out software on thousands of
desktops.
- MSI is pretty easy to work with, and supports an extensible model for
package metadata already. Why replicate?
- MSI files are easily digitally signed, and again, the operating system
knows what to do with that.
- In spite of people’s incorrect opinion on the triviality of manipulating
MSI files, they are actually pretty simple to pull data from, extract files
and validate the contents.
- zip files, on the other hand, are simply a container that while also
fairly trivial to manipulate, really offers absolutely nothing required for
package management and would mean we’d have to code up a bunch of needless
conventions.
/ (2) Shallow forks vs. upstream support
I understand that shallow forks are needed to get started, but I hope the
ultimate goal is getting CoApp adopted by as many upstream packages as
possible. I have a dream that some day, I'll be able to grab the latest
code for random open source projects and build them on Windows as easily as
on Unix.
///
Upstream support would be preferable, but even Ubuntu shallow forks pretty
much everything. While the ideal world would have upstream projects
shoulder the burden of maintaining Windows builds, it’s not very realistic.
/(3) CMake
Have you looked at CMake (http://www.cmake.org <http://www.cmake.org/>)?
There are several cross-platform build systems out there, and none has
emerged as a clear standard. However, my observation is that CMake has
gained the greatest acceptance. Could CoApp leverage CMake?
///
Yes, I’m more than well acquainted with CMake. Unfortunately, it doesn’t
solve any of the hard problems we’re tackling, it simply offers an
alternative target for creating build scripts. Sure, CMake generates VC
project files in the end anyway, but it’s not making things any easier, and
for our purposes, offers little other than an extra indirection (with the
possibility of incomplete functionality at build time) without accelerating
our activities in the short run.
G
