Interim build system (was: Post 3.2 Kopete)

[Adriaan de Groot]

On Tuesday 25 November 2003 19:41, Jason Keirstead wrote:
> I think this whole thread is an excellent argument for why we need some
> serious work done on Konstruct to get it ready for prime-time.
>
> If it were done properly, people could download, build, and install new
> Kopete / Noatun / Konqueror plugins with a simple click of the mouse, thus
> solving all of these problems. 

FWIW, KPilot is one of those apps in PIM where I've considered doing interim 
releases. When new hardware comes out, or USB support finally arrives, or I 
finally fix a long standing grave bug, I'd like to put out an interim 
release. But that has _nothing_ to do with packagers. They can ignore the 
interim. For people that _need_ the new stuff, I can point them to the source 
tarball.

All this discussion is about the process that a single project housed 
somewhere in a module follows for ensuring that it delivers quality software. 
And as Lauri pointed out, you're free to do that any way you like. And 
FreeBSD will ignore you. Fine.

Anyway, on to the subject at hand: how to build stuff effectively for a wide 
range of users. Preferably without the whole 800k of the KDE build system and 
configure scripts and whatnot. You may put your faith in Konstruct, I'll 
stick with AAP (www.a-a-p.org), which falls in the category of 
yet-another-make-replacement. You could view it as unsermake on steroids, 
subsuming the function of auto*, am_edit or unsermake, and make itself. I've 
put a bunch of effort into making it do KDE nicely (although it's really only 
tested on KPilot on BSD), AAP itself is packaged with FreeBSD, and doing a 
local upgrade of KPilot could be as simple as "aap -f 
http://www.slac.com/pilone/kpilot_home/kpilot-upgrade.aap".

-- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <groot at kde.org>
            If the door is ajar, can we fill it with door-jamb?