Greetings,

I'm trying to set up KDE for windows so I can both use and hack a little.
Specifically I'm interested in spending some time with Umbrello.

I followed the instructions at http://techbase.kde.org/Getting_Started ... ows/emerge and have what appears to be a mostly working setup. Things like emerge --help work very well.

Initially I ran into some things that appear to be dependency issues. I'm running a x64 system FWIW. My first issue was that 7za was not found according to the build logs. I explicitly emerged 7zip and that was solved. Next I had some problems with expat. It appeared that something got confused
and installed a 32 bit expat and the linker choked trying to build dbus-daemon. A little fussing and that problem was fixed. I never actually ran either of these problems to ground so I can't say exactly what was happening but I thought I would mention them for the record.

The next issue involved vlc. It seems emerge failed trying to download the file because vlc-1.1.11.py references a directory that no longer exists. Looks like maybe vlc changed some things around and broke the portage stuff. This looks like a legit problem to me.

My next issue is a failure during emerge kde-baseapps. The kdesupport -strigi build log indicate a problem linking libstreams.dll. The problem is the bzip2 library. I have an existing installation of Ghostgum stuff and the linker is trying to pick up libbz2.dll (32 bit lib) from there rather than using the libbzip2.dll.a installed under %KDEROOT%

I know I can clean up my path or set the Ghostgum file aside to get past this but I would a better solution. I can't permanently remove Ghostgum and tweaking the path seem inelegant. I'm not familiar with either emerge/portage or cmake but I have been developing software since punch cards. For starters, how can I see the actual command passed to the linker? All I see now is some eye candy "Linking CXX shared library libstreams.dll" Over in the build directory I found LibStreamsConfig.cmake and it looks like it wants to search "r.\\lib" but since I haven't figured out how to see the actual command I don't know what the compiler/linker is seeing.

Any ideas?
Thanks

On Linux at least, running "VERBOSE=1 make" causes the full output to be made. You should still be able to do this with emerge I guess.

Yes VERBOSE=1 seems to help but it doesn't seem to completely always work. I spent the afternoon on this and I found that you can use VERBOSE=1 or add -v to emerge to make emerge more verbose and apparently pass VERBOSE=1 on the the make system which does help some.

I also hiked along the steep learning curve of emerge and cmake and found the build directory in question so I can manually operate cmake or gmake up close and personal. I feel a little better.

As for loading the bzip2 library it looks like the fault lies with the algorithm used by cmake. In the FindBZip2.cmake module the names are bz2 bzip2 and bzip2d (in that order) The current algorithm searches for bz2 in all the searchable directories and then searches for bzip2 in all directories, etc... The file in the local KDE build tree is bzip2.dll.a in the KDEROOT/lib directory. There is a libbz2.dll.a in the Ghostgum tree which gets picked up first. The cmake team is aware of this and there may be a fix in the queue. Several short options occur: copy bzip2.dll.a ->bz2.dll.a in the local tree, fix the local copy of FindBZip2, or even path cmake to "do the right thing" which is apparently to search each directory for any named file then move on as opposed to search all directories for the first file then move on. IOW the search should be prioritized by path vs name of the library. The status quo makes it difficult to have a standalone and self contained development tree, or to quot Yoda "Fragile are we".

Off to more puzzles

Try setting the environment variable "CMAKE_PREFIX_PATH" to the location where your KDE/libbz2 installation is.
Make sure to remove the build directory afterward - as CMake remembers these values.

I tried that but it didn't help. I found a thread here:
http://www.cmake.org/pipermail/cmake/20 ... 36947.html that helps understand the issue. I didn't dig deep enough to find why the prefix doesn't seem to fix the problem but apparently the path searched by cmake is pretty extensive; it seems to try really hard. The end result is that if you have a library bz2 nearly anywhere on the machine it will take precedence over a file named bzip2 even in a preferred location. In a linux world the easiest thing would be a link but I'm not real clear about doing such things on windows.

From the thread I found it seems I'm not alone in considering the current behavior as surprising. Seems like cmake should either clearly document the current behavior or change the behavior and document the new behavior.

At any rate, understanding the problem allows many possible ways forward and I'm not stuck at the same place. Right now kde-baseapps won't properly build because it wants kdelibs 4.7.97 while the version that emerged is 4.7.4. I tried to update kdelibs but no joy.

Hmm.... CMAKE_PREFIX_PATH, if set to be exported (not sure if this is needed under Windows) and then followed up by running Emerge with a clean build directory should result in CMAKE_PREFIX_PATH being searched first.

You may wish to send a email to kde-buildsystem@kde.org - they should be able to help.

