На просторах инета я наткнулся на компонент для Delphi работающий с SQLite. При ближайшем рассмотрении в нем обнаружилась папка в которой лежал SQLite в виде .obj файлов. Я написал к нему юнит описание SQLite3ApiObj полностью повторяющий SQLite3Api. Теперь любой желающий может скомпилировать свою программу и запустить без sqlite3.dll. Не знаю нужно ли это кому нибудь, но выкладываю.
Версия SQLite 3.2.8.

[size=-2]------ Добавлено в 12:11
забыл добавить, что содержимое нужно поместить в elementdelphicode и в коде элементов использующих SQLite поменять название юнита с SQLite3Api на SQLite3ApiObj.
PS: Я знаю, что размер exe-шника "слегка" вырастет

Аттач ниже.

Chesh, а просто интересно на сколько больше готового exe-шника+sqlite3.dll ?

Tad, 302 кб exe-шник с obj, 66,5 кб без него. Размер DLL 349 кб. Итого 349+66,5=415,5 против 302.
А еще нашел obj от версии 3.3.4. если надо скажите, выложу.

Ну собственно, DLL - это безусловное пристегивание ВСЕХ фич, без анализа их использования...
Так что, результат этого "насколько" еще зависит и от того, насколько "все" из SQLite ты используешь.
ИМХО

Чтобы каждый раз не менять, нужно через условную компиляцию сделать. А ещё, хорошо бы символы условной компиляции добавить в Settings (для каждого компилятора). А ещё, хорошо бы символы условной компиляции и в sha-файле хранить.

Galkov, а еще HiAsm пакует экзэшник, а длл врядли упакована
tsdima, да ты прав, но я не стал пока трогать основной юнит, вдруг сообщество не одобрит такое нововведение. Если одобрите - то после выходных выложу на SVN.

В каком же виде?

Основной юнит трогать не надо. А вот компоненты - да, чтобы они подключали тот или другой основной юнит в зависимости от символов условной компиляции.

Чё то вы тут много понаписали а главного не сказали .
При использовании SQLiteObj.zip не надо будет таскать с прогой ещё и файл SQLite.DLL.
Плюсы очевидны при желании можно уменьшить общий вес программы,и не таскать не нужные фичи из DLL.
Минусы - такая прога может не влезть на форум и качать примеры ни какого трафика не хватит.

я думал, что EXE-шники уже все повыкидывал...
а второй пост Автора про что тогда ???

Dilma, тов. tsdima предложил сделать через условную компиляцию. Можно сделать это в SQLite3Api, а можно в каждом из элементов работабщих с SQLite, в секции uses. По моему, все таки, первый вариант лучше. Также добавить SQLite3Api.inc с {$define SQLITE_INDLL}

Может не надо плодить .inc файлы?

мне тоже не нравиться такое разнообразие. К тому же не подконрольное разработчику схем. Но как выйти из ситуации? Не знаю пока есть ли возможность это реализовать - может сделать элемент среды типа HubEx, назвать его ProjectOption, а в нем пропертисы _prop_MT_ENABLED, _prop_SQLITE_INDLL, и так далее. Логика работы проста: если на схеме есть этот элемент то берем данные и генерим условия компиляции, если нет, то по умолчанию.
Не знаю как реализовать это самому. Скорее это вопрос к Dilma.

ProjectOption давно пора сделать, которые в .sha файле будут сохраняться. Вполне допустимо, как компонент, либо как специальные свойства (определённого типа) главного компонента проекта. Без вмешательства в среду это вполне можно сделать - учесть в CodeGen.

[size=-2]------ Добавлено в 21:50
Пожалуйста. Кстати, я немного сократил каталог SQLiteObj, убрал почти всю C-RTL. Теперь "добавка" ещё меньше, в каталоге осталось лишь 4 файла

Подключение obj будет только если в командную строку компилятора добавить -DSQLITE_OBJ
Например так:

это здорово.
А вот у меня вопрос. А почему, если ты объединил SQLiteApi и SQLiteApiObj, такая странная функция CheckSQLiteLoaded ? в оригинальном SQLiteApi там есть проверка на наличие SQLite3.DLL.

И в добавку SQLite 3.3.4. в OBJ ах

[size=-2]------ Добавлено в 10:28
А вот здесь я объединил оригинальный SQLite3Api(без изменений), SQLite3ApiOBJ, SQLiteApi от tsdima и SQLite 3.3.4 в одном флаконе. В таком виде и предлагаю выложить его на SVN.
Условие компиляции находиться в SQLite3Api.inc. Для сборки без sqlite3.DLL поставьте в нем $ перед define.