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

[Q-Master]

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

Редкостная чепуха. Ни один из основных используемых компиляторов на не8-битках при линковании исполняемого файла со статическими библиотеками не тянет все поголовно ф-ции, если они не используются. Не надо проецировать Борландовские поделия на все остальные компиляторы.
Как ведет себя в этом случае сдцц я не в курсе, но подозреваю что такой примитивный вариант оптимизации там осилили. Если не осилили то здравый вариант разбивать на модули с ф-циями объединенными по некоему признаку. В этом случае из статической библиотеки слинкуются только те объектники, которые содержат используемые ф-ции.

[Advertiser]

[Oleg N. Cher]

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

Врушки. Ещё - Microsoft Quick C, DJGPP для Windows, Tiny C (tcc) и почти все старые сишные компиляторы, с которыми я работал. Должным образом эта проблема, пожалуй, решена только в GCC (дополнительными ключами командной строки: -ffunction-sections, -fdata-section, --gc-sections) и в MS Visual C++.

Как ведет себя в этом случае сдцц я не в курсе, но подозреваю что такой примитивный вариант оптимизации там осилили.

Нет. Я реквестил его, но Филлипа это не пробрало. Видимо, он делает библиотеки также как Sergey и не считает эту задачу насущной. Ещё я пробовал пробить данную возможность в сообщество разработчиков tcc, но и там отнеслись прохладно. Проще говоря, отказали. Почитайте, чем аргументировали.

Так что в XDev использование утилиты smartlib - не роскошь, а злободневная потребность. Особенно с учётом того, что некоторые компиляторы уже никогда не доработают (например, Turbo C).

Если не осилили то здравый вариант разбивать на модули с ф-циями объединенными по некоему признаку. В этом случае из статической библиотеки слинкуются только те объектники, которые содержат используемые ф-ции.

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

Вопрос в том, как именно поступить: разделить исходник библиотеки по "ф-циями объединенными по некоему признаку" на несколько кусков вручную, т.е. каждый такой кусок держать в виде отдельного файла, собирать мейком и радоваться. Либо же, как предлагаю я, иметь всю библиотеку в виде одного исходника и бить её на куски автоматически (места разделения кусков указываются программистом также вручную) в процессе сборки библиотеки. Как по мне, второй вариант значительно удобнее. Говорю как человек, сделавший большое количество библиотек для SDCC. За счёт того, что всё в рамках одного файла - проще редактировать, искать, переносить. Плюс с разделителями смотрится красиво.

[Q-Master]

Вопрос в том, как именно поступить: разделить исходник библиотеки по "ф-циями объединенными по некоему признаку" на несколько кусков вручную, т.е. каждый такой кусок держать в виде отдельного файла, собирать мейком и радоваться. Либо же, как предлагаю я, иметь всю библиотеку в виде одного исходника и бить её на куски автоматически (места разделения кусков указываются программистом также вручную) в процессе сборки библиотеки. Как по мне, второй вариант значительно удобнее. Говорю как человек, сделавший большое количество библиотек для SDCC. За счёт того, что всё в рамках одного файла - проще редактировать, искать, переносить. Плюс с разделителями смотрится красиво.

Первый вариант аутентичен для любого проекта на С/С++. В принципе он вполне аутентичен для ассемблерного кода. Исходя из этого (ну и из того что аутентичным его сделали нифига не глупые люди) это оптимальный вариант с не очень большим оверхедом.
Второй вариант во-1 очень трудно поддерживаем, т.к. требует не статической либы с кучей скомпилированных .o файлов внутри, а какого-то адского гемороя по указыванию какие куски откуда надо выкусить и куда собрать ( с этим вполне справляется компилятор без необходимости в программисте). Во-2, такой вариант нечитаем. В-3, сборка проекта будет увеличена ровно на время разбиения мегасорца на куски и последущей компиляции этой помойки. В-4, ошибки при таком разбиении практически гарантированы и вызывают п.3 в полный рост КАЖДЫЙ раз.
Могу предложить еще 3й вариант как компромисс между 1м и 2м:
config.h с куче #define где указывается какие ф-ции надо компилировать из исходников, а какие нет. Вариант имеет часть недостатков 2го метода, ибо требует пересборки при каждом изменении в количестве используемых ф-ций.

PS: Не понимаю я в чем проблема сделать выкидывание мертвого кода из собираемого файла в компиляторе...
PPS: Не думаю что выучить make или cmake это дичайшая из проблем.