Compile time options

[Sheldon Gill]

I thought it time to move this to a separate discussion thread.

I probably should have created a separate thread about "options.h" earlier 
rather than confusing things. So let me try now to clarify my proposal:

Configure generates "config.h" and friends to set things up for the platform. 
It detects the availability of libraries and functions etc. That's all fine 
and I'm not proposing we deprecate that or otherwise make changes there.

Increasingly within the GNUstep libraries, there are choices to be made about 
code behaviour at compile time. Within my patch there is 'platform support', 
for example. I can think of a number of such behaviour options we might have:

Theme support:  allow over-ride of drawing code for theming
Conf support:    enable/disable GNUstep.conf
Env  support:    allow environment variables to over-ride
Timezone files:  allow Win32 to ignore posix zone files
Default separation:  defaults in multiple files
Window decoration: allow gui to decorate it's windows

These sorts of things are internal to the library. I can foresee the number of 
these options growing.

In some cases now we are using the defaults mechanism to provide such choices 
without an easy way to set the compile-time default.
In other cases, there are compile time options which are obscure and difficult 
to find how to properly change.

For these sorts of things, I think that using configure makes things more 
difficult for us.
For starters, there is the documentation issue. There is plenty in the current 
setup which isn't documented, is poorly documented, or isn't in "./configure 
--help".
There is also the problem of having to re-run configure to change a single 
simple option. You need to know exactly how configure was last invoked to 
re-configure it correctly. For other projects I've had to write scripts to 
run configure so I could keep track of options properly. That's after I 
discovered what options were available and what they meant.
Thirdly, using configure becomes rather unwieldy when the command line gets 
very long.
I believe that the difficulty in setting things at compile time is resulting 
in fewer options within the library. I see this as leading to more debate 
about exact behaviour when a behaviour switch could provide an easy 
compromise.

I propose that we separate these "internal behaviour" compile time options 
from autoconf and put them in per library "options.h" or something similar. 
That can be the place to define all sorts of things like compile time 
behaviour switches and default names/locations used by the library.
Documentation for each item could then be in-line making it easier to create 
and maintain.

Another possibility would be to extend autoconf, possibly just by additional 
m4 scripts, to source a file or directory where such options can be easily 
defined and documented. 
That will mean that the "Optional Features:" list will grow long and some 
configure lines will be very lengthy indeed. It will still make changing 
options somewhat annoying as you'd need to re-run configure.

Anyway, I wanted to bring the issue up for wider discussion in the hope we can 
find a good solution.


Regards,
Sheldon




The "options.h" file I'm currently using for -base follows. Note that I've 
currently left things like default names and paths out for the moment.
--------------<options.h>-------------------------------------------------------
/* Build configuration options for GNUstep-base
 *
 * Author:  Sheldon Gill  <sheldon@iinet.net.au>
 * Date:    2004-01-18
 *
 * This file contains optional defines to include code for additional or
 * different behaviours.
 */

/*
 * Platform support allows searching for resources in the platform file system
 * heirarchy in addition to normal GNUstep places.
 */
#define OPTION_PLATFORM_SUPPORT

/*
 * Enforces 0600 permissions on the user's defaults database.
 */
// #define OPTION_ENFORCE_DEFAULT_PERMS

/*
 * Enables multi-cast DNS service discovery and publication services
 */
#define OPTION_ENABLE_NETSERVICES