"Умная линковка" в компиляторах

[Sergey]

В твоем (задолбало писать Вашем) случае 100 кб кусок кода будет по моему методу прогнан 1 раз ровно и скомпилирован в 1 .о файл который будет 1 раз прилинкован к собираемому приложению. По твоему методу это будет:
прогон 100кб файла нарезателем и сохранение 100 кусков по килобайту (в реальности с учетом хэдеров и статических ф-ций будет не по килобайту, а по полтора-два). Потом 100 компиляций в 100 объектных файлов и 100 линковок. Соотвтетственно в случае ошибки в моем случае 1 компиляция, в твоем от 1 до 100.

Эта монструозная времязатратная операция нужна только ОДИН(!) раз при создании библиотеки. Далее, при компиляции целевого файла, использующего эту библиотеку, линкер будет выдёргивать из неё только те функции, которые задействованы. Неужели ты предлагаешь библиотеку собирать каждый раз при пересборке проекта?!
Наверное, надо внести ясность, под библиотекой в беседе, из которой выросла эта тема, понимается не Си-файл, а архив объектников, созданный библиотечным менеджером.

Преимущество очевидно и не требует переноса (в случае смены компилятора или платформы для компиляции) утилиты по нарезке и лечения ее багов буде такие найдутся.

К случаю SDCC это преимущество неприменимо. Переносить проекты с ZX-Spectrum/ZX-Evolution на другие платформы никто не собирается.

Я уже сказал что это не проблема sdcc, а проблема исключительно придуманная и тщательно лелеемая. Пре-процессор полностью решает ее без использования сторонних утилит.

Я очень критично отношусь к своим знаниям и способностям в программировании, особенно, что касается Си, и допускаю, что я тупой и несведущий, поэтому прошу дать алгоритм, как при использовании пакета SDCC сделать библиотеку (архив объектников типа "name.lib") так, чтобы при использовании её в проекте при линковке конечного файла из неё в код программы добавлялись только задействованные процедуры.

Таки не нужна, если пользоваться ВСЕМИ возможностями компиляторов С.

Если пользоваться всеми возможностями компилятора SDCC, то, конечно, резалка не нужна, потому что всё можно сделать вручную, изначально пиша () каждую функцию в отдельный исходник. Но я не собираюсь тратить на это время. Если есть готовый исходник с кучей функций, я его порежу и соберу в архив объектников автоматически.
У меня такое чувство, что меня пытаются убедить, что мне неудобно то, чем я пользуюсь

[Advertiser]

[Valen]

как при использовании пакета SDCC сделать библиотеку (архив объектников типа "name.lib") так, чтобы при использовании её в проекте при линковке конечного файла из неё в код программы добавлялись только задействованные процедуры

1. У тебя есть несколько .c файлов, в каждом файле - одна Си функция.
(т.е. ты нарезал на куски свой большей исходный файл или же изначально делал "много файлов")
2. Компилишь каждый .c файл в .rel файл
(используешь sdcc ключик "-c", который значит: только компилить и не линковать)
3. с помощью sdcclib, добавляешь .rel файлы, в один .lib файл

(по памяти написал)

[Sergey]

1. У тебя есть несколько .c файлов, в каждом файле - одна Си функция.
(т.е. ты нарезал на куски свой большей исходный файл или же изначально делал "много файлов")
2. Компилишь каждый .c файл в .rel файл
(используешь sdcc ключик "-c", который значит: только компилить и не линковать)
3. с помощью sdcclib, добавляешь .rel файлы, в один .lib файл

(по памяти написал)

Valen, спасибо, - именно так я и делаю. Но судя по высказываниям уважаемого (не сарказм) Q-Master`a есть более правильный и удобный способ, - таки, хотелось бы подробностей.

[Oleg N. Cher]

фокус не сработает, если в функциях используются "самодельные" типы данных, которые без хедера компилятор не распознает и выдаст ошибку синтаксиса. Не сталкивался с этим, потому что меня умиляет писать типы полностью, например, "unsigned char", а не заменять на свои типа "u8".

Да, если описывать типы и прототипы вызываемых функций прямо в теле, то во многих случаях можно обойтись без инклюдов.

В случае с ZXDev спишем накладные расходы по времени компиляции на многократную обработку инклюда SYSTEM.h - это обходится описанием недостающих типов в заголовке (до "линии заголовка"). Конечно куски компилятся сильно дольше, чем один исходник - из-за многократных (по количеству кусков) вызовов SDCC, который ОС надо настроить в памяти, подгрузить ассемблер, линкер и препроцессор, находящиеся в отдельных exe. В случае простых библиотек с десятком функций компиляция происходит секунды. Сейчас вот проверил - вся библиотека XDev компилится < 15 секунд - с разрезанием всех модулей, как положено, а она сейчас состоит из таких модулей:

SYSTEM Platform Strings Console GrScr GrPixel GrTiles GrFonts Math Timer Input

Притом у меня не самый мощный комп, один из первых двухъядерников с 2 Гб ОЗУ. Мне трудно представить ещё большую библиотеку для Спека, тем более, никто не заставляет пихать все модули в одну библиотеку, можно и в разные.



---------- Post added at 22:24 ---------- Previous post was at 21:26 ----------

Но судя по высказываниям уважаемого (не сарказм) Q-Master`a есть более правильный и удобный способ, - таки, хотелось бы подробностей.

