Rant: So you want help?
info at g-com.eu
Fri Nov 5 16:01:32 CET 2010
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>
> > 2010/11/5 Thomas Friedrichsmeier <thomas.friedrichsmeier at ruhr-uni-
> >> 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.
> 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.
> Cristian Onet
> Kde-windows mailing list
> Kde-windows at kde.org
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.
More information about the Kde-windows