dcd или как его там

ну и пусть хочет - Олегу не нужно главный пакет собирать же, как я понял

Такой подход костылём попахивает

> workspace-d из-за этой строки не даёт автокомплит и переход на объявления А не бага ли это для dcomplete?

Ну... Не думаю

Да, это костыль, ибо "none" Does not generate an output file. This is useful for packages that are supposed to drag in other packages using "dependency" directives.

т.е. это такой официальный тип сборки. значит бага в комплиттере

или в том что ему грузит пути к сырцам

может он сам и неумеет по субпакетам шарить

т.е. это такой официальный тип сборки. значит бага в комплиттере

Компилятор тут каким боком?

а кто о нём говорит?

недопрочитал, сорян

и что значит баг в комплитере? этот способ работает для всех типов сборки кроме none, так как none запрещён намеренно

причина запрета none мне не ясна пока

ну так компилятор должен знать какую цель собирает, точнее это DUB ещё

если цель никакая то собирать нельзя

если цель неизвестная то просто убираешь строку и оно автодетектить пытается

причина запрета none мне не ясна пока

dub вообще никак не связан с автокомплитом

скоре всего, связан

dub вообще никак не связан с автокомплитом

dub может описать пути

как-то ведь автокомплит находит пакеты чтобы сырцы прочитать

а дальше уже dcd и иже с ними

автокомплит может анализировать dub.sdl или dub.json

автокомплит может анализировать dub.sdl или dub.json

дублирование функциональности

тут вопрос, а должен ли dub выдавать пути к субпакетам если цель none?

у dub есть инструменты, которые позволяют это делать и выдавать на выход всё что нужно

скорее всего он не сам анализирует а вызывает dub как библиотеку

скорее всего он не сам анализирует а вызывает dub как библиотеку

ну так так и есть

скорее всего он не сам анализирует а вызывает dub как библиотеку

скорее просто запускает dub с параметрами

скорее просто запускает dub с параметрами

нет, dub как библиотека используется

собственно вопрос в том почему все остальные targetType работают исправно, а none запрещён явно

ок, и эта либа не ковыряет субпакеты, если цель none. По мне так это повод для issue

+1

ну чтож... придётся костылить фейковую библиотеку

да чтож такое то...)

в одном из субпакетов copyFiles есть...

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

а это потому что автокомплит это почти что компиляция, как я понимаю

не не не

може там copyFiles а потом import(file) и какой-то парсинг например в миксин?

так вот пока всё это не сделаешь автокомплита не получится

помимо автокомплита dub ещё вызывается чтобы ошибки подсвечивать сразу

/me живёт с примитивным автодополнением слов в Geany и ему норм

тут да, по сути компиляция

до этого столкнулся с подобной проблемой, но там preBuild был

скрипт вызывался при каждом вызове проверки

автокомплит надо кэшировать и обновлять (непонятно когда)

этом не сам dub занимается...

вызывается какая-то функция "типа собрать, но не собирать"

ну да

так вот он исполняет всё, кроме того что кладёт результат в targetPath

все копирования файлов и pre и post скрипты

мне кажется это не правильно

правильно: может там потом import(file) и какой-то парсинг например в миксин?

хотели рефлексии? ешьте!)

правильно: может там потом import(file) и какой-то парсинг например в миксин?

да причём тут import(file) там вообще другое

там нужны пути статического импорта

а куда по итогу кладётся файл вообще не важно

нет, без парсинга всех миксинов из рандомных файлов невозможно автокомплит предоставить

в этих файлах может лежать генерируемый код

а для этого надо все приготовления сделать

копирование кладёт файлы в targetPath

всё, что до компиляции произвести будто компиляция будет

так вот targetPath никак на компиляцию не влияет

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

по всей видимости копирование делается просто "за компанию"

для копирования придётся отдельный скрипт писать...

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

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

> как менеджер пакетов хорош, но как система сборки не очень А в чём разница?

менеджер пакетов контролирует пакеты) зависимости разруливает, скачивает из репозитория

система сборки может отрабатывать разные случаи сборки

может быть я реально что-то не так понимаю как делается?

а смысл в пакете если его собрать никак нельзя?

а смысл в пакете если его собрать никак нельзя?

я про то что одинаково описывать пакет и процесс его сборки как-то не выходит

вот есть у меня проект, в нём много программ (4 программы для rpi, 1 на desktop)

они все используют общие типы данных, функции разные и тд — то есть библиотеки локальные

3 штуки

вот как мне этот проект описать и рулить им?

Программы реально разные? тогда это субпакеты должны быть

да, выполняют совершенно разные задачи

одна забирает данные от датчиков и отправляет в шину, другая рисует это на экране, другая обновление системы реализует, другая watchdog, будут ещё web интерфейс и modbus-slave

ну и вот описал я subPackage'ы разные

targetPath один на всех (папка build), туда должно всё складываться

gui использует доп файлы в виде ui и картинок, их тоже нужно в build класть

но вот чтобы все эти вещи связаны были в один проект он не может быть none

кстати dub не умеет platform для targetType

и targetPath

тоесть нельзя отдельно build-arm и build-x86 сделать

со сборкой +/- приятной под arm разобрался

нужно сделать отдельный скрипт, где ldc указать все нужные флаги и передать те что этому скрипту на вход идут

назвать например armldc2 и указывать его в качестве компилятора при сборке

хотел ещё номер сборки считать, но тоже не пойму как

кстати dub не умеет platform для targetType

И правильно делает

да почему же?

Потому что не указывается под какую платформу пакет - кроссплатформенные они как бы

многие другие поля умеют

некроссплатформенный код в версию заверни и оно при компиляции неверной платформы просто упадёт

теоретически проект мой может работать и на arm и на x86

Вот и верно. А targetType это просто библиотека там у тебя или исполняемый файл или сырцы

вот только чтобы одну из 4 программ попробовать запустить на arm я должен все пересобрать или руками их переложить в другое место