Feedback from an application developer

[Thomas Friedrichsmeier]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20090822/bf54ae8f/attachment.sig