Как понял его способ я: заключить каждую функцию в одном большом исходнике в такие "рамочки":

#ifdef _Function_1_
void Function_1 (void) {
  ..
}
#endif

- и потом скармливать компилятору весь исходник много раз, подпихивая ему в качестве параметра -D_Function_X_
При этом лично для меня очень сомнительно, что разделительные линии воспринимаются намного хуже кучи #ifdef'ов. И сомнительно что хидеры будут инклюдиться только раз, а не по количеству кусков. И это велосипед с квадратными колёсами, как я его понимаю. А сам я езжу на треугольных.

Почему есть трудности с внедрением круглых колёс в SDCC. Есть проблемы, связанные со static-функциями, которые обозначил Vitamin - с тем, что все имена в библиотеке глобальны (так спроектировано) и, возможны ещё некоторые проблемы, вызванными текущим каркасом разработки. Я не знаю как всё это решается в рамках GNU-утилит, надо разбираться.

[Q-Master]

Я правильно понимаю, что это будет каждый раз, при сборке приложения, которое использует библиотеку?

Стоп-стоп-стоп. Ключевым моментом был как-раз вопрос о ЕЖЕРАЗОВОЙ компиляции библиотеки. Если компиляция происходит один раз, то мой способ ессно не подходит, но в таком случае ручками распилить сорец на ф-ции и собрать как-надо значительно эффективнее чем автораспиливатель.

---------- Post added at 10:29 ---------- Previous post was at 10:20 ----------

