coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

So part of CoApp is the evolution of some seriously cool magic that I've been working on for the last couple of years.

Tools that can take absolutely any existing build process and turn it into Visual Studio project files. I've done this on about 100 projects already, and it's pretty damn cool

The nice part is, once we have real VC build files, we can leverage a lot of power out of the compiler.

I've spent literally years on this subject already, I'm not coming at it green--really. 

Besides, Canonical maintains shallow forks for everything that ends up in Ubuntu ... I'm sure we can do the same.

g

Garrett Serack | Open Source Software Developer | Microsoft Corporation 
I don't make the software you use; I make the software you use better on Windows.


-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Allison
Sent: Friday, April 09, 2010 9:21 AM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: [Coapp-developers] Conversion to/from UNIX-style build systems?

Hullo list, and in particular hello Mr. Serack!
This is a fantastic project idea, but I worry about the concept of maintaining "shallow forks", and having to maintain two build infrastructures for a project: one for UNIX (my personal choice being autotools), and one for the CoApp build environment.  It may simply be too early to expect good answers to this sort of question, but is the plan to somehow piggy-back off of existing build scripts, by - for example - scanning configure.ac, Makefile.am et al and producing at least a skeleton of CoApp build script?  This begs for some other questions, such as what *is* a CoApp build script anyway?  I assume it is a Visual Studio project file, but I've done very little professional development on the Windows side of the fence.
I'm under no illusion that such automatic generation would be simple, since the autotools are notoriously difficult to use "correctly" (with frequent differences of opinion regarding what constitutes correctness), but I also think it would be a mistake to expect developers to maintain multiple build systems; IMHO that is one of the biggest problems with porting as it currently stands.  "Shallow forking" presumably entails third parties - people other than the original project developers, perhaps analogous to package maintainers in the Linux world - creating and maintaining CoApp build scripts on a project's behalf, but it strikes me that such work is best done by people who really know the code they're trying to build, and that it goes beyond what I for one would consider the remit of a package maintainer.

I'm no expert, but I am currently working on a cross-platform project which makes heavy use of shared libraries and plugins, using the autotools (including libtool) to build using native tools on Linux and MinGW on Windows.  The configure.ac and assorted Makefile.am files are not easy to get right, and having to recreate their function from scratch for a different set of tools - then maintain both over time - would be somewhat daunting.

Looking forward to your answers, even if the surface can only be scratched at this stage. :)

Regards,
Phil

_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp