KDEVELOP_1_4: fix for a crash and kdevprj

[F@lk Brettschneider]

Hi,

Simon Hausmann wrote:
> 
> On Tue, Jul 03, 2001 at 10:49:49AM -0700, Roland Krause wrote:
> > Falk,
> > automake and or tmake/qmake will have their advantages and
> > disadvantages. qmake/tmake is relatively simple but it doesnt really
> > work for cross platform stuff 1/10th as well as autoconf does.
> > E.g. on all platform I've tried so far I have to directly tweak the
> > makefiles :-( when building Qt.
> >
> > automake has it's advantages and disadvantages but it is very easy to
> > handle (remember we are not talking about autoconf) and gives you the
> > necessary information, i.e. names of files to compile and libraries to
> > build and install.
> 
> Exactly. And with the templates from kde-common/admin building a fully
> autoconf and automake enabled project is a piece of cake. Take admin/ ,
> add a configure.in.in with just '#MIN_CONFIG' , and take Makefile.cvs and
> Makefile.am from for example koffice/ . That's it. Everything is in-place
> to build a fully kde/qt enabled application, all macros, configure checks,
> Makefile variables (with all the KDE extensions like $(all_libraries) or
> kde_moduledir) .
I don't doubt automake is OK for many cases but you can forget it if you
develop cross-platform with Qt.
For instance our company uses KDevelop for Linux, MSVC for Win32. The
base is the .pro file (tmake). Using those .pro files, we generate .dsp
files for programming with the comfortable MSVC IDE, and we generate
Makefiles for Custom projects supported by KDevelop on Linux.

There's a simple fact that we don't use autoconf/automake - you cannot
generate MSVC projects from it. :-P
Furthermore, you need a big book and some weeks for learning
autoconf/automake but I learned to handle tmake projecs in 1 day, it's
very intuitive.
Last but not least we handle projects as big as kdebase and with a
non-trivial structure by using .pro files and never had any problems or
had to do hacks, neither on Win32 nor on Linux.

I must very much agree to Roland (rokrau), KDevelop needs an abstract
project management independent of them all. Restricting to only using
autoconf/automake would mean a big step backwards. Please, don't drop
this advantage of KDevelop <= version 2.0 compared to other C++ IDEs!
Always remember, there's also a world outside of KDE. ;)

Ciao,
F at lk

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«