так напиши скрипт и положи его в корень, в чём проблема то?

targetPath? А с ним что не так?

1 скрипт для подмены ldc, другой скрипт копирования доп файлов после сборки, ещё скрипт для того чтобы можно было спокойно собирать под 2 архитектуры в разные папки

определение целевой платформы за рамками DUB просто

как раз таки нет

таки да

dub определяет целевую платформу

я про тип процессора

не про targetType

причём достаточно хитро: создаёт файл со всеми возможными version и собирает его указанным компилятором

файл этот уже возвращает json с платформой

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

ну дык всё верно же. тут просто компилятор снаружи как бы а DUB урвонем ниже подсовывает всё что надо для сборки, так можно считать

что, собственно, успешно указывается в dub.sdl

1 скрипт для подмены ldc, другой скрипт копирования доп файлов после сборки, ещё скрипт для того чтобы можно было спокойно собирать под 2 архитектуры в разные папки

с этим то что делать?

я щитаю это правильным потому что иначе бы мы щас имели кучу 32битных интеловых пакетов и кучу 64битных

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

DUB по документации не является системой сборки, он пакетный менеджер. Если уж буквоедствовать

ну вот

но для чего-то туда добавили эту возможность

это как travis-ci использовать - он СНАРУЖИ дёргает DUB с разными опциями и собирает таким образом разными компиляторами один и тот же пакет

но для чего-то туда добавили эту возможность

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

был наверно ещё вариант генерить через DUB Makefile - тебе хочется такого?)

ну а разница?

в любом случае в dub.sdl не прописать всего

кстати, вот этот мужик https://github.com/JinShil ковыряет D на голом ARM

и что оно тогда сгенерит?

и что оно тогда сгенерит?

то что попросишь внешними ключами

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

ну так это ничем не отличается от сборки самим dub'ом

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

я смотрю на любые другие языки и вижу сборки cmake, meson и тд

так что тебе надо скрипт пилить который будёт 4 раза dub дёргать. ожно даже Makefile написать, так проще если синтаксис знаешь

ты качаешь пакет и запускаешь одну команду без параметров, чтобы всё собрать

хотя бы в default'ном режиме

я смотрю на любые другие языки и вижу сборки cmake, meson и тд

Поговорка про миллионы мух же.

не знаю такой

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

не знаю такой

http://lurkmore.to/%D0%9C%D0%B8%D0%BB%D0%BB%D0%B8%D0%BE%D0%BD%D1%8B_%D0%BD%D0%B5_%D0%BC%D0%BE%D0%B3%D1%83%D1%82_%D0%BE%D1%88%D0%B8%D0%B1%D0%B0%D1%82%D1%8C%D1%81%D1%8F

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

Но ведь есть cmake!

для этого

ну или meson

угу

а я бы просто Makefile написал. clean там стандартный, install даже может. 6 строчек

и работало бы и в линуксе и в винде оно

Видимо так и надо делать

Но тогда зачем в dub копирования и pre и post команды?

Чтобы для простых случаев не нужен был cmake?

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

думаю оно для этого

а пост это чтобы кучу бинарников распихать результирующих

ну короч на всякий случай. но общая идея (как я лично понял) именно вот как изложил - dub это не система сборки.

Вот в этом я и пытался удостовериться)

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

вот travis-ci не юзал? там как раз есть выбор компиляторов и ОС, и он именно через переменные сделан, не надо прописывать в dub ничего для этого. Оттуда я и делаю вывод.

и как я понимаю, выбор компилятора это не только выбор компилятора, это ещё и выбор целевой архитектуры

При создании треда сокеты копируются в него? Их надо закрывать и в родителе и в детеныше получается?

сокет это int или Socket?

Socket убивает внутренний posix socket после выхода, int это просто int

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

ну не то чтобы совсем тривиальных, но таки да, слабоват.

сокет это int или Socket?

Socket

У меня накапливаются какие-то хрени массово в lsof

это же класс, как его в тред расшарить?

как треды плодишь?

socks5d 9394 ubuntu 325u sock 0,7 0t0 684457 can't identify protocol socks5d 9394 ubuntu 327u sock 0,7 0t0 686213 can't identify protocol socks5d 9394 ubuntu 329u sock 0,7 0t0 686235 can't identify protocol

Ну как обычно new Thread({ // work with mySocket here });

так это кооперативная многозадачность же?

или я путаю?

Не, это обычный тред

Системный

Который почти как процесс

ан у вот, короч сокет номер 1 закроется и закроет соединение, потому что он о своей "копии" знать не будет, он же не shared. Второй сокет при закрытии вызовет ошибку.

потому что тоже попробует закрыться

теперь когда у нас есть event loop из vibe нет нужды треды плодить ручками имхо

такие которые переменные снаружи шатают.

(я предполагаю что пишется какой-то сервер многопоточный)

теперь когда у нас есть event loop из vibe нет нужды треды плодить ручками имхо

Так он не работает)

отлично работает

опиши задачу

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

во, только что такую задачу решали с моей библиотекой)

короче очень плохо что сокет так вот передаётся. что сервер должен делать?

Передавать данные. Один тред работает в виде сервера, принимает клиентское подключение и работает с ним в созданном треде

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

не не, ты не как работает описывай, а какая задача стоит

:)

ну без деталей, конечно

Задача такая ровно и стоит

Прокси сервер

а ну то есть дальше пойдёт куда-то исходящее соединение?

да

а исходящих соединений может быть столько сколько входящих? они кэшируются? в пуле?

В рожденном треде открывается сокет к целевому клиенту и гоняются данные между входящим и имходящим сокетом

ага

а исходящих соединений может быть столько сколько входящих? они кэшируются? в пуле?

Не кешируются, без пула. Исходящих столько же сколько входящих

ага жорошо

Как только или входящее или исходящее обрывается, я сразу делаю .close() на обоих сокетах и тред заканчивается