Here is the CMake log from my first attempt to build KDE:
Quote:
----------------------------------------------------------------------------- -- The following external packages were located on your system. -- This installation will have the extra features provided by these packages. ----------------------------------------------------------------------------- * Perl - Needed for building kdelibs * ZLib - Support for gzip compressed files and data streams * Libintl - Support for multiple languages * BZip2 - Support for BZip2 compressed files and data streams * PCRE - Perl-compatible regular expressions in KJS * LibXML2 - Required by the KDE help system to process DocBook XML * shared-mime-info - Allows KDE applications to determine file types
----------------------------------------------------------------------------- -- The following OPTIONAL packages could NOT be located on your system. -- Consider installing them to enable more features from this software. ----------------------------------------------------------------------------- * OpenSSL <http://openssl.org> Support for secure network communications (SSL and TLS) STRONGLY RECOMMENDED: KDE uses OpenSSL for the bulk of secure communications, including secure web browsing via HTTPS * Soprano (2.5.60 or higher) <http://soprano.sourceforge.net> Support for the Nepomuk semantic desktop system * Soprano Raptor Parser <http://soprano.sourceforge.net> Support for the Nepomuk semantic desktop system * Soprano Redland Backend <http://soprano.sourceforge.net> Support for the Nepomuk semantic desktop system * Shared desktop ontologies (0.6.50 or higher) <http://oscaf.sourceforge.net> Support for the Nepomuk semantic desktop system * QCA2 (2.0.0 or higher) <http://delta.affinix.com/qca> Support for remote plasma widgets * LibACL <ftp://oss.sgi.com/projects/xfs/cmd_tars> Support for manipulating access control lists STRONGLY RECOMMENDED * LZMA/XZ <http://tukaani.org/xz/> Support for xz compressed files and data streams * FAM <http://oss.sgi.com/projects/fam> File alteration notification support via a separate service Provides file alteration notification facilities using a separate service. * Grantlee (0.1.0 or higher) <http://www.grantlee.org> ModelEventLogger code generation (part of the ProxyModel test suite) Grantlee is used for generating compilable code by the ModelEventLogger. Without Grantlee, the logger will do nothing. * HUPnP <http://www.herqq.org> UPnP support for Solid Allows Solid to provide information about UPnP devices on the network * UDev <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> UDev support for Solid Allows Solid to use UDev to provide information about devices on Linux * Flex <http://flex.sourceforge.net> Allows the Solid predicate parser to be updated Required by the UpdateSolidPredicateParser target (mainly useful for developers) * Bison <http://www.gnu.org/software/bison> Allows the Solid predicate parser to be updated Required by the UpdateSolidPredicateParser target (mainly useful for developers) * GSSAPI <http://web.mit.edu/kerberos/www> Allows KIO to make use of certain HTTP authentication services A MIT or HEIMDAL flavor of GSSAPI can be used * Aspell <http://aspell.net/> Spell checking support via Aspell This is not needed for spell checking if Enchant is provided or only Hebrew spell checking is required * HSpell <http://ivrix.org.il/projects/spell-checker/> Spell checking support for Hebrew Hebrew support can also be provided via Enchant, providing the correct Enchant backends are installed * Enchant <http://www.abisource.com/projects/enchant/> Spell checking support via Enchant * JasPer <http://www.ece.uvic.ca/~mdadams/jasper> Support for JPEG-2000 images * OpenEXR <http://www.openexr.com> Support for OpenEXR images * Avahi <http://avahi.org> Facilities for service discovery on a local network (DNSSD) Either Avahi or DNSSD is required for KDE applications to make use of multicast DNS/DNS-SD service discovery * DNSSD <http://avahi.org> Facilities for service discovery on a local network Either Avahi or DNSSD is required for KDE applications to make use of multicast DNS/DNS-SD service discovery
----------------------------------------------------------------------------- -- The following REQUIRED packages could NOT be located on your system. -- You must install these packages before continuing. ----------------------------------------------------------------------------- * Strigi (0.6.3 or higher) <http://strigi.sourceforge.net> Desktop indexing and search support Required by some critical kioslaves * libattica (0.1.90 or higher) <git clone git://anongit.kde.org/attica> Support for Get Hot New Stuff * DBusMenuQt <https://launchpad.net/libdbusmenu-qt> Support for notification area menus via the DBusMenu protocol * LibXSLT <http://xmlsoft.org/XSLT> Required by the KDE help system to process DocBook XML * xmllint <http://xmlsoft.org> Required by the KDE help system to process DocBook XML * DocBook XML <http://www.oasis-open.org/docbook/xml/4.2> Required by the KDE help system to process DocBook XML XML DTDs for DocBook 4.2 are needed * DocBook XSL <http://docbook.sourceforge.net/release/xsl/current/> Required by the KDE help system to process DocBook XML * libjpeg <http://www.ijg.org> JPEG image format support Required by khtml. * giflib <http://sourceforge.net/projects/giflib> GIF image format support Required by khtml. * libpng <http://www.libpng.org/pub/png> PNG image format support Required by khtml.
Of course we have SSL, libjpeg, libgif and libpng, but what about the others?? Is somebody interested in helping clearing up these dependencies? Or maybe someone has some of these lying around on their hds already?
I am only worrying about the REQUIRED for now. I think that is plenty.
By the way, I am trying to cross compile it, and one problem with the c++ compiler is, that it requires the -static option to actually work (or -use-dynld). Cannot this be fixed somehow? It is somewhat problematic for the configuration process. For building stuff it is ok, I have found a way to configure it, but it doesn't work with the TRY_COMPILE thingie in CMake. Help?
@alfkil I'm in love with Calligra and its underlying concepts! I would be more than happy if such an office suite will be available on OS4!!
I might sound a little bit boring to you, but when I mentioned the QT 4.8 platform abstraction layer, I did not only tried alerting you that using such a solution it might end up helping you while developing the native amiga rendering system.
I was also thinking about Calligra as it has a serious font rendering problem under QT4.7. I followed and used Calligra (thanks to the project neon on Ubuntu) since the koffice time and the switch to QT 4.8 gave to the overall text quality a massive bump.
To me it looks dangerous and a potential waste of time if you end up with a perfectly working QT 4.7 port but then you have to start from scratch for QT 4.8. I think we are all well aware of the time and effort you are putting into this port!
Actually I was hoping that I could wait until Qt5 to update my source base, but I guess I should look into 4.8 now... I haven't studied the Lighthouse thingy thoroughly, I hope it is not too dependent on OpenGL, which would mean again that we have to wait for mesa for it to really kick off.
@alfkil I do not want to discourage you, but from what I read QT 5 will be initially released next June and on its homepage they say
"...Qt 5.0 is a feature-driven release with time-to-market requirements especially for embedded environments. This implies that we should keep the scope of Qt 5.0 limited to the essential, and add more features and add-on modules in the upcoming minor releases..."
In my understanding this means that a feature rich version QT 5 will come not before a year or so.
QT 4.8 was released last December, so I think it is going to be mature enough as a source base for you, and your work will be of use for at least 2 (or maybe 3) years from now, and softwares such as Calligra will work happily on it.
As you are quite into QT now (well, judging from the quality of your releases which simply works) it could be time to start on 4.8 using your 4.7 knowledge.
Of course, as you said, if you meet strong dependancies from OpenGL, you can simply drop 4.8 and continue on QT 4.7. Just I'm asking you to have a look at it, before (maybe) wasting too much of your spare time.
Having got distracted trying to update lzma.library to liblzma 5.0.3, and giving up due to the incredibly annoying USB mouse problem (I've had to power off completely twice, and re-plug USB at least twenty times in the last half an hour or so, I can't believe none of the beta testers are jumping up and down about this issue; but I digress), I just realised you don't actually need the complete build tree to build the stub.
Never mind, I've created it now anyway. You'll need lzma.library also.
"-- Looking for lzma_auto_decoder in /SDK/local/newlib/lib/liblzma.so -- Looking for lzma_auto_decoder in /SDK/local/newlib/lib/liblzma.so - not found -- Looking for lzma_easy_encoder in /SDK/local/newlib/lib/liblzma.so -- Looking for lzma_easy_encoder in /SDK/local/newlib/lib/liblzma.so - not found -- Looking for lzma_lzma_preset in /SDK/local/newlib/lib/liblzma.so -- Looking for lzma_lzma_preset in /SDK/local/newlib/lib/liblzma.so - not found -- Could NOT find LIBLZMA (missing: LIBLZMA_HAS_AUTO_DECODER LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) "
"-- Looking for lzma_auto_decoder in /SDK/local/newlib/lib/liblzma.so -- Looking for lzma_auto_decoder in /SDK/local/newlib/lib/liblzma.so - not found -- Looking for lzma_easy_encoder in /SDK/local/newlib/lib/liblzma.so -- Looking for lzma_easy_encoder in /SDK/local/newlib/lib/liblzma.so - not found -- Looking for lzma_lzma_preset in /SDK/local/newlib/lib/liblzma.so -- Looking for lzma_lzma_preset in /SDK/local/newlib/lib/liblzma.so - not found -- Could NOT find LIBLZMA (missing: LIBLZMA_HAS_AUTO_DECODER LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) "