how to turn off -fno-exceptions in kdevelop
Wayne Innes
winnes at idx.com.au
Tue Mar 13 23:59:10 GMT 2001
Whilst I understand what you are saying, my main point is that if we are
going to have an IDE than verything should be controllable from the IDE.
As an example in MSVC when you create a project the makefiles etc are built
with the compiler/linker switches set so they are appropriate to the type of
project you have created. You can then change the switches to whatever you
want from within the IDE. By the way I am not saying that Kdevelop should be
copying everything that M$ do. However I see nothing wrong with taking ideas
from MSVC where they are useful.
One of the main reasons for having an IDE is to isolate the programmers from
the makefiles etc. For example although I have been using makefiles etc for
longer than I care to remember, I am not very familar with automake, config
stuff. One of the big attractions of kdevelop was that I could make use of
these things without having to know about it.
It also concerns me that its seems your reasoning seems to be along the
lines that the current behaviour is to enable the projects to stay update
for compiling KDE apps. A lot people won't by making KDE apps and they
should be considered.
I also take your point that "I would like to see the developers using
kdevelop taking more part actively in the development, even if it would be
in small areas of the code.". So you got me, I don't have huge amounts of
spare time but I am more than happy to take on a suitable task.
-----Original Message-----
From: Mailing list agent [mailto:mdom at barney.cs.uni-potsdam.de]On Behalf
Of Ralf Nolden
Sent: Tuesday, 13 March 2001 10:17 AM
To: kdevelop at kdevelop.org
Subject: Re: how to turn off -fno-exceptions in kdevelop
Juergen Suessmaier wrote:
Ok, can't resist to answer :-))
Here ya go:
> All that weren't that much of a big deal if the current KDevelop 1.4
> distribution were some sort of first run beta test. But the problem is
> that KDevelop 1.2 along with KDE1 worked _perfectly_ while the current
> version introduces _external_ problems that really shouldn't be there.
Well, with KDE *1*. With KDE 2 a lot of things have changed so we had to
deal with two things:
a) the KDE 2 architecture with XML stuff, changing API until almost end
of last year, integrating that admin directory and it's problems and
keeping kdevelop still as compatible as possible to KDE 1 until KDevelop
1.3. Now, kdevelop 1.4 is a port and although the kde 1 templates are
removed that didn't mean there are still places where work is necessary.
But generally, using the admin dir for KDE development is the way to go,
as well for Qt development. It is constantly updated by the KDE guys
like Stephan and you have to mind that there are a lot of easy things in
the Makefile.am's that can be used if you know how to write the
Makefile.am's. This is what's going on in the main KDE CVS' modules,
let's say with Icons. I myself have to look up these rules there
sometimes. What is needed is to find out the rules automatically and
dynamically because we used the admin dir of the checks it makes and
that it should make things easier to update with each KDE / Qt version.
The pro's are more than the con's here definetly, although it may seem
like it's causing you some trouble right now.
>
> Honestly, KDevelop is one of the best IDEs I've ever worked with and I
> really don't understand why its outstanding quality has to suffer from
> a set of external shell scripts... I'd be glad if somebody posted some
> real good reasons for all these odd compiler switches, so that I can
> revise my opinion and be happy with KDevelop 1.4 again.
see above. The compiler switches are general switches thought to be
needed by Stephan for KDE stuff. If you're not happy, take Stephan's
solution to avoid using them and write a patch to the project managment
for 2.0 and take part on that stuff in the active development. As much
as I appreciate comments and hints, I would like to see the developers
using kdevelop taking more part actively in the development, even if it
would be in small areas of the code. The codebase is so big that
everyone can look for a part to work on and everyone is invited to do
so. Take Roland as a good example. He ranted a bit first and is now
trying to do what he can do in his spare time, like we all do. I
wouldn't be that front up normally but there is, in opposition to many
other free projects, *nobody* paid for KDevelop development - although
some of us could really need it because we invest more than 10 hours a
day into our project.
> BTW: Has anybody managed to create text translation files (*.pot) with
> KDevelop yet? All I get is an empty (zero size) .po file but no .pot.
> I just want to make sure that I didn't do anything harmful before posting
> a bug report... :-)
I have it working here. You need to run make messages and merge first to
rebuild the pot file and add a po file of course. The differences will
be merged into the po file then.
Ralf
>
> Regards,
> Juergen
--
Finally, even I have to admit that being myself was the best thing
that ever could have happened to me. - Le Grand Charmeur
**********************************
Ralf Nolden
The KDevelop Project
http://www.kdevelop.org
nolden at kde.org
rnolden at kdevelop.org
**********************************
-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org
with the following body:
unsubscribe ;your-email-address+
-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«
More information about the KDevelop
mailing list