coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

There isn't a place yet, because we haven't written the second generation tools, and the first generation stuff was all one-off.

We're still documenting the packages specifications, after which we'll move into building the tools.

I have a list of Package priorities that I'm interested in working on--by virtue of being important to the guys writing my paycheque:
http://coapp.org/Project_Planning/Package_Priorities

Other than that, once the tools are in place, anyone can begin the process of adding new packages.

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: Bill Hoffman [mailto:bill.hoffman@xxxxxxxxxxx] 
Sent: Tuesday, April 13, 2010 11:09 AM
To: Garrett Serack
Cc: Andrew Fenn; coapp-devel
Subject: Re: [Coapp-developers] How exactly will CoApp come together?

Garrett Serack wrote:

> />>What I am wondering is if you could save a lot of development time 
> by using cmake/
> 
> I can’t see how CMake **shortens** development time. It has other 
> benefits to be sure, but it’s not going to accelerate the rest of the 
> process.  The CMake scripts would still have to be created, and 
> hopefully generate project files to the same spec as I’ve been doing.
> Possible? Yes. Faster? I don’t think so.
> 
> 
> Don’t get me wrong, CMake has its benefits, it’s just not accelerating 
> the solution.  It’s more than likely that once the pieces are in 
> place, CMake will be able to be fully supported, but it’s not a 
> concrete requirement in the short run.
> 
So, I obviously would like to CMake play a big part in this.   It has 
quite a bit of development effort behind it, and is moving forward every day.  For CoApp, I think there are two things that should be done one long term and one short term.

1. Short term:
The Coapp project should support building a project that already has a 
CMake build system.   I would be willing/able to help Garrett integrate 
CMake projects into the CoApp process.  This seems like it would be a shorter path, as it would not require generating build files at all.

2. Longer term:
It would be interesting to modify the CoApp generation to script to automatically create CMake files instead of directly creating VS 9 or VS
10 projects.  A CMake project has a higher likelihood of being adopted in the upstream project than a VS 9 or 10 project, and what about VS 11 
when it comes out.   If the build files used for CoApp no long need to 
be shallow forked, then it is a win for both the project and CoApp.  I would also be willing/able to spend some resources on this effort.


Another group that might be willing to help is the KDE Windows team. 
They have been "cmakeing" many projects to support the KDE Windows effort.  I posted to that list and they have the following stuff converted to CMake already:

- - chm
 > - - cyrus-sasl
 > - - djvu
 > - - ebook-tools (libepub)
 > - - exiv
 > - - expat*
 > - - fontconfig
 > - - freetype
 > - - giflib*
 > - - jpeg7*
 > - - jasper
 > - - libbzip2*
 > - - libidn
 > - - liblzma
 > - - libxml2*
 > - - libxslt*
 > - - openslp
 > - - redland
 > - - shared-mime-info
 > - - sqlite*
 > - - win_iconv*
 > - - zlib*

Garret, is there a place in the wiki that lists all of the packages you 
have already converted?   It maybe that CMake files exist for many of 
these projects in one place or another already.   cmakeports is another 
place that has a few projects converted:

http://code.google.com/p/cmakeports/source/browse/#svn/trunk/ports


-Bill