[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

A common configuration format, anyone?

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.

    ( 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.

Philip Ashmore

Reply to: