Как мне сделать конфигурацию в DUB, которая превращает несколько входных файлов D с основными функциями в несколько выходных исполняемых файлов?

Question

Я могу придумать по крайней мере несколько сценариев использования или сценариев для этого:

• Конфигурация "examples", которая создает несколько примеров программ.
• Проект с клиентской программой и хост-программой.
• Проект с одной основной программой и несколькими вспомогательными программами (например, gcc).

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

В качестве примера, у меня может быть такой макет проекта:

dub.json
.gitignore
source/common/foo.d               (Code called by all examples)
source/examples/simple_example.d  (Build input with main function)
source/examples/complex_example.d (Build input with main function)
source/examples/clever_example.d  (Build input with main function)
bin/simple_example.exe            (Output executable)
bin/complex_example.exe           (Output executable)
bin/clever_example.exe            (Output executable)

Другой проект может выглядеть так:

dub.json
.gitignore
source/common/netcode.d           (Code called by all programs)
source/common/logic.d             (Code called by all programs)
source/executables/host-daemon.d  (Does privileged things for the server)
source/executables/server.d       (Unprivileged network endpoint)
source/executables/client.d       (Queries the server)
bin/host-daemon                   (Output executable)
bin/server                        (Output executable)
bin/client                        (Output executable)

В любом проекте я хотел бы собрать все исполняемые файлы с помощью одного вызова DUB. В идеале, все это будет управляться из одного файла dub.json из-за взаимосвязанной природы входов и выходов.

Кажется, что subPackages могли бы сделать это, но управлять им из одного файла dub.json "вообще не рекомендуется":

Подкаталоги /component1 и /component2 затем содержат обычные пакеты и могут называться "mylib:component1" и "mylib:component2" из внешних проектов. Для ссылки на субпакеты в одном и том же репозитории используйте спецификатор версии "*".

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

Может ли DUB собрать несколько исполняемых файлов за один раз, как указано выше, и если да, то какой способ наиболее рекомендуется и почему?

Answer 1

Мне удалось сделать это с помощью конфигураций, без подпакетов.

Во-первых, вы ставите все свои основные функции перед versions спецификаторы.

Предположим, у вас есть 3 разных файла, каждый со своим основным.

один D:

....
versions(one)
void main() {
    ....
}

two.d:

....
versions(two)
void main() {
    ....
}

three.d:

....
versions(three)
void main() {
    ....
}

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

dub.sdl:

....
configuration "one" {
    versions "one"
    targetType "executable"
    targetName "one"
}

configuration "two" {
    versions "two"
    targetType "executable"
    targetName "two"
}

configuration "three" {
    versions "three"
    targetType "executable"
    targetName "three"
}

Если вы просто позвоните dub build, он будет использовать первую конфигурацию, но вы можете передать другую конфигурацию:

dub build --config=two

Answer 2

"Подпакеты предназначены для модуляции вашего пакета снаружи".

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

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