I'd like to do an experiment with fpc and fpc based apps(mostly fpgui, mse*, Lazarus...). The experiment involves using a closed source software called Flavouring Control System(FCS). FCS is something like an advanced patching system. It can modify files not only depending on the available HDD content, but also on data gathered using external applications. For example, modifying source files depending on "fpc -iX" output. FCS uses symbols(defines), macros, possibility to run external programs, setting an order in the way files are being modified, storing/exporting data(text or binary) within/from flavour files, internal scripting and so on, everything done on the fly. I think it's a much more complicated application compared to a simple "patch" one, but this doesn't mean it's better suited for specific activities.
Now, FCS is already advanced enough to start acting as an installer, too. Lazarus has it's own fpcup support, fpgui and mse* don't have something similar, CT is too advanced for this. Installation/configuration/updating can be a pain for new users. My proposal is:
- I try to develop two flavours, one that acts as an installer and one that acts as an updater.
- You agree to make the changes to your apps so that the apps won't conflict one with the other at the same level. Example: FCS installs fpc and fpgui trunk versions filling a default fpc.cfg file. After that, trying to install mse* will fail because it requires a stable fpc version and default fpc configuration file points to a development version. I don't think this is a good enough example as mse* can be built using fpc trunk too, but you get my point.
If you would like to involve your application in this experiment, here is the first recommendation:
After installation, some default settings should be inserted automatically by FCS into default configuration files. The problem is that after installation, these configuration files might not exist. Also, even if they exist, their possible location might be unknown or obsolete in terms of content and path. The same application can change the location of the configuration file depending on its version or whatever other reasons. This situation has to be managed somehow. My idea is to add a parameter to an application(I think the IDE is most appropriate). Passing this parameter(something like "--assureconfigurationfile"), will make sure a valid configuration file exists, file that contains all possible macro values. The application will return the full path of the valid configuration file and will exit immediately, like "fpc -iX" commands. FCS will use this file path to update the involved values. Storing settings by executing an external app with settings as parameters is ok, too. Failure to fulfill this recommendation might lead to totally useless installations as FCS might build your app with a fpc and its default configuration file that are not in PATH environment or within default values. That's not good for an IDE, is it!?
If you would like to involve your app(IDEs are mostly targeted) in this experiment, you're welcome to reply to this forum subject.