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

[Oleg N. Cher]

Это означает: не включаем в хедеры то, что там не нужно, не включаем в файлы исходного кода то что там ненужно.

Ага. Значит я, по-твоему, включаю в хедеры то, что мне не нужно и не включаю то, что нужно. Надо же. Сам понял чего сказал?

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

Не показываем конечному юзеру те ф-ции которые ему не нужны (скрываем реализацию служебных структур и частей кода).

Всё правильно, ненужное скрываем. Это есть инкапсуляция.

Я и Витамин уже 100500 раз это писали.

Вы не сказали ничего дельного по этому вопросу. Даже язык Си не требует помещения каждой функции в отдельный исходник. Ты же напираешь на необходимость это обязательно делать. Да, с SDCC по-другому пока и не сладить, но лучше бы ты задумался над тем как лучше сформулировать feature request разработчикам SDCC.

Ну что конкретно ты предлагаешь? И не дури мозг. Вовсе не "невключать то что ненужно включать то что нужно", а "помещать каждую функцию в отдельный файл". Ну хорошо. Будет в папке Lib не 44 файла, а 544. Легче кому от этого станет? Придётся имена всей этой тучи файлов хранить в мейк-файле (и постоянно его редактировать, дополняя новыми именами). Это что - удобно настолько, чтобы к этому стремиться? Нет, батенька. Это просто для тебя привычней. Ещё какие достоинства будут?

Я не нашел ни слова документации в репозитории как это собрать. Все бинарники находящиеся там на моем powerpc G5 не запускаются т.к. собраны под и386.

Угу, угу. Витамин тоже в глаза никогда не видел ни винды, ни i386, представляясь линухойдом. Пока не прокололся, приаттачив презентацию ppt.

Не могу рассматривать такой ответ иначе как дешёвую рисовку.

Вопрос без которого нельзя на вот то что ты написал ответить: ты каждый раз переписываешь библиотеки которые юзаются у тебя в zxdev? в смысле они каждый раз экспортируются по-новой в С-исходники и каждый раз собираются?

Да.

Но с некоторыми "но".

Библиотека, написанная на Обероне, собирается именно так, как ты сказал. Разрезание тоже работает, но с некоторыми ограничениями.

Поэтому исключительно для того чтобы юзать "умную линковку" используется полу-автоматическая генерация. Т.е. то, что нагенерил Ofront, ручками переносится в сишный исходник и редактируется для добавления "линий разреза". Иногда используется сишный препроцессор. Это для шика. Например, чтобы без перекомпиляции использовать разные опции работы библиотеки. С некоторыми ограничениями это можно юзать и из Оберона.

Наконец, чисто сишные библиотеки. Ну какой смысл резать их на сто кусочков? Чтобы подсластить жизнь утилите. Проклинаемый тобой оверхед - у тебя в голове, я уже писал, что авторазрезание даже на сто кусков занимает меньше секунды.

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

Если так то мой подход неверный. Если нет - не вижу проблемы доработать после экспорта напильником то что получилось для:
1) удобочитаемости и нормальной структурированности

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

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

2) исключению необходимости резать это все каждый раз каждую сборку.

Пользователь не пересобирает библиотек. Как правило, это делает разработчик библиотек. Даже если пользователь пересобирает библиотеку - он делает это одним нажатием кнопки. Голова не болит. Разве что батничек подправить. Но в нём нету ста имён кусков файлов исходника.

3) скрытию системных и внутренних структур и ф-ций от конечного пользователя.

Я повторюсь. Пользователь оперирует даже не хедерами. Интерфейсами. В них нет ничего лишнего. Но может быть много полезного, вплоть до комментариев, созданных с помощью автодокументирования (как в Javadoc).

4) ускорению сборки в силу пп 2 и 3.

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

Слушай, у меня ужасное подозрение. Это твоя идея фикс. Грамотный разработчик зрит в корень. И уж точно усмотрит более приоритетные направления разработки. А их сотни. А что предлагаешь ты? Чепуху, вобщем.

PS: Ответь мне, ты сам-то что пересмотрел в своих привычках за время треда?

Ещё более укрепился в своём почитании библейского принципа "око за око, зуб за зуб", и знаешь, правило верное - не подводит.

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

А ты сталкивался с тем, что кто-то, рьяно рвущийся дать тебе совет, не вполне понимает что именно ты делаешь? А, соответственно, и не заслуживает более достойного ответа. А другие на меня и не в обиде. За это я спокоен. И благодарен за хорошие советы. С этим всё в порядке.

Я с этими скриптами и разбиением вожусь уже не один год. А, по-твоему, адекватный человек будет давать советы по усовершенствованию продукта, который он не то что юзает ежедневно, а вообще даже не смотрел?

Так, риторика.