Improve configuration infrastructure

[hmelder]

GNUstep's config infrastructure, mainly the code responsible for handling domains is quite complex, and does not work well with more restricted platforms like Android.

I propose the following changes:

• Adapt for the use case of GNUstep not being installed system-wide, but bundled in an application
  • Let the user supply a configuration dictionary, instead of storing a configuration file somewhere
  • Add hooks for NSSearchPathForDirectoriesInDomains, GSSetUserName, GNUstepConfig, GNUstepUserConfig, and GSDefaultsRootForUser
  • Have platform-specific default providers if no hooks are registered (Android, *NIX, Windows, etc.).
    Roughly the implementation of NSPathUtilities we have now

/**
 * If username is nil, the configuration independent of a user is returned
 * (e.g. common filesystem configuration).
 *
 * On GNUstep, there are four separate places where files related to GNUstep
 * are installed: these places are called "domains".
 * The four domains are USER, LOCAL, NETWORK, and SYSTEM. This is also the order
 * when quering NSSearchPathForDirectoriesInDomains.
 *
 * For more information on domains and the filesystem hierarchy, checkout the
 * GNUstep filesystem hierarchy document.
 *
 * Here is a list of keys that are expected to be found in the config dictionary.
 *
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_APPS
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_ADMIN_APPS
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_WEB_APPS
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_TOOLS
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_ADMIN_TOOLS
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_LIBRARY
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_LIBRARIES
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_HEADERS
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_DOC
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_DOC_MAN
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL, USER_DIR}_DOC_INFO
 *  GNUSTEP_{SYSTEM, NETWORK, LOCAL}_USERS_DIR
 */
typedef NSMutableDictionary *(*gs_config_handler)(NSString *username);

/**
 * Replaces the GNUstep default config handler which loads
 */
GS_EXPORT
void GSSetConfigHandler(gs_config_handler handler);

Ideas are welcome :D

[rfm]

I'm not seeing what the idea is here (or really what the problem is) ...

Adapt for the use case of GNUstep not being installed system-wide, but bundled in an application

The base library already provides for this situation (originally developed for distributing windows applications with everything inside the app bundle), with the various domains being inside a single fixed location or in a relocatable application bundle - it's just a matter of configuring it with the appropriate location information and the details are extensively covered in the base library documentation. In fact gnustep-make has a 'standalone' filesystem layout designed to make this even easier (the idea is that you just configure gnustep-make with that layout and then everything is done for you).

Perhaps what would be good for android would be to change gnustep-make to use the 'standalone' layout (or some android specific variant) by default when configuring on an android system?

Now, if the existing system is lacking in some specific detail, it would obviously make sense to enhance it, but it's not clear to me what might be missing.

[hmelder]

Perhaps what would be good for android would be to change gnustep-make to use the 'standalone' layout (or some android specific variant) by default when configuring on an android system?

This assumes that we know the installation directory at compile time, which is not the case. It would be great to provide a way to supply a config dictionary instead of a path, or at least resolve it dynamically on android (with the values in the config acting as an override).

I guess the LOCAL and SYSTEM domain can point the application's resource directory, while USER points to the application data directory.

[rfm]

This assumes that we know the installation directory at compile time
Rather, it assumes that you know whether you want a standalone (app bundle) based installation or a shared (different apps all use a common set of resources outside their bundles) setup.
Actually, even that is just for the default config locations: you can configure it so that base uses a config file from an environment variable, so you build for apps to be deployed in standalone setups by default, but switch to the use of a shared resource setup with an environment variable pointing to a config file in the shared location.

I guess the LOCAL and SYSTEM domain can point the application's resource directory,
while USER points to the application data directory.
Yes, you can point them all to the same place if you want.

PS. In theory the GNUstepConfig() function already allows you to control this programatically, overriding the default (ie when base was compiled) config or the information in the config file (normally read at runtime) by calling it with a non-nil argument before it's called automatically, but as far as I know nobody has ever needed that.