Есть несколько проектов и общее lib, где размещать lib?
Литература на это тему есть?

А без "литературы", просто подумать и сделать так, как разумно для этого случая?

У меня используется структура подкаталогов. Хидеры в каталоге _INC лежат, исходники в каталоге _LIB. Все пути в исходниках использую относительные. Общие для нескольких проектов исходники и хидеры лежат в одноименных каталогах, но уровнем выше. Перенести проект на другой диск или в другой подкаталог с сохранением структуры проекта не составляет особой сложности.

не хотелось бы велосипед изобретать, тем более что все тонкости сразу не учтеш.

С хидерами вроде понятно, для подключения пишем:
#include "..\_LIB\file.h"
(порядок включения, как я понимаю, - после хидеров проекта, перед стандартной библиотекой)
Можно наврное, добавлять путь"..\_INC\" в опциях предпроцессора, но тогда будут проблемы при однаковых именах хидеров, и менее наглядно, чем "..\_LIB\file.h" - сразу видну что хидер из библиотеки.

А исходники библиотеки придется добовлять в проект? Чего лучше использовать исходники или объектные?

И еще вопрос, в чем приимущества перед размещением в toolkit_dir?

Ну "наглядность" наглядностью, а возможность тасовки исходников резко снижается. Оптимальнее пути поиска все-же указывать компилятору.

Ну для начала стандартные указвабтся прежде всего, ибо по опредлению совершенно не зависят от того, что Вы дальше напишите. Остальное.

Лучше ни то, ни другое - лучше библиотеки. Ну они именно для этого сосданы и именно так и называются

А как будет происходить отладка? можно будет посмотреть чего делается в модулях библиотеки?

В умных книжках рекомендует включать хидеры от специализированных к более общим, цитата (в цитате) из книги Брюс Эккель Филосовия С++:

Заголовки включаются в порядке "отспециализированных к общим". Иначе говоря сначала включаются все заголовочные файлы в текущим каталоге, затем заголовочные файлы личного инструментария автора, затем заголовки стандартной библиотеки С++ и наконец, - заголовочные файлы библиотеки С.
Джон Лакос в своей книги "Large-Scale C++ Software Deign" так обосновывает эту последовательность
Автономная обработка h-файлов компонента (без внешних объявлений и определений) помогает предотвратить скрытые ошибки. Включение h-файла в самой первой строке c-файла гарантирует присутствие всей критически важной информации, относящейся к физическому интерфейса компонент (или ее отсутствие обнаружиться немедленно при попытке откомпилировать c-файл).
Если заголовочные файлы включаются в порядке "от специализированных к общим", вы быстрее обнаружите те из них, которые не обрабатываются автономно, и избавите сеюя от дальнейших огорчений.

>>>Заголовки включаются в порядке "отспециализированных к общим".

Считаю это неправильным, т.к. я могу в своих *.h файлах задефайнить какое-нибудь слово, и оно вполне возможно, что уже продефайнено где-то еще, в стандартных библиотеках. То что продефайнил сам, то помнишь и используешь нормально. Если вдруг надо использовать дефайн из стандартной библиотеки, то тоже вероятность обнаружить коллизию больше.