OberonCore

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

CompileSubs родился в итоге работы международного центра, в чём-то я с вами соглашусь, что это излишняя автоматизация, однако она форсировала обсуждение роли директории как компонента системы Блэкбокс, внесла ясность, что не надо городить много подсистем в одну папку. И на мой взгляд - это хорошо. Чем яснее требования к пакетам расширений, тем лучше.
Расширение расположено в директории, в ней есть Quick-Start, Compile-List, и было бы здорово, чтобы оно собиралось командой DevCompiler.CompileSubs
Однако не обязательно. Но внутри Блэкбокса это должно выполняться, как пример компонентности, как это было задумано изначально.

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

вообще-то ровно так оно и происходит: подсистема Sql динамически грузит драйвер поддержки конкретной ДБ. зачем этому драйверу в свою очередь делать ещё одну прослойку, когда он тоже уже импортирует модуль, который динамически же грузит .so/.dll?

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

p.s.: единственный, пожалуй, случай, когда такой финт может получиться — это модуль импорта из .so/.dll. если он другие модули не импортирует, то соберётся, хоть оно и бессмысленно. надо бы защиту от этого прикрутить, спасибо за идею.

кстати, мне чтобы такую защиту прикрутить — надо сходить в DevCompiler, и вставить туда одну проверку. а парзер менять не надо. сразу стоило сделать, конечно, но я не подумал. виноват.

p.p.s.: ваш вариант с изменением парзера, правда, позволяет защититься от случая, когда исходники модулей лежат по произвольным путям. только я не очень понимаю, как в вашем случае компилятор будет проверять допустимость той или иной архитектуры. глядя в `Dialogs.platform`? так это ровно то же самое глобальное состояние. и вдобавок не позволяет кросс-компилировать. или я что-то не так понял?

Потому что есть платформенно-независимая часть драйвера, и есть зависимая от платформы, поэтому ещё один слой. Это ок.

да явно неправильно понимаете, потому что утверждаете, что "не позволяет кросс-компилировать"
в Блэкбоксе изначально есть возможность компилировать для i386 под любую ОС, поэтому нет необходимости в каких-бы то ни было инструментов для кросс-компиляции, за исключением того, что модули не должны лежать в одном Host, поэтому Host и был убран, чтобы эту возможность обеспечить. Поэтому возвращение Host как раз совсем не входит в планы. Мы специально его убирали для кросс-разработки.

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

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

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

p.s.: просто у меня есть вполне неиллюзорный шанс возникновения ещё и RISC-архитектуры, например, поэтому я сразу думаю о том, что я буду делать, когда настанут зимни холода. и у меня всё изначально затачивалось именно на мультиархитектурность в плане поддержки разных CPU (и даже разных конфигураций среды под разные CPU), а не только разных осей для одного CPU в одном его режиме. да, там не всё ещё доделано (динамическая загрузка правильных бэкэндов, например), но пилилось изначально с прицелом именно на это. собственно, я CPfront засунул, а потом вынул обратно как раз потому, что его надо правильно интегрировать вместо хранения отдельной подсистемой: как новую target.

Да, собрать то можно всё из репозитория под любую ОС, но не нужно. Поэтому и делается выборка модулей.