Hi, On Friday 21 August 2009, Ralf Habacker wrote: [...] > If you have more questions in this area let me know.
Just the sort of information I was looking for. Thanks! (Probably I will come back with questions, some time later). > The most annoying stuff are dependencies and binary incompatible > changes. Do binary incompatible changes still happen on windows? Are such changes expected for every minor release, for even for every patch-release? Are BIC changes announced on this list or elsewhere? > > Is there any documentation on this? > > over the last year several thread about the structure is documented at > the kde windows mailing list and there are the sources Ok, whenever I do get something to work (which will definitely take time), I'll try to document the basic steps on techbase. Or are these things still expected to change at a fast pace? [MinGW / MSVC] I'm not quite willing to give in on this, yet. > > - both versions are not co-installable > > not true > > > (or at least not in the same directory). > > yes Well, yes, but having two (or even more) separate KDE installations on one machine doesn't sound like a desirable thing to me. It may be ok to ask this from a developer (though it causes real space problems on the windows partition of my dual-boot laptop). But I just don't think this sort of issue helps create the "ready for the desktop"-impression. > the most important issue is > http://qt.nokia.com/developer/task-tracker/index_html?id=157932&method=entr >y -> Rejected: We don't find sufficient reason to implement this naming > scheme. I see. But would it be possible in theory to simply split the different versions into different sub-directories? Like C:\KDE\lib_mingw and C: \KDE\lib_msvc? (Similar to separate lib-directories on mixed 32bit/64bit systems)? That way 1) At least the data could be shared. 2) It would be possible to provide a stable least common denominator (such as MinGW4 / 32bit libraries are always installed) that third parties can rely on. MSVC and MinGW3 and/or 64bit libs/binaries would be an optional add-on. Failing that, the problem could be alleviated quite a bit, if it was at least possible to control all different flavors of KDE on one machine with a *single* instance of the installer. E.g. allow installation into a single root directory, but with subdirectories KDE_MinGW, KDE_MSVC, etc. for each installed flavor. In this approach, at least: 1) The installations would easily be kept in sync, and the only problem pushed to the end-user is the additional space-requirement, not the additional administration. 2) Again it would be possible to provide for a least common denominator for third parties to rely on, by always installing the KDE_MinGW4_32bit version, with any other versions as optional add-ons. Finally, failing that as well, I'll still insist and pose a more radical question: What really is the point of providing several binary flavors? I can basically see three answers to this: 1) To experiment with the different compilers, to profit from the different warnings they give, and further increase portability. A valid reason, but for this purpose it would not really be neccessary to off all compiler flavors in the binary installer. 2) To all developers to use both toolchains. Another valid reason, but once again this is useful for development machines, only. 3) To give third party appliation developers the freedom of choice to use either compiler flavor for distributing their software. That would be a nice idea, but the current approach does not really offer that choice at all, but rather makes providing *all* flavors as well the only clean option. So, I would argue: If "true" co-installability, i.e. especially management of different flavors in a single instance of the installer cannot be realized, then providing several flavors quite simply causes more harm than good. In this last case, a decision should be made to support *one* flavor in the installer. Developers in need of more would be expected to compile from sources. Well, that's my personal 2 cents. I'm sure most of my points have already been discussed at length, and it's not my intention to waste your time with perpetual repetition of the same discussion. But I do think this is an important issue, and perhaps I did bring up something that has not been considered, yet. Regards Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
