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

[Oleg N. Cher]

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

Я за выставление её наружу, заманглировав предварительно имя таким образом, чтобы не было возможности вызвать её из Оберона (а для Си - снабдить её префиксом "__"). Ну и в Оберон-интерфейсе она мелькать не будет.

Плюс необходимость ручной работы по разметке- не фонтан (я думал, там более продвинутая автоматика)...

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

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

Если сделать всё внутри SDCC, то никакой информации не будет нужно. Фрагменты нарезания будут самые атомарные. Браться будут по требованию. Лишнего не будет взято.

И мой (точнее стандартный) способ лишен тех проблем про которые говорит Витамин.

А в чём преимущество прогонять целый исходник столько раз, сколько там функций? Вы ведь никак не решаете проблему инклюдов, только предлагаете засорять исходник #ifdef'ами, усложняя его и портя стиль разработки. И как вы предлагаете решать проблему локальных (static) функций, про которую говорит Витамин?

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

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

Думаю что доработать Ofront проблем вообще никаких нет.

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

Я вообще сейчас знаете как делаю? Транслирую Ofront'ом, но всю Си-библиотеку веду ручками и ручками в неё переношу оттранслированные куски. Пока объёмы работы небольшие - такой вариант приемлем.

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

Ну как это проблемы просто нет? Ещё как есть проблема. Об этом прочитайте постами выше. Проблема в SDCC, который пихает весь исходник библиотеки без возможности смартлинковки, одним сегментом. Приходится делать библиотеку в виде кучи маленьких файлов. Вот проблема. Это не проблема только для тех, кто делает всё кусочками и вводит это в ранг религии. Но есть противоположная религия цельности.

И конечно решать данную проблему никто в здравом уме в этой теме не пойдёт, зачем, вдруг юродивый Oleg N. Cher когда-нить этим займётся, а мы подождём, куда нам спешить, и потом попользуемся плодами. Ведь давить инакомыслящих - гораздо более интересное занятие.

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

Vitamin, а как решить проблему двух зайцев: a) и чтобы static функция сидела в библиотеке отдельным куском; b) и чтобы вызывать её из других функций по её имени; c) и чтобы её нельзя было вызывать из некоторых более других функций по её имени, т.е. чтобы наружу это имя не светилось.

Мне нравится сама постановка задачи! Но средствами XDev (Oberon-Ofront-smartlib) она решаема автоматическим манглированием Си-имён. Т.е. из модуля Abc, написанного на Си, вызываются нелокальные конечно, но все функции модуля Abc. А вот из Оберон-модуля Cde нельзя вызвать static-функции модуля Abc, которые не экспортированы в интерфейс модуля.

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

Я думаю, после приведённого мною примера NewSupercode уже понятно как можно решать эту задачу средствами smartlib.