It does search CMAKE_PREFIX_PATH first (at least I think it does) but it searches for bz2. Then it goes on and searches all other directories for bz2. If that search fails it starts over searching CMAKE_PREFIX_PATH for bzip2 and then moves on to the other directories. (for the record you don't export under cmd.exe on windows)

Given
name1, name2, name3

and
dir1, dir2, dir3

It searches for name1 in dir1, dir2, dir3 then searches for name2 in dir1,dir2 and dir3 and so on.

The order of names in the FindBZip2.cmake is (bz2 bzip2 bzip2d) and the bzip library in the Ghostgum tree is libbz2.dll.a while the KDEROOT tree holds bzip2.dll.a so the wrong one is found.

Based on the thread I found and my own experience it seems that behavior is surprising. Most seem to assume the search would find any of (bz2 bzip2 bzip2d) in the preferred directory CMAKE_PREFIX_PATH before searching other directories. I haven't checked, but the cmake developer mentioned a patch to change the behavior. The thread I mentioned included the cmake code so the problem and fix were relatively easy.

The surprising version has two loops; the outer loop looks at names while the inner loop looks at directories. The fix is the switch the inner and outer loops so the outer looks at directories and the inner looks for names.

As a work around I copied bzip2.dll.a to libbz2.dll.a and with a clean build directory (to remove the cache) everything went smooth; the correct library was found and the whole emerge process proceeded to a success.

I seem to have a working base system at this point but I still haven't managed to emerge Umbrello yet.

What error is holding up the Emerge of Umbrello?

From the log:

v:\trunk\KDE\kdesdk\umbrello\umbrello\/version.h:14:22: error: revision.h: No such file or directory
In file included from v:\trunk\KDE\kdesdk\umbrello\umbrello\main.cpp:14:
v:\trunk\KDE\kdesdk\umbrello\umbrello\/version.h: In function 'QByteArray umbrelloVersion()':
v:\trunk\KDE\kdesdk\umbrello\umbrello\/version.h:24: error: 'REVISION' was not declared in this scope

I confirmed there is no file revision.h in the local repo.

FWIW I'm emerging the KDE-4.7 branch on a windows machine. My initial
attempts to emerge head seemed to be troublesome so I chose to work on
a stable branch with the idea that it might be a little more - well
"stable". I've been around long enough to know that breaking a build
on head is bad form, but it still happens. Since I'm unfamiliar with
the emerge/cmake systems I decided a stable branch would likely have
fewer changes likely to break a build and hence would minimize the
incline of the learning curve. My plan was to get a stable branch
working and then tackle head. So far it hasn't been too bad. The
issues have all been tracked down.

At my present point I guess my next step is to go digging around in
an online repo and see if it matches what I have locally. My spider
sense from being in this position many times tells me that there are
two very real possibilities:

1. The 4.7 build really is broke.
2. I did something wrong getting to this point.

Experience tells me #2 is more likely, so I'd like to figure out if
the problem is pilot error or broken build.

After a little digging, it looks like a possible portage problem.
As I noted above my emerge/portage tree is a KDE-4.7 branch. I looked
at the portage tree in umbrello-20090807.py to find the location of the
repository. From this:

self.svnTargets['svnHEAD'] = "trunk/KDE/kdesdk#norecursive;trunk/KDE/kdesdk/umbrello;trunk/KDE/kdesdk/cmake"

It looks like I'm fetching umbrello from trunk versus the KDE-4.7 branch.

I also went back to my buildlogs and found something I missed the first time.
The umbrello log says it couldn't find svn.exe. That makes sense because dev-util/svn/bin isn't on the path. There is a svn.bat in dev-util/bin which
I'm guessing is how svn is working in spite of the log error but why not just put util-dev/svn/bin on path?

FWIW the umbrello-soc (Summer of code?) does emerge and build, but crashes
instantly. I haven't put any energy into that yet as I hope that a stable branch line will be easier than a relatively high change branch that hasn't been merged yet.

After pointing the portage to the umbrello in the branch it emerged, built, and seems to work (at least it opens and closes a file without blowing up).
The branch repo is missing the application icon but that's a small thing. I suppose now I should spend some quality time setting up a reasonable work environment. I'm normally a command line and emacs kinda guy but given the windows environment and the possibility of cygwin clashes I'll probably try kdevelop.

This forum is a general discussion place as opposed to a developer list correct? Is there a place for development discussions? I didn't keep a journal through this process but I should probably pass on what I found. Now that I think of it, I don't know how development is organized. Are there separate teams for emerge, kde, and umbrello and how about the windows port?

Development related discussions will likely elicit a greater response on the KDE Windows mailing list - if KDE on Windows specific - or on KDE Devel - if just KDE specific.

kde-windows@kde.org
kde-devel@kde.org

Thanks, I was already in the process of browsing through both the KDE and KDE on windows mailing lists.