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.
Comments
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.