Rant: So you want help?

Patrick Spendrin ps_ml at gmx.de
Fri Nov 5 16:15:40 CET 2010

Am 05.11.2010 16:01, schrieb Alf Gaida:
> Am Freitag 05 November 2010, 15:13:38 schrieb Cristian Oneţ:
>> On Fri, Nov 5, 2010 at 3:44 PM, Gilles Caulier <caulier.gilles at gmail.com> 
> wrote:
>>> 2010/11/5 Thomas Friedrichsmeier <thomas.friedrichsmeier at ruhr-uni-
> bochum.de>:
>>>> Hi,
>>>> On Thursday 04 November 2010, Patrick Spendrin wrote:
>>>>> KDE on Windows building/packaging works this way:
>>>> ok, let's focus on creating a 4.5.x release. So far, it seems to me the
>>>> greatest obstacles are:
>>>> 1) Only few people really know what precisely needs to be done to create
>>>> a release. Your sketch certainly helps understanding some of the major
>>>> steps. But still, I for one simply wouldn't know where to start. So I'm
>>>> hoping for very specifc instructions. Naturally, there will be problems
>>>> of all sorts on the way, and you can hardly anticipate and document all
>>>> of that. But in an ideal world, what would be the sequence of commands
>>>> needed to create a release?
>>>> 2) Creating a release is a daunting task, and it's hard to split up into
>>>> more managable portions. Let's break this one up some more, into mostly
>>>> independent problems:
>>>> 2a) Packaging dependencies: Alright, I can see the pain involved. But
>>>> are missing dependencies really still an issue for a 4.5.x release? If
>>>> so, do you have a list (complete or not) of which ones in particular? I
>>>> guess it should be possible to split up at least this point among
>>>> several people, easily.
>>> From digiKam viewpoint, the next 2.0.0 release will require OpenCV
>>> library for face detection stuff.
>>> On my Win7, it compile fine with TDM-GCC and MSVC2008. It's a libary
>>> managed by Cmake. So it's easy to include as windows installer package
>>>> 2b) I keep stumbling across the "multitude of compilers" issue. If
>>>> ressources are this limited, then trying to package for several
>>>> compilers at once looks totally counter-productive to me at this point
>>>> of time. I've stated before that I'm all for dropping everything except
>>>> MinGW4-32bit from the installer, but I guess this idea won't be
>>>> accepted (I'd still appreciate any direct feedback, though).
>>> From a developer viewpoint, to have at least Mingw4-32 + MSVC is very
>>> instructive. Some warnings/errors can be see with GCC, some others
>>> with M$ compiler. both are complementary.
>>> I never run digiKam & co using MSVC bin, for a simple reason : it
>>> crash at start up due a binary uncompatibility between KDE4 packages
>>> compiled with MSVC 2006 and digiKam compiled with MSVC2008
>>> I always use GCC. All compile and run fine.
>>> From an user viewpoint it's a very confuse situation. Why 2 compiler
>>> packages version exist... Only one is enough.
>> +1
>> So the compiler choice could be hidden from the normal user but it
>> should stay the way it is now from a developer's POV. Having different
>> compilers go trough the code is really good thing.
>> Regards,
>> Cristian Onet
>> _______________________________________________
>> Kde-windows mailing list
>> Kde-windows at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-windows
> IMHO the goal has to be one compiler. I know that the linux world is not ideal 
> but there is one compiler. Why split in ming and several flavours of MSVC like 
> Gilles wrote. More compilers == more possible errors. And i'm talking not 
> about a x86_64 release. Its only 32bit. That sounds a little bit nuts to me. 
> When i look at the compiling list i see different errors per compiler. This 
> means to me, that they hav to be fixed by different people in different places. 
> In an ideal world the project has enough ressources to handle this without 
> problem. This world we live in isn't ideal. Let's focus on one compiler and 
> build an automation structure. Maybe when the automation work and the 
> processes are proven a second ore third compler make sense.

Well, also on Linux there are different compiler releases, which have
different problems, different bugs etc.

The second thing is that with different compilers you will see different
bugs as well (Just had such a warning yesterday, which wasn't available
in gcc). Also each compiler has advantages over the other one (which can
be quite important).

Also we invested quite some time into this, which would be totally
useless if we chose to stay with one compiler.

The compiler discussion is old already, and it won't be solved any time
soon. So let's try to focus on the other problems first.


> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows

More information about the Kde-windows mailing list