cmakifying packages

[Ralf Habacker]

Bernhard Reiter schrieb:
> Am Dienstag, 13. April 2010 11:38:09 schrieb Ralf Habacker:
>   
>> Patrick Spendrin schrieb:
>> <snip>
>>
>>     
>>>> There will be some overlap with KDE windows, and a real package manager
>>>> supported by MS, would be great for all of us.   If it could leverage as
>>>> much CMake as possible that would be even better.   What is the current
>>>> list of "cmakeified" third party stuff that is done for KDE windows?
>>>>         
>>> - - 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*
>>>
>>> Not all of them are up to date, some more might be added in the near
>>> future (* means recent additions).
>>>       
>> Do you know how many packages are using a non cmake build system and
>> which ? This is important to estimate how much work is still required to
>> migrate the remaining.
>>     
>
>   
Sorry if this has been interpreted as a pro - I only tried to give a 
hint where the problems could be  and that KDE on windows probably have 
to support more than one build system (think about qt - or do they 
switch to cmake too in short) Because mostly packages used by KDE came 
from unix, autotools has to be provided too.
> Note that some initatives will be unhappy if you "fork" their product
> by adding another build system to it.  [1] 
> I know this is the case for many components of the GnuPG crypto family, e.g. gpgme, gnupg and dirmngr.
> I guess there will be others as well. My recommendation is to coordinate 
> cmakification first with upstream.
>