From kde-core-devel  Sun Feb 20 14:22:53 2005
From: Fred Schaettgen <kde.sch () ttgen ! net>
Date: Sun, 20 Feb 2005 14:22:53 +0000
To: kde-core-devel
Subject: Re: Build system (was Re: Future of KDE Development)
Message-Id: <200502201522.53661.kde.sch () ttgen ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110896587318728

On Friday 18 February 2005 16:34, Harri Porten wrote:
> Although I'd prefer to have this flexibility as well one should be fair
> and not dismiss one big drawback: other tools like KDevelop won't be able
> to reverse engineer the information anymore. 
> .. 
> Therefore some simple input format or at least some special tagging 
> would be important, too.

I would very much prefer the second option.

A simple input format only works well for simple problems, and it starts 
getting nasty if you can't express a solution for a given build problem 
easily in the terms of this simple input format.
If kdevelop could only parse scons files which adhere to some conventions (be 
it special comments or variable names), then we can decide case by case if 
it's better to follow these conventions, but leading to a more ugly solution 
in complicated cases, or we can choose to sacrifice kdevelop compatibility if 
this makes things a lot easier.
It would be up to the users and developers of kdevelop to enforce these 
conventions. Either they will be accepted or not. But I think we better let 
the market decide instead of forcing everyone to follow these rules.

If the restrictions on sconsfiles imposed by kdevelop lead to nice, consistent 
and easy-to-read build files, then even non-kdevelop users will be happy to 
follow them. The build system could even print warnings if the input format 
isn't simple enough for kdevelop. But we should always be free not to follow 
a convention whenever we think that this is the best option at the moment.

Fred, hoping for a life without auto[conf|make]

-- 
Fred Schaettgen
kde.sch@ttgen.net