A common configuration format, anyone?

[Philip Ashmore <contact@philipashmore.com>]

Hi there.

As someone who develops software for Debian I encounter situations where 
I have to specify the same information multiple times, and when that 
information changes I have to remember to update it in each of these places.

Just now I had to add a debian/*doc.postrm.in to one of my projects.
Makefile.am - save the *in file in EXTRA_DIST
configure.ac - convert the *.in to a *.
Git - add to version control.
makefile - new version
NEWS - what's changed
ChangeLog - what's changed
Git - store the changes

As a C++ developer it can get much worse and the opportunity for 
mistakes to happen increase proportionately.
This is from someone who uses the compiler to check my syntax.

Each of these processes provides a way to verify your input but it's not 
the right place to properly address the issue.

I'm proposing a means to capture these work-flows by storing the 
information in one place and providing mechanisms for doing 
project-level semantic validation and change management.

I've already got a format - a text file that has a binary representation.

You can take a look at the sb/tests directory to see "Hello world!" 
printed out using several different approaches to inspect the same data.

    program
    ( attributes
        ( id([bd64d1f6-a1f8-45bf-9f65-ce0842eda6d7])
        )
    , name("hello-world")
    , contents
        ( puts
            ( type(function-prototype)
            , returns(int)
            , parameters
                ( str(type(pointer(const(char))))
                )
            )
        , main
            ( type(function)
            , returns(int)
            , parameters
                ( argc(type(int))
                , argv(type(array(pointer(char))))
                )
            , body
                ( puts("Hello, world!")
                , return(0)
                )
            )
        )
    )

I realise that asking all developers to change their configuration 
format is ridiculous, but I ask it anyway.

Specifying content in a way that's easy to inspect transform and verify 
should be a corner-stone of software development but it seems to be one 
of those things that "was like that when I got here".

Anyway, I'm going to keep with it and see how deep this rabbit-hole goes.

Regards,
Philip Ashmore