Valen, спасибо, - именно так я и делаю. Но судя по высказываниям уважаемого (не сарказм) Q-Master`a есть более правильный и удобный способ, - таки, хотелось бы подробностей.

Стоп. Я говорил исключительно про "компиляция каждый раз", ибо рассматривать такой вопрос при линковке с статической либой мягко скажем глупо. В случае сборки библиотеки вообще делать 1 гигантский .с файл неразумно.

[Reobne]

Стоп-стоп-стоп. Ключевым моментом был как-раз вопрос о ЕЖЕРАЗОВОЙ компиляции библиотеки. Если компиляция происходит один раз, то мой способ ессно не подходит,

Вот непонятно, что за ежеразовость такая! Можно поподробней, когда этот "раз" наступает?

но в таком случае ручками распилить сорец на ф-ции и собрать как-надо значительно эффективнее чем автораспиливатель.

Кто это должен делать, тот кто подготавливает библиотеку, или пользователь(тот кто пишет прогу, использующую библиотеку) библиотеки?

---------- Post added at 12:44 ---------- Previous post was at 12:36 ----------

Чуток офтопика

[Q-Master]

Вот непонятно, что за ежеразовость такая! Можно поподробней, когда этот "раз" наступает?

Насколько я понял, изначально такой вариант и делался. Поэтому я и предложил вариант с #ifdef. В нормальном случае исходники либы представляет из себя изначально кучу .с файлов и не требуют таких извращений.

Кто это должен делать, тот кто подготавливает библиотеку, или пользователь(тот кто пишет прогу, использующую библиотеку) библиотеки?

Тот кто готовит библиотеку ессно. Точнее тот, кто ее собирает в статическую.

[Q-Master]

При этом лично для меня очень сомнительно, что разделительные линии воспринимаются намного хуже кучи #ifdef'ов. И сомнительно что хидеры будут инклюдиться только раз, а не по количеству кусков. И это велосипед с квадратными колёсами, как я его понимаю. А сам я езжу на треугольных.

Для случаев когда "библиотека" представляет из себя 1 исходник и не подготавливается автором никак:
компиляция в С происходит в 2 этапа: 1-препроцессор, 2-компиляция.
На 1м этапе выполняются все директивы препроцессора, в частности, #ifdef #endif, #warning, #error и тэдэ.
На 2м этапе происходит компиляция подготовленного.
Само собой что никого не интересует кто там в чем сомневается, ибо все инклюды находятся в том-же исходнике (одном) и соответственно включаются 1 единственный раз, т.к. в твоем случае 1 физический файл разрезается на 100500 кусков, а в моем случае компилятор просто ВЫКИДЫВАЕТ из текста ненужное и ничего никуда не режет.

PS: Можно мне пример исходников библиотеки в твоем исполнении, чтобы я таки понял за дело мы спорим или нет?

---------- Post added at 11:00 ---------- Previous post was at 10:58 ----------

Какой "таккой"? Я попросил разъяснить понятие "ежеразовость". Мой вопрос не подразумевает никакого контекста, на который можно сослаться словом "такой".

Ну прочитай данный тред с начала. Я-ж не буду пересказывать все его содержание?!
В моем понимании был такой вариант: библиотека есть мегасорец, который каждый разраб, который его юзает вынужден пилить на куски чтобы нормально линковать в свой проект.

[Oleg N. Cher]

Странно, я-же просто просил объяснить мне кое что, помочь понять, а в ответ получаю нечто непонятное мне, смахивающее на оправдания.

Reobne, перед нами - типичный случай за "умной" формулировкой замылить смысл происходящего. Мне тоже не нравится, что разговор ушёл в область каких-то абстрактных сопоставлений без детальных наглядных примеров, что я и хочу попытаться исправить.

1. Круглые колёса. Исходники любого содержания, хоть большие, хоть маленькие, хоть с инклюдами, хоть без, хоть со static'ами - всё едино - "умная линковка" из коробки, всё оно так и должно быть. В "правильных" компиляторах всё оно так и есть. Но в "неправильных", куда отнесём и SDCC, ВСЕ сущности из одного исходника попадают в один сегмент (*.rel) библиотеки и если использовать хоть ОДНУ сущность из этого сегмента - потянутся все остальные. Лечится распихиванием различных сущностей по разным исходникам. Остаётся проблема многократного запуска SDCC с его инфраструктурой, многократного парсинга инклюдов - она никуда не делась.
2. Квадратные колёса (по методу Q-Master). Делаем "резку" цельного исходника "в уме" с помощью препроцессора и #ifdef'ов, как я показал выше. Многократный запуск SDCC и проблема многократной обработки в исходнике инклюдов и static'ов никуда не делась, как бы её ни забалтывали:
   

   #include "MyIncl.h"
   #ifdef _ABC_1
   void ABC_1 (void) {
   }
   #endif
   #ifdef _ABC_2
   void ABC_2 (void) {
   }
   #endif

   Пусть нам Q-Master пояснит, как он предлагает компилить "в памяти" такую библиотеку с единоразовым запуском компилятора и единоразовой обработкой инклюда. С примерами объяснит и подробно.
3. Треугольные колёса (smartlib) - та же самая резка, но без #ifdef'ов, а с помощью "линии заголовка" и "линий разреза". При этом вменяемые этому способу проблемы с многократной обработкой инклюдов и static'ами точно и ровно также присутствуют и в "квадратном" варианте колёс.

Разумеется, я за правильные круглые колёса, только не вижу как в таком сообществе добиваться поставленных целей. Либо всё делать одному и выслушивать, что асм Z80 круче всего на свете, либо забить, выбирайте.

---------- Post added at 15:38 ---------- Previous post was at 15:15 ----------

в твоем случае 1 физический файл разрезается на 100500 кусков, а в моем случае компилятор просто ВЫКИДЫВАЕТ из текста ненужное и ничего никуда не режет.

PS: Можно мне пример исходников библиотеки в твоем исполнении, чтобы я таки понял за дело мы спорим или нет?

Давал уже, но отчего же, извольте.

#include "MyIncl.h" // Здесь то, что надо включать многократно,
// т.е. нужное ВСЕМ кускам.
// Секция заголовка может быть и ПУСТОЙ, т.е. не включать в себя ничего.
// Также она может просто отсутствовать - результат тот же.
/*================================== Header ==================================*/

#include "MyAbc1.h" // А вот здесь можно поместить нужное только ЭТОМУ куску

void ABC_1 (void) {
}

/*--------------------------------- Cut here ---------------------------------*/
#include "MyAbc2.h"
void ABC_2 (void) {
}

Как видим, присутствует возможность гибко выбирать какие инклюды включать многократно, какие однократно. Линии разреза наглядны. Фразы "Header" и "Cut here" могут быть убраны, решает только присутствие в комменте определённого количества идущих подряд "===" или "---". Т.е. ничем не хуже, а то и нагляднее вашего способа. А разрезанные файлы ОС кэширует (все мы знаем, что поиск во второй раз происходит во много раз быстрее, чем в первый), так что проблем со скоростью трансляции вообще нет.

Но вы лучше расскажите нам как компилить по вашему способу: во-первых "всё в памяти", а во-вторых - единократным вызовом компилятора (а может ещё и библиотекаря? ), ибо только это мы можем считать твёрдым достоинством квадратных колёс и преимущества их над треугольными.

[Oleg N. Cher]

Исходники либ есть в ZXDev, ссылки в Пристанище Спектрум-кодера. Дублировать ничего не буду.