> This MP is about runtime dependencies - we already use libboost-all-dev at build time
Actually this MP is about build time dependencies of other code building against the Mir libraries. We are providing headers in our -dev packages that reference various external headers but don't require (through package dependency mechanisms) those external headers to be present.
>> $ dpkg --search /usr/include/boost/asio.hpp
>> libboost1.53-dev: /usr/include/boost/asio.hpp
>
> header only library => not needed by runtime.
>
>> $ dpkg --search /usr/include/boost/throw_exception.hpp
>> libboost1.53-dev: /usr/include/boost/throw_exception.hpp
> header only library => not needed by runtime.
...but currently needed by other code when build against Mir (e.g., if they include asio_main_loop.h).
The throw_exception dependency can easily be removed. The asio dependency can also be removed, e.g., by using Cheshire Cat.
Note that we have even more external header dependencies that are not dealt with at the moment:
Our header dependencies are either headers that the users of mir libraries will need to interact with the library, or just header "leaks".
My proposal is to decide which is which, remove/hide the "leaked" header dependencies, and depend only on the -dev packages of real header dependencies.
> Do we also need to add libboost-system-dev?
It doesn't seem so. libboost-system doesn't provide any headers.
The improvements described above can be done in another MP, or this MP, I don't have a preference. This MP is fine as it is, so approving.
> This MP is about runtime dependencies - we already use libboost-all-dev at build time
Actually this MP is about build time dependencies of other code building against the Mir libraries. We are providing headers in our -dev packages that reference various external headers but don't require (through package dependency mechanisms) those external headers to be present.
>> $ dpkg --search /usr/include/ boost/asio. hpp boost/asio. hpp boost/throw_ exception. hpp boost/throw_ exception. hpp
>> libboost1.53-dev: /usr/include/
>
> header only library => not needed by runtime.
>
>> $ dpkg --search /usr/include/
>> libboost1.53-dev: /usr/include/
> header only library => not needed by runtime.
...but currently needed by other code when build against Mir (e.g., if they include asio_main_loop.h).
The throw_exception dependency can easily be removed. The asio dependency can also be removed, e.g., by using Cheshire Cat.
Note that we have even more external header dependencies that are not dealt with at the moment:
$ grep -R '#include <.*h\(pp\)*>' include/shared include/server include/client
... and after some manual filtering:
include/ server/ mir/compositor/ buffer_ swapper_ spin.h: #include <boost/ throw_exception .hpp> server/ mir/options/ program_ option. h:#include <boost/ program_ options/ variables_ map.hpp> server/ mir/options/ program_ option. h:#include <boost/ program_ options/ options_ description. hpp> server/ mir/asio_ main_loop. h:#include <boost/asio.hpp> server/ mir/graphics/ drm_authenticat or.h:#include <xf86drm.h> server/ mir/graphics/ gl_renderer. h:#include <GLES2/gl2.h> server/ mir/graphics/ internal_ client. h:#include <EGL/egl.h> server/ mir/graphics/ display_ report. h:#include <EGL/egl.h> shared/ mir/graphics/ android/ android_ driver_ interpreter. h:#include <system/window.h> shared/ mir/graphics/ android/ mir_native_ window. h:#include <system/window.h> shared/ mir/input/ xkb_mapper. h:#include <xkbcommon/ xkbcommon. h>
include/
include/
include/
include/
include/
include/
include/
include/
include/
include/
Our header dependencies are either headers that the users of mir libraries will need to interact with the library, or just header "leaks".
My proposal is to decide which is which, remove/hide the "leaked" header dependencies, and depend only on the -dev packages of real header dependencies.
> Do we also need to add libboost- system- dev?
It doesn't seem so. libboost-system doesn't provide any headers.
The improvements described above can be done in another MP, or this MP, I don't have a preference. This MP is fine as it is, so approving.