#include "" и INCLUDEPATH

В файлах #include нужно указывать относительно текущего файла. В таком случае includepath можно не указывать, компилятор производит автоматический поиск относительно компилируемого файла.

Например,
src
    - first
        - signal.h
        - first.cpp
    - second
        - signal.h
    - main
        - main.cpp

main.cpp
#include "../first/signal.h" // правильно
#include "../second/signal.h" // правильно

first.cpp
#include "signal.h" //правильно, равно first/signal.h, вне зависимости от includepath

Но если main.cpp будет такого вида:
#include "signal.h" // неверно, хотя и будет работать, если установлен INCLUDEPATH
и присутствует includepath, то выберется тот signal.h, папка которого находится раньше в includepath.

По мере разрастания проекта или выделения библиотеки позволяется для поиска хедеров в определенной директории установить INCLUDEPATH.

http://www.mingw.org/wiki/IncludePathHOWTO

Ограничение mingw на уровень вложенности хедера

Необъяснимое ограничение в mingw количество уровней вложенности файлов, включаемых через #include. Ошибка: no such file or directory.

Например, file.cpp
#include "../../../../../../../some_path/maybe_yet_path/file2.h"

При компиляции в win не находить файл file2.h, хотя в линуксе все норм. Критическое количество уровней не определял. Может из-за длины имени файла, но вроде ntfs, да и путь не такой уж длинный.

pysvn + sasl + ldap

Проблема.
После перевода сервера svn на режим аутентификации sasl + ldap перестал работать модуль pysvn на windows машинах. Вываливался с ошибкой: cannot negotiate authentication mechanism. Очевидно subversion библиотеки, которые с ним поставляются, скомпилированы без поддержки sals + ldap.

Решение.
Необходимо установить пакет консольных утилит subversion от кампании wandisco (или другой, лишь бы была поддержка sasl + ldap), добавить в переменную окружения PATH путь к wandisco, далее скопировать все динамические библиотеки (dll) из wandisco в папку, куда установлен pysvn (по умолчанию, python/lib/site-packages/pysvn). После этого должно заработать.
ps Замечено, что при удалении или переименовании wandisco перестает работать pysvn. Не удаляйте wandisco. Костыли конечно.

Установка нескольких процессоров для windows в virtualbox

Если при установке windows в virtualbox сначала машина была сконфигурирована как однопроцессорная, то после добавления процессора в свойствах настройки дополнительные процессора не будут видны в windows. Виной тому драйвер ОС, отвечающий за режим работы многопроцессорной системы. Решение следующее.

Если у вас ядро с ACPI.
Сменить его можно: диспетчер устройств-оборудование-компьютер-"многопроцессорный компьютер с ACPI-обновить драйвер-нет,не в этот раз-установка из указанного места-не выполнять поиск,я сам выберу драйвер. выбираем нужное ядро в табличке.
Существуют ядра(здесь и далее под ядром я понимаю ядро windows а не ядро процессора ):

"Стандартный компьютер"
"Компьютер с ACPI"
"Однопроцессорный компьютер с ACPI"
"Многопроцессорный компьютер с ACPI"
"Однопроцессорный компьютер с MPS"
"Многопроцессорный компьютер с MPS"
И еще одно:

Если того что вам нужно в списке нет, то нужное ядро появится после изменения HardwareID: рис (http://aceq.by.ru/ru/smena-tipa-komputera/jpg-kartinki/1.jpg) (SYSTEM\Current Control Set\Enum\Root\ACPI_HAL\). Если не позволяет сменить HardwareId, то нужно на папке выше вызвать контекстное меню и установить разрешение.

Меняем HardwareID на

acpiapic_mp -> добавляется строка с "Многопроцессорный компьютер с ACPI"
acpipic_up -> компьютер с ACPI
acpiapic_up -> "Однопроцессорный компьютер с ACPI"
mps_mp -> "Многопроцессорный компьютер с MPS"
e_isa_up -> "Стандартный компьютер"
mps_up -> "Однопроцессорный компьютер с MPS"
возможные значения HardwareID можно посмотреть в WINDOWS\inf\hal.inf

вообще необязательно указывать HardwareID именно для искомого типа ядра. Если указать acpiapic_up то в меню выбора ядер появятся все шесть типов.

Источник: http://forum.ixbt.com/post.cgi?id=print:22:65459

Загрузка waf tool

Проблема.

При выполнении конфигурации множества модулей со схожей конфигурацией методом recurse для каждого модуля производится поиск библиотек.

Решение.

Выполнение загрузки (load) расширения waf выполняется только однажды. Соответственно, только один раз выполняются методы options, configure и т.д., определенные в расширении. Но  configure для каждого модуля выполняется отдельно. Отсюда, если в модуле будет стоять conf.check_boost(), то проверка будет проходить каждый раз для модуля. Если необходимо в расширении проверить наличие библиотек, то вызов функции проверки должен осуществлять, например, из configure.