Автор: Qraizer
Дата сообщения: 31.01.2008 20:02
foreground, если тебе просто нужна некая STL, то наверняка она уже есть в твоей среде разработки, и как-то специально её настраивать не нужно - ужо всё сделано. Если же тебе хочется юзать именно STLPort, который я тоже уважаю больше поставляемых вместе со средами, то это другой вопрос.
Вообще говоря, немного зависит от версии. Если ты качал недавно, то процедура примерно следующая.
Распаковываешь (с сохранением дерева каталогов) в какой-нибудь каталог, не важно какой, но желательно с недлинным маршрутом и обязательно свой собственный, т.е. не в коем случае не перезаписывая уже имеющиеся заголовочные файлы твоей среды разработки. Я, например, у себя распаковал в D:\STL. Не меняешь и не переименовываешь в этом дереве никакие имена - ни подкаталогов, ни файлов.
Заходишь в подкаталог BUILD\LIB\, видишь некий CONFIGURE.BAT, который и запускаешь, указав используемый тобою компилятор. Я, например, иду в D:\STL\BUILD\LIB\ и запускаю CONFIGURE.BAT -с msvc71. Эта штука работает быстро и создаёт файл конфигурации, который будет использовать при построении библиотек.
Запускаешь построение библиотек отсюда же, пользуясь твоим мэйкером и указывая ему соответствующий твоему компилятору .MAK-файл. Я использую NMAKE -f MSVC.MAK. Эта штука будет работать довольно долго и в итоге создаст шесть библиотек: по два варианта - статическая .LIB и динамическая .DLL - релизная, отладочная и специальная отладочная версия STLPort. Релизные и отладочные отличаются в основном наличием или отсутствием оптимизации. Специальная же отладочная версия - это жестокая вестчь. Она очень хорошо отлавливает программерские глюки наподобие использования невалидных итераторов, неверных диапазонов последовательностей итп. Т.е. всё то, проверка чего занимает кучу времени, и поэтому этого очень не хочется иметь в готовом коде, но что очень может помочь при отладке. А особенно, когда ещё не специалист и понимаешь, что мог наглючить жёстко. STLPort чуть ли не единственная реализация STL, имеющая подобный отладочный режим. Но тормозит при этом, конечно, конкретно.
Ещё раз запускаешь свой мэйкер с тем же .MAK-файлом, но добавляешь параметр install. Я юзал NMAKE -f MSVC.MAK install. Эта штука тоже отрабатывает недолго, и результатом её работы является копирование .LIB и .DLL по соответствующим каталогам. А именно: .LIBы помещаются в подкаталог lib, .DLLки - в каталог bin. У меня это D:\STL\LIB и D:\STL\BIN соответственно. Впрочем, DLLки я переношу в Windows\System32.
Осталось выполнить что-то вроде NMAKE -f MSVC.MAK clean, чтобы грохнуть все объектники и связанное с ними, и если уже выполнил предыдущий пункт, то больше не нужное.
Если очень хочется, можно выполнить CONFIGURE.BAT --clean.
Вообще говоря, это потенциальный минимимум того, что нужно сделать. На самом деле, прилагая немного больше усилий, можно кастомизировать процесс в весьма широких пределах. Можно сказать строить только некоторые из шести библиотек или наоброт (на самом деле, есть ещё варианты, кроме указаных шести). Можно насоздавать несколько вариантов библиотек для нескольких компиляторов, если ты используешь их более одного, или с разными опциями компиляции (я например, использую три варианта - для VC71, для Intel C++ и для него же, но с поддержкой нативного long double). Обо всём этом можно почитать в его readmeях и хелпах.
Использовать STLPort потом тоже очень несложно. Его каталог LIB добавляешь к окружению, чтобы среда знала, где искать .LIBы, BIN соответственно к путям, чтобы .DLLки нормально находились (впрочем, если копирнуть в общедоступное место, как я в Windows\System32, то BIN не нужен). Можно добавить на постоянной основе, они не мешают, даже если не использовать STLPort. Его каталог STLPORT (у меня это D:\STL\STLPORT) нужно добавить к окружению впереди каталогов среды, чтобы компилятор начинал поиск заголовков оттуда. Соответственно добавлять не нужно, если ты не хочешь использовать STLPort, а желаешь вместо него заюзать STL, поставляемую с твоей средой. Т.е. переключаться между ними не просто, а очень просто - указав на первом месте STLPortовый каталог или не указав. Всё остальное сделается само, т.к. для MSный сред разработки в заголовках STLPort-а расставлены автолинующие прагмы, которые сами укажут линкеру, какую либу нужно подлинковывать.
Только правильно указывай параметры компиляции: для статических либ говори, мол, хочу static libraries, для динамических - хочу dynamic libraries. Т.е. статис/динамик "для STLPort-а" будет совпадать с "для RTL". Для релизных библиотек нужно, чтобы дифайн _DEBUG отсутствовал, для дебуга наоборот, присутствовал; для юзанья специального дебуга, нужен просто дебуг и плюс ещё один дефайн - _STLP_DEBUG. Обо всём, кроме _STLP_DEBUG, заботится сама среда разработки, когда меняешь соответствующие параметры в настройках проекта. Так что всё учтено. Единственное, что следует помнить, по дефолту STLPort стоит свои библиотеки как multithreadные, поэтому для статических библиотек нужно выбирать RTLные либы тоже multithreadные. Можно посторить STLPort и для без multithreadности, но ИМХО это лишнее.
В заключение. Не всё в STLPort-у является просто заголовками. Кое-что не инстанцируется по месту использования, а подликовывается для сокращения времени компиляции и уменьшения размеров исполняемых файлов. Вот это и включается в библиотеки. Туда помещается форматирующий ввод/вывод, комплексные и некоторые строковые операции и работа с локалями. Можно вообще не строить библиотеки, но в этом случае либо некоторые возможности будут недоступны, либо будут заюзаны исходные возможности среды разработки. Вообще, в STLPort-у есть три замечательных заголовка host.h, stl_mycomp.h и user_config.h, которые лежат в STLPORT\STL\CONFIG\, и которые позволяют много что настроить очень детально.
Но страшно что-то.