Configuration

Configuring Fab

There are 3 broad potential approaches to configuration characterised by their complexity and extent.

In the middle of this spread is an approach like that currently used by FCM. That is, a configuration file which allows most things a user could reasonably want to achieve to be specified within an simple syntax.

If more control is needed then we envisage Fab being used as a library allowing the user to create their own bespoke build system. The cost of all that additional control is much greater complexity.

At the opposite end is the "zero configuration" approach where the tool builds whatever it is able from the current directory tree. This has the ultimate in simple interfaces but would be limited in what it is able to achieve. Still it should be enough for a lot experimental programming jobs.

Requirements

Zero configuration mode has no explicit configuration and so imposes no requirements. Likewise library mode defers configuration to its host program. In which case only the intermediate mode imposes requirements for configuration.

• Configuration exists as a hierarchy: Site, Project and Path. Options held lower in the hierarchy override those from higher up.
  • Site configuration is held in a known location and effects all instances of Fab running in that site.
  • Project configuration is held in a project's source tree and effects builds of that project.
  • Path configuration is also held in a project's source tree but effects only specific sub-trees.
• Each task type (compiler, source processor, etc) will require its own unique paramaters.

Analysis

Here we consider issues brought to the surface by the requirements.

Locating configuration

The location of site configuration is probably handled easily by hard coding a "well known location", typically this would be in the /etc directory. Allowing this to be overridden by an environment variable would add flexibility.

Locating the project configuration is a knottier problem though. We could make an assumption that the source tree is always part of a version controlled working copy. This would allow us to specify "the root of the working copy" but that has problems.

The assumption is not valid. It is usually true when undertaking interactive development and quite likely to be true when running test suites. On the other hand it is much less likely to be true when building releases for production, particularly at 3rd party sites.

Per path configuration could be specified in the file tree itself. This would have the advantage of embodying the area-of-effect in the location of the configuration. The down side is having to walk back up the tree from each location to determine the configuration in effect.

Alternatively the per-path configuration could be held in the project configuration. That way it is centralised and needn't be compiled, potentially for each file. Caching could remove that last problem.

The down side of keeping the per-path configuration at the location of the project configuration is that it is now separate from the paths to which it refers.

Managing Task Options

This theme of conflicting ways to organise continues with task options. Each kind of task, e.g. Compile Fortran or Invoke the C preprocessor, needs its own set of arguments and switches. There seem to be at least two axes on which these could be considered.

Options might be grouped per task type. This means that, for instance, all the arguments for the Fortran compiler will be held in one place. However this implies that all the options for a single file will not be together. e.g. Options for the C preprocessor in one group and for the C compiler of the same file, a different group.

Conversely options might be grouped by file. That way everything pertinent to that file is visible at a glance but it is no longer possible to take in all options for a particular task at once.

Note also that in reality options would be specified across the whole file tree. So options not set for a lower point in the tree would be inherited from a higher point. In which case it still may not be possible to understand completely what is going on from a single inspection.

Maybe some sort of debugging tool which allows the user to ask "What options are in play for this point in the tree and where do they come from?"