Mir header install paths forces client developers to use pkg-config

[Daniel van Vugt]

Mir installs headers under:
  /usr/include/mircommon/mir/a.h
  /usr/include/mircommon/mir_toolkit/b.h
  /usr/include/mirclient/mir_toolkit/c.h
  /usr/include/mirserver/mir/d.h

This allows you to include <mir/foo.h> or <mir_toolkit/bar.h>, however only if you have the right include path set up. To get the include path you need to use pkg-config:
  pkg-config mirclient --cflags

I think it would be nicer if we used install paths that did not force developers to depend on pkg-config. That means using:
  /usr/include/mir/e.h
and maybe
  /usr/include/mir_toolkit/f.h

This problem has already caused confusion for one client developer as seen in bug 1161064.

[Robert Ancell (robert-ancell)]

No, no, no, no. This isn't the 1980's. We need to be able to version headers correctly.

[Daniel van Vugt (vanvugt)]

Versioning is fine, but we're not even doing versioning yet. And when we do, we could have versioning AND resolve the uncleanliness described here by using:
    /usr/include/mir-1.0/mir/foo.h

[Daniel van Vugt (vanvugt)]

Or alternatively:
  #include <mir/1.0/foo.h>
  #include <mir-1.0/foo.h>
  #include <mir1/foo.h>

[Daniel van Vugt (vanvugt)]

OK, the assertion that you /have/ to use pkg-config is weak and we are now off-topic. Keeping this bug open won't help.

[Sturm Flut (sturmflut)]

I would always prefer the solution without pkgconfig. I opened bug 1161064 because I expected that a simple #include <mir/client/mir_toolkit/mir_client_library.h> would do the trick, and when it didn't work I never even thought of having to use pkgconfig and I wouldn't have known which package to pass (who thinks of "mircommon"?).

Header files in /usr/include should use the default compiler include paths and not rely on pkgconfig. If versioning is needed the solution proposed by Daniel (just include the version in the directory name) should suffice.