Re: OpenBSD KDE4 Ports (was: Makefile format/best practices)
On Sat, Nov 06, 2010 at 05:27:04PM -0700, onteria wrote: As an update to the building of kde4 side by side with kde3, as well as getting it to run side by side, I've so far found the following: 1) Looking at FreeBSD, the kde4 problem is solved by installation of kde4 into /usr/local/kde4 No way, sorry but that's utterly gross. FreeBSD doing things like this is not a reason for it being a good idea. Besides, the existing kde4 we have in tree uses the correct layout. Packages will need to have WANTLIB updated for KDE4 libs, such as the following example with kde-base: WANTLIB += GL GLU ICE SM X11 Xau Xdmcp Xext Xft Xpm Xrender Xt \ cglib-2.0 kde4/lib/kde3support kde4/lib/kdecore.=8 \ kde4/lib/kdesu kde4/lib/kdeui \ Once you'll be at WANTLIB fixes, that means most of the work is done. In the meantime, don't really bother with it.. concentrate on runtime issue/crashes/linuxisms in code.. Please note that if we want to do divisions of directory structure such as: /usr/local/lib/kde4 /usr/local/include/kde4 /usr/local/bin/kde4 etc., that this could potentially add a large level of complexity to the process. Unlike Qt3/4 I don't think the build system easily allows that level of breaking down. It surely allows that. Landry
Re: OpenBSD KDE4 Ports (was: Makefile format/best practices)
As an update to the building of kde4 side by side with kde3, as well as
getting it to run side by side, I've so far found the following:
1) Looking at FreeBSD, the kde4 problem is solved by installation of
kde4 into /usr/local/kde4
2) I checked into how it could be done with OpenBSD and have come up
with the following:
/usr/ports/x11/kde4/Makefile.inc:
addition of the following:
CONFIGURE_ARGS += -DCMAKE_INSTALL_PREFIX:PATH=${LOCALBASE}/kde4/
This will allow kde4 to be installed into LOCALBASE/kde4, which is
/usr/local by default. The build and installation went okay after
dealing with some suid issues and rebuilding the plist.
Packages will need to have WANTLIB updated for KDE4 libs, such as the
following example with kde-base:
WANTLIB += GL GLU ICE SM X11 Xau Xdmcp Xext Xft Xpm Xrender Xt \
cglib-2.0 kde4/lib/kde3support kde4/lib/kdecore.=8 \
kde4/lib/kdesu kde4/lib/kdeui \
...
Just to make sure it's pulling kde4, I did a make configure with
kde-base:
-- Found KDE 4.4 include dir: /usr/local/kde4/include
-- Found KDE 4.4 library dir: /usr/local/kde4/lib
3) With regards to packages that can build against kde:
If there are any packages not in x11/kde4 that can be built with kde4
and kde3, my thought was to potentially use flavors. Does that seem like
a reasonable idea? For packages that depend on kde3 and can't be built
with kde4, no change would be necessary at the moment. If anything in
ports not in x11/kde4 can be built ONLY with kde4, they would need to
have WANTLIB updated with the new location format.
Please let me know if this seems like a reasonable solution and I will
start working towards implementing it in all the kde4 makefiles.
Please note that if we want to do divisions of directory structure such
as:
/usr/local/lib/kde4
/usr/local/include/kde4
/usr/local/bin/kde4
etc., that this could potentially add a large level of complexity to the
process. Unlike Qt3/4 I don't think the build system easily allows that
level of breaking down.
- Onteria
OpenBSD KDE4 Ports (was: Makefile format/best practices)
Pardon the breakoff, but continuation of the previous thread might have confused people who were looking for info on makefile creation issues. I've already gotten all the kde4 subdirs to build, and I currently have kdm running as I type this email. Unfortunately, many deps I added on the fly to get things to build, so the makefiles need to be updated so the packages will build on someone's machine who doesn't have the proper deps, or knowledge of which deps to add. With regards to the kde3 issue, I'm not sure I have an immediate answer to that. I'd have to check with how other distros do it, if they even do it at all. I personally would like to work on fixing the KDE4 issues before handling the side by side install issue. Just to name a few I've found so far: No, some other distros do allow that, and it's really the main issue we need to fix, and the kde people do provide some amount of documentation about it. Specifically, at least be able to build BOTH during a bulk build without collision. That's the big problem I haven't had time to look at yet. It might not be difficult to solve, or it might be difficult to solve, but it's really step 1. What you're doing is very simple, and very enjoyable. I've played that game, I can do it. But the very serious work needed to get kde4 uptospeed is to figure out the logic behind installing it correctly, so that we can activate the build. All right, I'll tread that path then. Let me look up their docs on how to best approach building both side by side. If I can't find anything there, I'll see how distros do it and figuring out how to best approach the issue while working inside the OpenBSD way of doing things. I'll post all my findings in an email so we can see if any of the approaches can be made to work, or if I need to search for another alternative. I can't promise I'll be able to do that today, but I'll have something at least by the end of the weekend (America/Pacific). Right now, what you're doing is noise, and it's not even sure it will be used, until we have fixed that major issue. All of my fixes to date are for making some of the kde4/* ports actually compile. Nothing has been fixed runtime wise. I'm not sure how they wouldn't be used, unless there is a better solution to fixing the compile issues that I'm not aware of. - Onteria
