Bug 103758

dbus-message-builder was a domain-specific language for building D-Bus message blobs. It was introduced in 2003, and deleted in early 2005 when the type system was rewritten to be fully recursive. (See https://bugs.freedesktop.org/show_bug.cgi?id=103601#c28 for VCS archaeology)

These tests have been diagnosed as "skipped" since the commit that also deleted dbus-message-builder.[ch]:

commit 9d21554dd3b560952cd5aa607c4ec07898c0b260
Author: Havoc Pennington <hp@redhat.com>
Date:   2005-01-23 06:10:07 +0000

    2005-01-23  Havoc Pennington  <hp@redhat.com>
    
            * dbus/dbus-message-factory.c, dbus/dbus-message-util.c:
            get this all working, not many tests in the framework yet though

but even before that, the message builder language was disabled by:

+      if (FALSE) /* Message builder disabled, probably permanently,
+                  * I want to do it another way

which was part of this mega-commit:

commit 9c3d566e95c9080f6040c64531b0ccae22bd5d74
Author: Havoc Pennington <hp@redhat.com>
Date:   2005-01-15 07:15:38 +0000

    2005-01-15  Havoc Pennington  <hp@redhat.com>
    
            * Land the new message args API and type system.
    
            This patch is huge [...]

As a result of the type system having changed, the specific content of these files is probably no longer useful. However, the general concept of loading message blobs with known content and asserting that they do something sensible is potentially a valuable one, so maybe we should rescue some test coverage from them?

If we want a DSL for writing messages, here is a straw-man:

    message in xxd format, with comment lines introduced by #
    (xxd format is: "%08x: " offset, followed by up to 32 columns of hex
    with a space after each group of 4 digits, optionally followed by a
    double space and an ignored text-dump of the content)

    VALID or INVALID

    if VALID, some sort of encoding of the intended message content
    (GVariant text serialization?)

    if INVALID, the error code we expect to see

Unfortunately it would not really be OK for the "embedded tests" to link GLib for the GVariant text syntax. However, we could do something like this:

* in embedded tests
    * load each valid message (optionally with the crazy OOM-simulation),
      assert success or OOM
    * load each invalid message, assert the expected error code
* in GLib'y modular tests
    * load each valid message, assert expected content

I am not going to have time to work on this any time soon, but I'd review patches.

Until this happens, it might make sense to drop the unused code and data files, leaving this bug open - they haven't actually been used since 2005, and it would be trivial to get them back from git history for inspiration.