From kde-buildsystem  Sun Oct 23 12:37:23 2005
From: michael-olbrich () web ! de (Michael Olbrich)
Date: Sun, 23 Oct 2005 12:37:23 +0000
To: kde-buildsystem
Subject: very basic SConfigure support available
Message-Id: <20051023123723.GA24141 () a168 ! apm ! etc ! tu-bs ! de>
X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=113280651111833

On Sun, Oct 23, 2005 at 02:01:55AM +0200, Ralf Habacker wrote:
> relating to the discussed custom configure support I have prepared some 
> example, how it could be structured. Please send your suggestions to this 
> list. 

Could we use this opportunity to create a clean structure for the tests?
Currently it is quite a mess.
Some test can be disabled via configure options others cannot.
Some print a large warning at the end of configure when they fail others
silently disable huge blocks of code.
Some disable by manipulating SUBDIRS (e.g. KDE/kdebase/kioslave) others
by an #ifdef arround all code (e.g. KDE/kdelibs/kioslave/bzip2).

I propose to create an object for each test with the following
information:

- identifier
- description 
- function to check and provide compiler and linker flags
- default if no configure options if given

I'm sure we can create generic functions for header files, pkgconfig
etc.

In the SConscript file we could then do something like:

obj.Requires('bzip2')

That would then disable the creation of the target if bzip2 is missing
and automatically add the necessary compiler and linker flags.

We could also use this to create several configure options for each
test:
- disable completely (as if the test failed)
- enable the test.
- require the test to be sucessfull or abbort the configuration.


michael