Well, it's been one of those weeks of running forward to keep standing still,
or something like that. Some notes on what I have been doing:
- Rather brusquely, I shoved all the KBE packages into a category KBE. Since I
don't know if there are rules governing SUNW_Category, this might be a
mistake, but it makes it much easier for me right now to yes | pkgrm -Y KBE.
- I fixed the missing mkdirs which would trip up kbe-install on a fresh system
which had no ~/packages/SOURCES or SPECS yet.
- We had a long chat about what to do with packaging; Lukas and I had been
working on pkgtool .spec files for dependencies using the original
third-party sources, while Stefan was working on a different set of source
trees. This led to duplication of effort and some confusion along the lines
of "<foo> does not work!" "i already fixed it last week" "where?". So we
decided to do the following:
- Work only in Stefan's source trees. These are in CVSDude.
- Roll tarballs and whatnot from those source trees.
- "Bless" a Solaris/ dir in each tree for administrative stuff.
- Put all the build machinery inside the sources themselves.
As an experiment, I then wrote a tool in perl that reads a kind of
minimalistic .spec file and spits out boilerplate %prep, %build, %install
and %clean sections based on the conventions for the contents of the Solaris/
directory. This tool seems to work fairly well, although it is finicky and
undocumented, and already three days old (the neighbours have a three day old
baby, and she is *much* better behaved than my code).
- The C++ compile flags have been considerably cleaned up. I intend to do the
same to the C flags, to normalize them and chop them into comprehensible bits
from their current 8-line monstrosity state. Getting the flags just right for
the general case is quite difficult: various configure scripts insist on
using C++ flags for the C compiler, or use various combinations of c99 and cc
for configure tests; the combination -z nodefaultlib -xlibmopt is hazardous;
deciding which flags go where (C, cpp, C++) can be tricky as well. Consider
the time.h installed by stdcxx: if you're a C program, you must *not* include
that one, and if you're a C++ program, you must *do* include it. So that's
a -I that goes in CXXFLAGS, not CPPFLAGS. As a consequence, configure won't
necessarily discover the C++-compatible time.h.
- What the exactly just right flags should be will be a topic for another IRC
meeting on friday at midnight CET on #kde-solaris.
- In the meantime Stefan is hunting a memory leak in QBezier and Joep is
hunting crashes in QMutex on SPARC, so we have got some low-level stuff to
sort out still. Thomas Zander wrote that there's at least one Solaris Troll
who would like to meet me; I think I'd want that too, as Qt + SS12 + stdcxx +
aggressive optimization is not as easy to get done as it might.
- I'm off somewhere in the bowels getting other dependencies to build. For C++
applications we would want to avoid the regular C++ headers (such as
<cstdio>) and use the stdcxx versions thereof, but that does mean that the
stdcxx versions have to be *right*. Such isn't the case now, as they are
missing little bits and pieces (va_list, fdopen, strdup, for instance, don't
end up in namespace std).
- KDE4 continues to build, albeit not with the cleanest selection of compile
flags nor the most stable binary underpinnings (all my previous screenshots
were of systems built with horribly mixed up headers, for instance).
- The FOSS packages end up in a category KCE; that is between KBE and KDE,
which is where they belong, but might not be a good category name in the long
run.
- As we get more bits of the dependencies working, more otherwise #ifdeffed
out KDE code gets compiled, which will lead to new issues. OpenLDAP stopped
the PIM compile, for instance. These will be resolved.
- From a short experiment just now, KDE4 runs better on Solaris than on
FreeBSD.
--
These are your friends - Adem
GPG: FEA2 A3FE Adriaan de Groot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
URL:
<http://mail.opensolaris.org/pipermail/kde-discuss/attachments/20080109/94325f36/attachment.bin>
