On Tuesday 05 July 2011 20:16:54 Joachim Langenbach wrote: > Ok, but the actual one supported doesn't allow easy builds on windows. The qconf support for windows has gotten better in recent times (the docs are dated though). Checking for support on the delta mailing list may be useful.
> So I > decided to take the cmake script which they provide (more or less nothing) > and extend it (I know KDE has also one, but KDE does not have the newest > version in repository and has another structure of the sources related to > qca and the plugins). I'm not following you here. Can you explain further? > Yes, I've worried that they do not really want to support cmake. The background to the cmake support is that it was added to kdesupport, and QCA was part of that, so it was an easy way for KDE developers to build QCA. > But > compiling it on windows is a big horror and I've seen, that nearly any > linux distribution applies many patches to their sources. Many? I had a quick look at Debian (which is usually the worst, and there is only a few (mostly for more recent OpenSSL versions). Do you have links for these patches. > So tonight I > thought, it might be easier to create a new repository, import their > sources, apply the patches, used by every distribution and merge the > changes from the original source back into the new repository if they > appear from time to time. This may be much more efficient than create > patches independent at every distribution. Also windows and mac users (and > kde) doesn't profit from the process right now. Sounds like it should be done in the repo. Why not? > During the compile and linking process I get many errors and it is really > difficult to get the overview, if all appears at the same file. So a more > structured source, should made the debugging during the compile run much > more easy. Also create patches should be easier, since it is easier to > understand the logic behind the source code. I think it would be harder, more duplicated headers etc. The whole structure of QCA is simple: its a Bridge. Each plugin has factory that creates objects of the right kind. There are a lot of capabilities in the ossl plugin so its long, but the hard part of that plugin in the hideous OpenSSL API that it uses. I think this is a bad idea to do this kind of change- too much code churn which could break things, not enough unit test coverage, and not enough benefit to justify the work. Brad >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
