You are here

LCFG Server Refactoring

Project ID: 
Current stage: 

Description: A project to rewrite the LCFG server to be cleaner and easier to maintain and develop, without significant change in functionality.

Deliverables: New LCFG server code.


Customer: All LCFG users.

Case statement: The LCFG server code has grown over many years and is virtually unmaintainable. There is a significant risk that the existing code base might not run "as is" on future DICE platforms. Further developments of LCFG are also stalled because of the difficulty of extending the existing code.



Timescales: Project to start in June 2009




Proposal: It is the project team's view that it would be difficult/impossible? to produce a detailed plan at the outset of the project.

Instead, we will plan our work on a month-by-month basis. We will produce, at each
development meeting, a report on progress made in the past month and an action plan for the current month.

We will review, biannually, effort expended and progress made in order to decide whether to continue with the project.

Resources: Substantial design/programming resources required.


  1. Produce test suite

    Produce a test suite so that we can ensure that code changes don't affect the
    behaviour of the compiler. For now, only interested in "system" testing - ie generated profiles.

    The test suite :-

    • must cope with testing uncommitted code changes
    • must be portable so that developers can run it on their own machines
    • will include a snapshot of every header file, package list, default/schema
      files, source profiles plus the profiles for the source profiles as generated
      by the existing compiler.

    It is expected that the bulk of the work is in producing a "difftool" to
    compare the output of the modified compiler with that of the existing compiler.

    Estimate 7-8 days of effort.

  2. Improve coding standards

    Bring existing code up to modern perl coding standards :-

    • everything passes perl critic (at some level of perl-critic acceptance)
    • turn on use strict and use warnings
    • use subset of perl to improve readability
    • use perl-tidy (need to agree on perl style)
    • pod sanity and coverage checks
    • will review changes (at file granularity) before commit (? submit patch via bugs?)

    Estimate 5 days of effort (might stretch). Can parallelize work across team, as long as communicate well.

  3. Mkxprof running as normal user

    Modify mkxprof code to run as normal user rather than as root

    Estimate 2-3 days of effort.



Risks: Throughout the project, there is a risk that we will underestimate the effort required to understand and re-engineer particular sections of the existing code.



Proposed date Achieved date Name Description
2010-04-30 1.0 Produce test suite
2010-02-28 2010-01-31 2.0 Switch package building to Module::Build
2010-02-10 2009-09-30 3.0 Run all Perl code through perltidy
2009-10-26 2009-09-30 4.0 Remove all pre-processed Perl files and replace macros with a module to handle configuration.
2010-01-31 2010-01-31 5.0 Perl critic level 5
2010-02-14 2010-02-28 6.0 Perl critic level 4
2011-08-11 2010-04-28 7.0 Fix major causes of warnings
2010-02-28 2010-02-25 8.0 Rewrite mkxprof commandline handling
2010-04-30 9.0 Add git support to LCFG build tools.
2011-09-30 10.0 Replace various database interfaces with Object-Oriented classes.
2011-10-30 11.0 Refactor the mkxprof script into an Object-Oriented class using Moose so that the huge number of global variables can be become attributes. This would make the coder safer, easier to read and maintain, and would permit the automated handling of command-line options and configuration files.