tmake(qmake)/automake (was:Re: New AppWizard Dialog)

Ralf Nolden nolden at
Mon Aug 13 08:25:34 UTC 2001


while working with my iPaq stuff, I realized that we will be confronted with 
the situation of more tmake/qmake stuff in the future. Though we support 
that, the main reason for using tmake is currently that those who want to 
compile their project on windows will stick with that. On the other hand, 
tmake doesn't do the packaging stuff etc. very well - in fact, in order to 
provide that feature-wise the same way that we do for KDE/automake packages, 
we need an architecture for that. Now, in any case that will require 
preparing the makefiles by tmake for a given platform that you want to make a 
src rpm for. Which is really bad since you have to provide a src package for 
each distro/UNIX version separately (as far as I understand this). So, to 
solve this, we should have an easy way of either:
a) combining both systems in the same package, thus the project management 
has to keep up both styles,'s and .pro files,

b) enable the user to switch between both systems on the fly by writing the 
according files and let him choose on the appwizard stage which project 
management system he wants.

I would say, as tmake stuff is desired for windows versions mostly to do a 
package, but users may want to use it alone, we should default on automake 
for all templates, but the user can still choose tmake. When he wants, he can 
select either "add tmake support" and thus setting the default project 
management (that one the makefiles are generated with) to either automake or 
tmake in a combo box. When tmake is selected and the user wants to do a 
package, we could ask wether he wants to use automake and update those files 
affected to match that and then do the package.... Anyway, it also depends if 
there is a real difference in what we can do with automake and what we can do 
with tmake, so if a converter can be possible that translates both formats 
into each other. 

Anyone spend some thoughts about that ?

We're not a company, we just produce better code at less costs.
Ralf Nolden
nolden at

The K Desktop Environment	The KDevelop Project

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

More information about the KDevelop-devel mailing list