I don't see the connection, tbh. There's plenty of makefile targets, some of which may fail in various circumstances. Why do you think ./configure should fail to give you an early headsup that 'make check' will do the same later ?

I would personally prefer if we could drop our python dependency altogether, but its not exactly a priority.

Test suite dependency is totally different from building.

See also https://bugzilla.gnome.org/show_bug.cgi?id=670718

(In reply to comment #1)
> I would personally prefer if we could drop our python dependency altogether,
> but its not exactly a priority.

I don't think we want to rewrite gdbus-codegen(1) just to avoid a build-time dependency. Seriously, no, we don't want that.

(In reply to comment #1)
> Test suite dependency is totally different from building.

There are actually multiple kinds of dependencies - at least these three categories

 1. the deps on GLib runtime packages
    - no python dep, basically only libc + other core libs
 2. the deps on GLib devel packages
    - python dep due to e.g. gdbus-codegen(1)
    - perl dep due to e.g. glib-mkenuims
    - C compiler, C library headers, linkers etc
 3. the build deps for the GLib tarball (python dep, others)
    - includes at least the deps in 1. and 2.
      - Includes category 2. because it's a fair assumption that
        the glib devel tools are used in the build
        - for example gdbus-codegen(1) itself is used at
          least on Win32 and the test suite. It's not far fetched
          that we'll use gdbus-codegen(1) as a dep for e.g. libgio-2.0
          at some point in the future..

My view is that I don't think it's worthwhile to eliminate deps in anything but the first category. I know a lot of source-based distros / Linux-From-Scratch people like to eliminate deps in 2. and 3. but I still don't think that makes it right. But that's just me.

This is not a 'make check' fail.  It's a 'make' fail (ie: during the building of the testcases).

(In reply to comment #4)
> This is not a 'make check' fail.  It's a 'make' fail (ie: during the building
> of the testcases).

--disable-modular-tests

(In reply to comment #3)
>
> My view is that I don't think it's worthwhile to eliminate deps in anything but
> the first category. I know a lot of source-based distros / Linux-From-Scratch
> people like to eliminate deps in 2. and 3. but I still don't think that makes
> it right. But that's just me.

The problematic thing is *circular* build dependencies.  It's not a problem at all for something high in the stack to add a reasonable build dependency.

What would be a serious issue for "build everything" people is something like Python gaining a hard build dependency on a recent GLib version.  I've thought about this occasionally...basically have Python ship out of the box on Linux with GLib mainloop bindings.  Not really worth it, but not completely inconceivable either.

The way to solve these things is generally that projects should offer a way to cut them manually.  So realistically Python would have to offer a --disable-glib option.

A current example is there's a systemd <-> dbus circular build dependency (and actually the dbus libx11 complicates the graph significantly).  But it's totally not a problem because I can just build dbus twice; first without systemd and libx11:

http://git.gnome.org/browse/gnome-ostree/tree/gnomeos-3.6.json?id=65b0d806400d3f0edd21cc48e10541210481c9b6#n64

And then later with it.

We now require Python for a few more things (the rewritten glib-mkenums and and glib-genmarshal, for example), and once we entirely switch to Meson in favour of autotools, the Python requirement will become a hard requirement.

Closing.