CoApp may actually use MSI for packaging, but MSI doesn't have dependency management.
The purpose of CoApp is to make open source applications easily installable on Windows. I'm thinking similar to how you can install the GnuWin32 tools but more robust. So maybe a better description would be like Cygwin but more integrated into the Windows ecosystem.
What about the none open source apps? If microsoft is ever going to be relevant again, they have to make it worth developing software for Windows rather than webapps. Microsoft has some advantage, since their apis are much more powerful than html/css/javascript, but actually getting users to install your program, and dealing with all that crap makes it not worth it.
So right now I have msys + mingw + msysgit + emacs + console 2 on windows 7 and xp for development. It was difficult to set up and I'm happy that it is fully functional. I am actually a bit surprised that I got bash and emacs to a point where I'm happy. I can do what I need to do to deploy my application on windows with nsis. Or since the main part of the program is in python py2exe + nsis.
I can already get to the point where my application is an msi or exe or zip. What is CoApp going to add to the equation?
I just finished watching the presentation. I'm not an especially big proponent of open source... but this approach is so wrong. It ignores the solutions that exist and work in favor of new solutions that exclusively use Microsoft build tools and create more work for cross platform developers.
I must still be missing something because it looks like I'll have to maintain another configuration for coapp while still supporting gnu make (including mingwXX-make for other windows developers). Is there any reason that they are ignoring gnu tools? It's almost like they don't want to make the easy decision to just bring gnu to windows. You know... ./configure & make & make install. Windows users could just use bash.
The project style looks like classic Microsoft. I guess that bothers me because he claims independence. XML all over the place. New syntax and new ways of doing things that already work in * nix. A lot of magic and little explanation of the limits that will be placed on these builds.
I support a build system that works on windows. I just don't support some rigid new build system that kicks out pre-built microsoft binaries and requires me to maintain additional build configurations as a cross platform developer. Especially if that means I have to use a completely different development tool chain.
Ideally if I could maintain and update my *nix gnu tools and python using coapp I would use it. But I'm uncomfortable with a build system that isn't flexible. I've run into enough problems building on windows. I don't need another complication to add to the process.
15 comments
[ 3.2 ms ] story [ 41.1 ms ] threadNow if there were something like this for device drivers...
Of course, the fact that my Broadcom wireless NIC was supported out of the box was also nice.
The purpose of CoApp is to make open source applications easily installable on Windows. I'm thinking similar to how you can install the GnuWin32 tools but more robust. So maybe a better description would be like Cygwin but more integrated into the Windows ecosystem.
I can already get to the point where my application is an msi or exe or zip. What is CoApp going to add to the equation?
I must still be missing something because it looks like I'll have to maintain another configuration for coapp while still supporting gnu make (including mingwXX-make for other windows developers). Is there any reason that they are ignoring gnu tools? It's almost like they don't want to make the easy decision to just bring gnu to windows. You know... ./configure & make & make install. Windows users could just use bash.
The project style looks like classic Microsoft. I guess that bothers me because he claims independence. XML all over the place. New syntax and new ways of doing things that already work in * nix. A lot of magic and little explanation of the limits that will be placed on these builds.
I support a build system that works on windows. I just don't support some rigid new build system that kicks out pre-built microsoft binaries and requires me to maintain additional build configurations as a cross platform developer. Especially if that means I have to use a completely different development tool chain.
Ideally if I could maintain and update my *nix gnu tools and python using coapp I would use it. But I'm uncomfortable with a build system that isn't flexible. I've run into enough problems building on windows. I don't need another complication to add to the process.