Optimize compilation time?

[rbx]

@dennisklein My thoughts on this comment.

The question is if boost::signals can be hidden from public headers (or specifically FairMQDevice.h).

boost::signals propagates to FairMQDevice.h through:

1. FairMQDevice.h --> ProgOptions.h --> EventManager.h --> boost::signals,
2. FairMQDevice.h --> FairMQChannel.h --> Properties.h --> EventManager.h --> boost::signals.

For 1, ProgOptions can be made a forward declaration, but at at a price of forcing user to include ProgOptions.h wherever fConfig or GetConfig are used, which in majority of cases will be a small breaking change (due to missing include statements on user side).
For 2, I can actually remove Properties class entirely from FairMQChannel, it will only involve small amount of refactoring.

Ideally we would hide boost::signals from EventManager, but I don't see how it can be done, because the template types it takes propagate through to the user interface. Same thing goes for hiding EventManager in ProgOptions/Properties.

What do you think?

We also should consider the trade-off between compile time and potential runtime optimizations compiler can make. For config code this is probably not critical, but we don't have precise measurements for this atm.

[ktf]

Regarding having to include ProgOptions.h, I am completely fine with this because in any case this is hidden inside DPL in our case.

[dennisklein]

Let's think how we can get rid of boost::signals in EventManager. If we switch to C++17 now anyways I am sure we have enough tools to re-implement it much more lightweight.

[ktf]

I would actually be interested in any "lightweight" alternative for my ServiceRegistry as well.