First make sure you really need this - having a central library which is reused more than 100 times works better when the public interface of that library does not change too often or only at specific points in time. Check if it is possible to split up your library in smaller parts, so that changes in one part don't affect the dependent projects of the other parts. Check also if it is possible to develop any changes to that library first "in private", and publish them (visibly for the majority of dependent projects) only for new "major releases" of that library.
But let's assume your project dependencies are correct and necessary for your system, and you really need to extend the public parts of that central library (or central class "A") very often. Then, you cannot avoid that all dependent projects have to be recompiled. But since you typically don't make changes to all the 100 projects simultaneously, you don't have to recompile them all on your local workstation.
What you need in this situation is a build server - a server which automatically checks out all changes from your SCCS and runs a full build of all the 100 projects in the background. For setting up such a system, you will also need a good structured automatic build process. Hopefully your 100 projects can be split up into groups of projects which can be individually compiled and tested, otherwise you have to solve that problem first.
Also a good read, though a bit outdated: Large Scale C++ Software Design by John Lakos. This book will also explain the PIMPL idiom mentioned by Jtrana in depth, though this will only help you with the private parts of your classes, not with the public ones like in your example.