[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Compile time options
Compile time options
Thu, 11 Mar 2004 14:14:33 +0800
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
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
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
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
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.
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.
/* Build configuration options for GNUstep-base
* Author: Sheldon Gill <address@hidden>
* 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.
* Enforces 0600 permissions on the user's defaults database.
// #define OPTION_ENFORCE_DEFAULT_PERMS
* Enables multi-cast DNS service discovery and publication services
Re: Compile time options, Adam Fedor, 2004/03/14
- Compile time options,
Sheldon Gill <=
- Re: Compile time options, Kazunobu Kuriyama, 2004/03/12
- Re: Compile time options, Sheldon Gill, 2004/03/13
- Re: Compile time options, Alex Perez, 2004/03/13
- Re: Compile time options, Alexander Malmberg, 2004/03/13
- Re: Compile time options, Adam Fedor, 2004/03/13
- BACKEND_BUNDLE (Was: Re: Compile time options), Alexander Malmberg, 2004/03/14
- Re: BACKEND_BUNDLE (Was: Re: Compile time options), Adam Fedor, 2004/03/14
- Re: Compile time options, Nicola Pero, 2004/03/18