Op 18 aug 2010, om 20:46 heeft Pedro Lopez-Cabanillas het volgende geschreven:
> For my cross platform VMPK (Virtual MIDI piano keyboard), I distribute an > universal .app bundle (intel+ppc,32bits) for Mac, including all required Qt4 > dependencies as private frameworks. It is a ~15Mb .zip package. > http://sourceforge.net/projects/vmpk/files/ > > KMid (www.kde.org/applications/multimedia/kmid/) is now a cross platform KDE > application. I've done my best to support Windows and Mac OSX. The users of > these operating systems may enjoy their native MIDI infrastructures and soft > synths. No other external dependencies are needed, only kdelibs. Op 18 aug 2010, om 17:30 heeft Mike McQuaid het volgende geschreven: > As an example of my method, here's how to make a Qt application that finds > and installs all it's own dependencies in CMake: > http://gitorious.org/charm/charm/blobs/master/Charm/CMakeLists.txt#line228 > > This lets "make package" build a droppable .app installer of this Qt > application on OSX. I could change one line and make it create .pkg > installers instead. The .dmg is 6.4MB and the installed .app is 20MB. This > somewhat destroys your claim that "bundling a Qt framework inside the .app > makes the .app grow by a few hundred MB". The situation with Qt is *completely* different from the situation with KDE. Qt is merely a library. A bunch of frameworks and you're done. KDE consists of much more than that, one of which is the daemons. I indeed checked the size of the Qt library including all headers and with full debugging, no stripping. Still, you have to agree that having the complete KDE application environment (usually not just kdelibs), installed as many times as you have applications, instead of just once, isn't good for the disk space, right? Op 18 aug 2010, om 17:47 heeft Benjamin Reed het volgende geschreven: > I'd rather work on making CPack Do The Right Thing for all of KDE out > of the box, which benefits other platforms as well. Op 18 aug 2010, om 20:56 heeft Mike McQuaid het volgende geschreven: > Yep, I agree that it's a shame. My work with CPack and KDELibs should be able > to help you here. If you work on improving building of self-sufficient KDE applications, that's wonderful work. It is probably possible, and maybe easier than I expect it to be. In the meantime, I will be brainstorming this KDE installer. Maybe only to fill a gap until you guys have figured out how to do it the most beautiful way, while circumventing the problem of the daemons and everything. Yes, a self-sufficient .app is beautiful. But in this case: why bother, it's not like the user will notice. Yes, interfacing with Fink may be hard. I find it to be a better investment of my time. Op 18 aug 2010, om 17:47 heeft Benjamin Reed het volgende geschreven: > I'm obviously a supporter of Fink, being one of the core maintainers > and all, but I think trying to package fink with a frontend would be a > nightmare. First, what do you do with people with existing Fink > installs? Upgrade their dependent binaries with new debs, > potentially? Make the KDE packages in somewhere other than /sw? These are all just trivial problems. The installer will use the existing Fink installation if it exists. It will use /sw like normal Fink packages. It will use a binary distribution with packages in Fink itself (I don't think 'my' packages will divert from Benjamin's packages, can't think of any patches that wouldn't make sense in Fink itself, or upstream). It will not divert from normal Fink procedures such as the -shlibs packages, so there will be no binary compatibility problems. I'll think this through before I'll really start working on it. This brainstorm has been hugely helpful, but we're just repeating arguments here. I would love it if you continue work on CPack and kdelibs improvements to one day get "real" Mac KDE applications; in the meantime, I will try to work on an installer that works with Fink in symbiosis. We'll tackle the same problem from two sides and maybe we'll meet again in the middle. Thank you for the discussion. :) Sjors
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
