Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
В GCC 10 какой-то новый атрибут access появился, чтоб более строго что-то там гарантировать:
The access attribute enables the detection of invalid or unsafe accesses by functions to which they apply or their callers, as well as write-only accesses to objects that are never read from. Such accesses may be diagnosed by warnings such as -Wstringop-overflow, -Wuninitialized, -Wunused, and others.
The access attribute specifies that a function to whose by-reference arguments the attribute applies accesses the referenced object according to access-mode. The access-mode argument is required and must be one of three names: read_only, read_write, or write_only. The remaining two are positional arguments.
The required ref-index positional argument denotes a function argument of pointer (or in C++, reference) type that is subject to the access. The same pointer argument can be referenced by at most one distinct access attribute.
The optional size-index positional argument denotes a function argument of integer type that specifies the maximum size of the access. The size is the number of elements of the type referenced by ref-index, or the number of bytes when the pointer type is void*. When no size-index argument is specified, the pointer argument must be either null or point to a space that is suitably aligned and large for at least one object of the referenced type (this implies that a past-the-end pointer is not a valid argument). The actual size of the access may be less but it must not be more.
Так-то теперь этой хуйней можно сказать, что такая-то говнофункция, которая если принимает указатель на char то она имеет право только 4 байтика туда записать, а читать с того массива вообще права никакого не имеет. Но это хуйня всё, надо еще чтоб можно было более ебанутые контракты впендюривать, типа если второй аргумент в функции это true то тогда функция по четным элементам такого-то массива (точнее смещений указателя, нувыпонели) байтики может только записывать, а по нечетным - только читать, а если там false то по четным только читать, по нечетным только записывать. И чтоб на основе такой хуйни оно б еще что-то там могло оптимизировать.
А оно на основе этого SAL может что-то заоптимизировать? Ну типа если есть некая функция, которая записывает 8 байтиков по такому-то указателю(и больше нихуя не имеет никаких сайд-эффектв), а потом за ней идет другая функция, которая тоже записывает 8 байтиков по тому же указателю (не читая того, что там было) и если это описано в этих контрактах, то может ли их компилятор нафиг выбросить первую функцию т.к. ее вызов ни на что не влияет?
Насколько помню, они SAL пилили исключительно для статического анализа, чтобы подстраховаться от переполнений буфера (да, аргументы size и ptr там тоже можно было связать), неинициализированных переменных (in и inout будут на это ругаться, а out нет), уровня IRQL в драйверах (чтобы не позвать какой-нибудь malloc из прерывания) и т.п..
А для самого конпелятора это вроде просто макросы-пустышки.
Тогда можно ALSC из Frama-C взять. https://frama-c.com/html/acsl.html
Эту хуйню можно потом через Why3 в язык для SMT солверов экстрактить. И даже в Coq, чтоб руками доказывать.
да майкрософт анскильные лалки по сравнению. у них разделение по языкам в солюшене на уровне проектов. заедушно
а у эппла можно в одном исходнике мешать обжектив, няшную и кресты, красиво вызывая одно из другого, а в соседнем сырце на Свифте вызывать продукты этой жизнедеятельности
Ну няшную с крестами можно и у MS мешать.
Виндузятник из крестов трогает няшный w32api примерно как яблоник трогает какой нить core foundation, наверное
Смотря какое определение слову "проект". Я из контекста понял это как поебень, которая в вижуалстудиевской говноIDE присутствует. https://professorweb.ru/my/csharp/charp_theory/level2/files/img4510.png - вот когда надо какую-то поебень мышкой создавать, и там создается какая-то говнина в привязанной к конкретной IDE формате.
Да, и кастомные скрипты ещё. Но их реально проще выписать и переписать на чём-то другом. Особенно с учётом того, что студия все настройки по 4 раза повторяет если через гуйню править.
А потом ты видишь, что какая-то опция включена в 5 ворециях сборки из 8 и думаешь -- они это специально или так получилось? Комментов же гуйня не даёт написать.
Что-нибудь адекватное из императивных языков. Ибо сам cmake по сути и является императивным DSL, нахуяренным на коленке. Он даже не пытается косить под декларативность.
*впрочем, я послал его нахуй год-два-три назад, когда оказалось что сишку надо компилить через рулы для плюсов, а компилятор самому выставлять через классическую переменную окружения (СС вроде)
и еще отсутствием внятной документации. это заебись что у вас по странице на каждую функцию, но как мне их блядь компоновать, чтобы получить желаемый результат? "посмотрите чужие примеры в интернете"
Не, ну это понятно, IDE могут хранить всякие там настройки кодстайла, идентации для конкретно этого вот "проекта" и проч, только эта хуита к задаче сборки не имеет никакого отношения. Кстати такая вот хрень есть https://editorconfig.org/ - чтоб разные IDE могли через один конфиг работать могли.
Самое главное -- макросы, инклуды, прочие опции конпелятора которые влияют на код. Вот это вот самое нужное в "проекте". Без этой инфы проще взять "ноутпад++" и не заморачиваться с "ИДЕ".
> а почему херня, если мой код написан только под винду?
Потому что тогда получается так, что только на винде его и можно удобно редактировать, и только вот в этой конкретной IDE, а бывают ведь и другие ОС, и еще можно кросскомпилировать и удаленно отлаживать что-то, пользуясь при этом не виндой.
>На других OS ты не соберешь мой код, так как там нет ни visual c, ни виндовых SDK
Будто бы есть что-то хорошее в том, что код под винду собирается только под виндой.
> Ты кстати в своем Makefile вполне можешь завязаться на наличие perl, bash, sed, awk, и удачи тебе в сборке это под другую ОС
perl, bash, sed, awk в винде можно из msys2 взять, с этим как-то попроще, чем если какую-то хуйню, наглухо завязанную на виндовый компилятор и SDK пытаться собирать в прыщах.
ты можешь дать какое-то рациональное объяснение своему негодованию?)
типа разработчик ФАРа должен был обязательно сделать его кроссплатформенным, чтобы лялиховоды вкусили плоды его работ? а не сильно ли это самонадеянно звучит?
а так же MAPI есть только под винду, WDM есть только под винду, netfilter есть только под Linux, DirectX есть только под винду, а netgraph есть только под BSD
Очевидно, все эти технологии не нужны, ведь они не кросс-платформены
> Это плагин в фару для посылки говна через MAPI (понятия не имею, кому это нужно).
> MAPI есть только под винду, и FAR есть толкьо под винду.
> На кой чорт тут вообще думать про другие ос?
А на кой черт надо так писать свои IDE и SDK, что собирать под винду эту хуиту возможно только из винды? Если у меня в контроллере некая OS, мне не надо почему-то в контроллер засовывать компилятор чтоб собрать под эту микроконтроллерную OS некую херню.
Какие различия в API разных OS мешают сделать возможным компиляцию для платформы X из платформы Y? На ум приходит разве что какая-то херня с именами файлов и путями. Компилятору ведь много не надо для работы - вполне достаточно выделять память, читать файлы, писать в файлы.
На самом деле, виндовые SDK и WDK даже из винды юзать противно. Они там конфликтуют друг с другом, ломают друг друга при неправильном порядке установки, читают какую-то хуету из реестра и т.п.
В теории я, конечно, должен юзать последнюю версию и течь, а остальные просто снести. Но на практике это не работает.
Какой смысл делать кросс компиляцию, тратить вермя на портирование SDK, разбираться с особенностями компиляторов (к примеру, экспорировать функции у линкера из вижала и gcc нужно по разному) если твой код все равно не будет работать на других ос?
> если твой код все равно не будет работать на других ос?
Почему у тебя "будет или не будет некий код работать под другими ОС" как-то увязывается с тем, "можно или нельзя компилировать этот код из некоторой-ОС под единственую-ОС-в-которой-код-будет-работать" ? Как это вообще соотносится?
Я смутню помню, что там заголовок тома показывают драйверам файловых систем, и говорят "to je tvoje hovinko?", и кто первый согласится -- тот и прикручивает
Поверх него драйвер партиций (который там понимает MBR, GPT, вот это всё), потом volumgr (который отличает софтварные рейды -- dynamic вот это всё), и потом файлуха
> Потому что не существует смысла тратить время на то, что бы делать код компилируемым на ненужных мне ОС.
А почему возникла ситуация, что на это надо специально тратить время? Вот например взять некую ОС под микроконтроллеры, пусть это например будет RetroBSD, она предоставляет POSIX API и программное окружение unix и из нее даже можно компилировать код под нее же, притом работает она на микроконтроллере Microchip PIC32 с 128 килобайтами памяти и 512 килобайтами Flash: https://habr.com/ru/post/143679/
Почему-то там не возникало ситуации, что надо тратить время чтоб что-то под эту ОС собирать не из-под нее же. Почему? Может быть потому, что для RetroBSD никто не вендорлочил SDK и тулкит таким образом? Почему на винде такое возникло? Нахуя было вендорлочить? Хорошо ли это?
>А почему возникла ситуация, что на это надо специально тратить время?
Потому что не все компиляторы совместимы друг с другом, увы.
SDK для RetroBSD специально была сделана портируемой (и наверняка не на все существующие ОС) чтобы делать кросс-компиляцию, потому что на самом RetroBSD собирать не удобно.
Попробуй собрать ядро Linux на RetroBSD, или даже на OpenBSD (без GNU bitutils, gnu make, баша (там ksh), и гцц: шлангом и бздёвыми тулами с pmake). Скорее всего тебя ожидает сюрприз.
> POSIX API
Ты можешь использовать стандартную библиотеку си уровня C89 (VC не поддерживает c99), и собираться примерно одинаково всеми компиялторами, но далеко ты так не уедешь.
POSIX внезапно тоже покрывает далеко не все: начиная от сискола signal() (который в BSD и SystemV ведет себя по разному) и заканчивая epoll/kqueue в разных *nix нас ждут разные API.
Именно потому у любого крупнгого проекта есть огромные ОС-специфичные куски.
Тоже касается и сборки.
Неужели я могу просто так собрать clangом любую линуксовую и GNUшную тулу?
>Почему на винде такое возникло? Нахуя было вендорлочить?
SDK -- довольно крупная штука, и поддерживать её совместимость с разными компиляторами и OS это большая работа.
Смотри, Linux на Clang тоже не очень легко переносится
> Потому что не все компиляторы совместимы друг с другом, увы.
Как это мешает сделать кросскомпиляцию?
> Тоже касается и сборки.
С каких хуёв процесс сборки надо гвоздями прибивать к конкретной ОС? Компилятору нужно лишь читать из файла, писать в файл и аллоцировать/освобождать память, и всё, нихуя ничего платформоспецифичного компилятору делать не надо. Компилятору не нужно быть завязанным на какую-то хуйню вроде COM или реестр виндовса для компиляции чего-либо.
> SDK -- довольно крупная штука, и поддерживать её совместимость с разными компиляторами и OS это большая работа.
Что именно там ОС-специфичного? Повторяю, компилятору достаточно чтения файлов, запись в файлы, выделение памяти через malloc и освобождение через free.
> Смотри, Linux на Clang тоже не очень легко переносится
Это ты вообще в другую оперу полез. Я говорю не о том, чтоб хер пойми что хер пойми каким компилятором собиралось, а чтоб компилятор X который умеет компилировать код только !!ДЛЯ!! операционки W мог это делать не только в операционке W, а вообще в любой операционке, где есть возможность читать писать файлы и выделять память на хипе. С хрена ли ты приплел тот факт, что у разных компиляторов разные расширения?
>Как это мешает сделать кросскомпиляцию?
С таких, что ты не можешь скомпилировать любой код любым компилятором.
Ты не можешь взять Clang, и скомпилировать им Linux ядро "из коробки", не сделав предварительно телодвижений.
>С каких хуёв процесс сборки надо гвоздями прибивать к конкретной ОС?
Процесс сборки может быть прибит:
* к утилитам GNU (которых нет во многих ОС, пока ты их туда не поставишь)
* компилятору, которого нет на другой ОС
>Повторяю, компилятору достаточно чтения файлов
Сборка проекта состоит не только из компиляции .c файлов в объекты с последующей линковкой, но еще и хуевой кучи всего: от компиляции ресурсов, до генерации лексеров и парсеров.
> С таких, что ты не можешь скомпилировать любой код любым компилятором.
Да. И какое это имеет отношение к вопросу о том, почему я не могу код специально для MSVC компилировать в MSVC который работает не в винде?
> Процесс сборки может быть прибит:
> * к утилитам GNU (которых нет во многих ОС, пока ты их туда не поставишь)
Эти утилиты непереносимы (вендорлокнуты)? Ну типа, может они к systemd привязаны, и без systemd они не запускаются?
> Сборка проекта состоит не только из компиляции .c файлов в объекты с последующей линковкой, но еще и хуевой кучи всего: от компиляции ресурсов, до генерации лексеров и парсеров.
Что в этом платформоспецифичного?
> В смысле ты спрашиваешь меня, почему VisualC++ не портировали под Linux, чтобы ты там мог зачем-то собирать код под Win32API?
>Эти утилиты непереносимы (вендорлокнуты)?
shell и make это части операционной системы (во всяком случае, в bsd). Тот факт, что приходится рядом с ними ставить еще и их GNUшные аналоги говорит нам о том, что для сборки проекта недостаточно портировать компилятор: нужно портировать и другие утилиты тоже.
Теперь смотрим, какие утилиты нужны винде:
>Что в этом платформоспецифичного?
В SDK есть .bat файлы, которые не работают на *nix по причине отсутствия там cmd.exe.
В SDK есть утилиты, использующие API операционки.
Компилятор ресурсов ``rc.exe`` импортирует user32.dll и kernel32.dll.
Наконец сам компилятор файл "cl.exe" импортирует следующие dll:
* ole32.dll
* kernel32.dll
* MSVCP140.dll (это как раз рантайм)
* ADVAPI32.dll
>Бинго!
Итого:
Чтобы портировать WinSDK и VisualC++ на Linux, там придется:
* Убрать завязку на наличие cmd.exe из SDK
* Убрать завязки на win32API (сделав свой слой абстракции, где этот функционал реализован поверх линуксовых сисколов)
Звучит как "дохуя работы", а какой в этом практический смысл я так и не понял.
Зачем собирать что-то для виндуоса на линуксе?
Ну и наверняка можно и из FreeBSD под Solaris, и из Solaris под FreeBSD, но есть шанс напороться на хуевый сборочный скрипт, который тебе всю малину испортит.
Yup, кажется уже была такая дискуссия про std::embed или что-то такое. Ебаться с тем чтобы превратить гоатсе в массив байт тупо для того чтобы поставить его на десктоп юзеру - дело такое, мучаешься час, а смеешься только пять минут.
> В смысле ты спрашиваешь меня, почему VisualC++ не портировали под Linux, чтобы ты там мог зачем-то собирать код под Win32API?
Вообще, если внимательно перечитать сообщение https://govnokod.ru/27294#comment615192 то я указывал не только на проблему сборки для "проектов", вендорлокнутых на непереносимый тулчейн (тулчейн, который запускается только на винде), но и на проблемы что некая IDE хранит некую хуйню:
> "Самое главное -- макросы, инклуды, прочие опции конпелятора которые влияют на код. Вот это вот самое нужное в "проекте". Без этой инфы проще взять "ноутпад++" и не заморачиваться с "ИДЕ"."
которая делает более удобным редактирование что-то в этом "проекте", и эта хуйня работает только в этой ОС только в этой "ИДЕ", и извольте компилировать это только на винде, билдсерверы с прыщами тут не катят.
Не ну мс начало понемногу чесаться последние годы. Научили конпелятор в докере работать, дотнетом под прыщи занялись официально, wsl, vscode опять же...
Ну оно там ещё за каким-то хуем читает всякие параметры компа иногда. Из-за этого потом лямбды по-другому называются и бинарь получается немного другой из тех же самых исходников...
Потому что кресты паразитируют на сишном линкере и ей надо дать какое-то имя. При этом хочется какое-то более-менее стабильное имя, чтобы оно каждую конпеляцию не менялось. Но чтобы оно никогда не пересекалось с другими файлами.
Мне то похуй на имя лямбды, лишь бы оно не плавало в зависимости от компа, на котором собирают... А то собираешь на разных компах и получается разный бинарь, байтики не сходятся.
Ну вот скинул я тебе драйвер. Он подписан майкрософтом, вся хуйня.
Но ты мне не доверяешь и боишься его запускать. Тогда я даю тебе исходники. Ты их читаешь и собираешь... но получается какая-то другая хуйня, в которой весь код перемешан потому что лямбды по-другому называются. А запустить свой собранный драйвер ты толком не можешь т.к. подписать тебе его нечем. В итоге ты ни то ни другой юзать не можешь.
Тут-то ты и задумываешься, как было бы заебись, если бы бинарь всегда собирался одинаково.
У дебиана немного другая история, но суть примерно та же. Если много чуваков соберёт исходники и убедится, что в репе дебиана лежит точно такой же бинарь, то доверие к репе будет намного выше. И всем остальным не придётся играть в гентушков.
Ну вот крестам свой линкер надо было делать, а не на сишном паразитировать, имхо.
А так получается, что с одной стороны анонимная хуйня не должна торчать из своего объектника. А с другой стороны мёржить одинаковый код из хедеров то хочется, поэтому она не совсем приватная, comdat по сути.
Вот и начинается ёбля с тем как мёржить foo и foo и при этом не мёржить foo и foo.
A problem occurred evaluating settings 'gradletest'.
> Could not find method allprojects() for arguments [settings_9zza4tw75g6pjlonpz6j4n86b$_run_closure1@126a1f8e] on settings 'gradletest' of type org.gradle.initialization.DefaultSettings.
у тебя есть бинарь который раздать по сети 30 минут и сорцы которые компилировать 30 минут
ты предлагаешь его сначала собрать, потом раздать = 60 минут
я предлагаю параллельно раздать и собрать чтобы потом каждая машина смогла сверить sha бинарника и того чтобы собралось = 30 минут, компилируется только на одной машине которая зарепортит sha
Ну обычно сборка занимает куда больше времени, чем передача по сети, не?
идею я понял, но если Борманд утверждает, что в зависимости от машины у тебя будут разные бинари, то получается,что и собирать их придется в виртуалке?
> Ну ты согласен, что это много работы: отпилить всё от Win32API?
Не надо было его припиливать туда.
> Ну блин, мне тоже не нравится, что винда не POSIX. Но с этим уже ничего не сделаешь.
Для компиляции никакой POSIX не нужен. Компиляция - чтение файлов, запись в файлы, выделение и освобождения памяти. Это можно и на условной DOS делать, если убрать ебнутые ограничения на имена файлов.
> А как делать многопроцесную компиляцию? -j4 как сделать?
"-j4" не юзает никаких pthread-ов или чего-то такого. Это просто означает, что одновременно можно запускать 4 процесса компилятора/линкера/еще-какой-то-хуйни.
Ну то есть даже такую простую штуку, как компиляцию в несколько потоков (или процессов, называй как хочешь) нельзя сделать без ос-специфичного кода?
Выходит, для портирования компилятора между прыщами и пиндой придется делать разный код.
И такого, я уверен, дофига: "за бесплатно" портировать не получится.
Алсо, винда же это не просто ядро, это еще туева хуча сервисов.
Захочешь ты там в SDK свой .exeшник подписать например, и тебе понадобится доступ к виндовому CryptoAPI, потому что у пользователя там лежит сертификат и ключ (в отличие от линуксов, где "openssl" это просто сторонняя тула, в винде это часть системы)
>Какие сложности у тебя возникнут с написание общей обертки под разные ОС
Любой код увеличивает сложность системы. Не стоит добавлять код, если он не решает никакую полезную задачу.
Задача "компилировать виндовый софт под линуксом" полезной не является к сожалению, потому что у нас пока нету ни одного реального примера такого желания от разработчика под windows.
>вызывать несколько экземпляров компилятора параллельно - задача сборочных скриптов
То есть нам еще нужно портировать и какие-то сборочные утилиты, и написать этот код в них?
>Приведи реальный пример
Ну вот нет кросс-платформенного запуска процессов.
> Задача "компилировать виндовый софт под линуксом" полезной не является к сожалению, потому что у нас пока нету ни одного реального примера такого желания от разработчика под windows.
> для работы с http у винды есть API, использующее настройки системы (прокси, аутентификацию, итд): все это придется переписывать
Хождение по http и всякие криптоапи - это уже не компилятор, а какая-то вспомогательная херня. Нехер было такую дикую поебень городить. Мне для компиляции хуйни через GCC не нужно никакое криптоапи и никакой http
и тут тебя будет ждать сюрприз с обработкой аргументов.
В линуксах у тебя чуть ли не в сисколе есть argv, а в винде это строка, и их нужно правильно склеить:)
А еще ты захочешь наверное чтобы новый процесс наследовал от тебя какие-то дескрипторы, или чтобы его завершения можно было ожидать (типа wait()), или проложить с ним какой-то pipe, чтобы общаться.. и все это нифига не портабельно на винду без кастомного кода
> А еще ты захочешь наверное чтобы новый процесс наследовал от тебя какие-то дескрипторы, или чтобы его завершения можно было ожидать (типа wait()), или проложить с ним какой-то pipe, чтобы общаться.. и все это нифига не портабельно на винду без кастомного кода
> В смысле зачем мне ожидать завершения четырех процессов компилятора?
Это уже проблема не компилятора. Это проблема той штуки, которая их (процессы компилятора) запускает. И в самом компиляторе с этим ничего делать не надо.
И вообще, зачем так ограничивать себя, давай еще системы распределенной компиляции расмотрим, типа каких-нибудь distcc, под винды есть схожая херня, например Incredibuild. Вот там непереносимой хуйни будет куда больше.
И кстати да, сборочные скрипты вполне можно сделать непереносимыми. Например я однажды кросскомпилировал хуйню под ARM на своём x86-64 компе, и там была такая херня в этих сборочных скриптах, которая компилировала некий бинарник под target(в данном случае ARM) и его пыталась запустить. Нахуя? Чтобы узнать, вверх или вниз растет стек для того таргета, под который мы собираем хуйню. Разве не охуенно?
Концептуальное отличие заключается в том, что "проект" это какая-то сущность, прибитая гвоздями к какой-то среде разработки, а сборочный скрипт это просто хуета, которая собирает программу, и ей срать на всякие там вижуальные студии и прочую поеботу.
Аргументы можно таскать в виде туплы, которая параметризована тайплистом в котором содержатся различные утверждения о её полях. Новые утверждения можно навешивать только проверив их на входе. Ненужные утверждения можно выкинуть через шаблонный оператор преобразования типа.
Функция аналогичным образом описывает свой контракт на входе. Если тупла не кастанулась -- значит каких-то утверждений не хватило.
З.Ы. Что-то я боюсь PoC этой хуйни пилить, как бы дьявола не призвать.
Если пойти дальше, можно описывать теоремы как туплу с оператором преобразования типа, который конпелируется только если входные условия выполнены и возвращает туплу с какими-то новыми утверждениями. Ну и в его реализации можно писать пруф, пользуясь какими-то другими теоремами и аксиомами.
Ты пишешь в аннотации на каких IRQL может работать твоя функция. А статический анализатор смотрит, что ты не вызываешь что-то, что помечено более низким уровнем.
Я имел ввиду функции из DDK/SDK.
Хорошо, если так.
Мечтаю о таком для джвы, чтобы например функции с пометкой @Slow нельзя было вызвать из треда, обрабатывающего гуйные события (функции с пометкой @EDT, например)
j123123 # 0
6oHo6o # 0 ⇈
void*, int
можно было сказать, что первый парамтер есть указатель на такую-то структуру, если второй равен такой-то конгстанте
j123123 # 0 ⇈
guest # 0 ⇈
bormand # 0
j123123 # 0 ⇈
bormand # 0 ⇈
А для самого конпелятора это вроде просто макросы-пустышки.
j123123 # 0 ⇈
Эту хуйню можно потом через Why3 в язык для SMT солверов экстрактить. И даже в Coq, чтоб руками доказывать.
6oHo6o # 0 ⇈
Придумать новый язык с такой типизацией, как нам нравится, но обратно совместимый с сями, и транспилер сделать из него в си?
j123123 # 0 ⇈
bormand # 0 ⇈
j123123 # 0 ⇈
bormand # 0 ⇈
6oHo6o # 0 ⇈
А кресты и objc изначально превращали код в си (хотя про кресты я не уверен). Сейчас конечно конечно уже нет.
Кстати, С++ не полностью обратно совместим с няшной, а вот обж вроде как полностью.
Desktop # 0 ⇈
- мм, простота и понятность C++, помноженная на лаконичность и выразительность ObjC, что может быть лучше
bormand # 0 ⇈
Объективное крестоговно/CLI. То же самое, но с удобством управления ресурсами в C#.
К сожалению его почему-то не пильнули.
Desktop # 0 ⇈
booratihno # 0 ⇈
Desktop # 0 ⇈
а у эппла можно в одном исходнике мешать обжектив, няшную и кресты, красиво вызывая одно из другого, а в соседнем сырце на Свифте вызывать продукты этой жизнедеятельности
booratihno # 0 ⇈
Виндузятник из крестов трогает няшный w32api примерно как яблоник трогает какой нить core foundation, наверное
Desktop # 0 ⇈
booratihno # 0 ⇈
j123123 # 0 ⇈
У меня никаких "проектов" и "солюшенов" нет, я просто пишу сборочный скрипт и компилирую что угодно с чем угодно.
booratihno # 0 ⇈
j123123 # 0 ⇈
booratihno # 0 ⇈
Desktop # 0 ⇈
j123123 # 0 ⇈
bormand # 0 ⇈
booratihno # 0 ⇈
алсо, его можно собирать из командной строки (но если у тебя сложная логика сборра, то заебешься)
bormand # 0 ⇈
booratihno # 0 ⇈
а кодить потом в notepad++ ?
bormand # 0 ⇈
cmake то ещё говнище, конечно. Но по сравнению с мсбилдой он на порядки удобнее. Да и к венде гвоздями не прибит.
booratihno # 0 ⇈
>винде
ну если ты пишеш не только под винду, то понятно, что не нужно хранить проект в студийном говне
bormand # 0 ⇈
Да, и кастомные скрипты ещё. Но их реально проще выписать и переписать на чём-то другом. Особенно с учётом того, что студия все настройки по 4 раза повторяет если через гуйню править.
booratihno # 0 ⇈
ну да, но тебе похуй, если ты через гуйню всё делаешь
bormand # 0 ⇈
А потом ты видишь, что какая-то опция включена в 5 ворециях сборки из 8 и думаешь -- они это специально или так получилось? Комментов же гуйня не даёт написать.
booratihno # 0 ⇈
с гуйней еще есть такая проблема, что можно случайно вкоммитить путь
c:\users\booratiho\
и незаметить
Desktop # 0 ⇈
bormand # 0 ⇈
Там что-то есть, но через гуйню эти дефолты совсем пиздец настраивать, проще руками написать xml'ку.
Desktop # 0 ⇈
bormand # 0 ⇈
В основном очередным самодельным говноязыком. Ну и тем, что многие важные вещи вообще не поправить не залезая в код (а он на крестах).
А если собирать стандартные проекты -- сойдёт.
Desktop # 0 ⇈
bormand # 0 ⇈
Что-нибудь адекватное из императивных языков. Ибо сам cmake по сути и является императивным DSL, нахуяренным на коленке. Он даже не пытается косить под декларативность.
booratihno # 0 ⇈
bormand # 0 ⇈
Но cmake императивный и его как-то парсят... Полностью исполняют весь скрипт, как и гредл, на самом деле.
Вот отредактировать что-то из гуйни -- да, неразрешимая задача. Но никто вроде уже и не пытается.
booratihno # 0 ⇈
bormand # 0 ⇈
Ну конпеляцию можно же прервать. Вот тебе и решение хальтинг проблема.
Fike # 0 ⇈
Desktop # 0 ⇈
ну то есть какие у нас есть варианты?
1) пистон
2) ???
booratihno # 0 ⇈
bormand # 0 ⇈
Desktop # 0 ⇈
- каждому своё, но я уж лучше на велосипедном поделии попишу, чем на этой отрыжке wannabe-программистов
bormand # 0 ⇈
Ну удачи там. В js хотя бы переменные из фрейма вызывающей функции не наследуются. И массивы не через жопу сделаны.
Desktop # 0 ⇈
есть же какая-то билд-система на лиспе, кстати
Fike # 0 ⇈
*впрочем, я послал его нахуй год-два-три назад, когда оказалось что сишку надо компилить через рулы для плюсов, а компилятор самому выставлять через классическую переменную окружения (СС вроде)
Desktop # 0 ⇈
Fike # 0 ⇈
MAKAKA # 0 ⇈
Fike # 0 ⇈
j123123 # 0 ⇈
booratihno # 0 ⇈
но решение очень неоднозначное
bormand # 0 ⇈
Как что-то уникальное. qt creator вон из cmake их умеет получать. Да и из make опции конпелятора можно надрать в теории.
booratihno # 0 ⇈
но из make вряд-ли)
Впрочем, jциферкам может оно и не надо. Настоящему индейцу ctags+vim и заебись
j123123 # 0 ⇈
booratihno # 0 ⇈
Но editorconfig это хорошая идея, да.
bormand # 0 ⇈
Да это особо и не надо.
Самое главное -- макросы, инклуды, прочие опции конпелятора которые влияют на код. Вот это вот самое нужное в "проекте". Без этой инфы проще взять "ноутпад++" и не заморачиваться с "ИДЕ".
j123123 # 0 ⇈
Да, подобная хрень вполне нужна и полезна, но если эта хрень работает только в одной конкретной IDE, на одной конкретной платформе, то это херня.
booratihno # 0 ⇈
он прибит гвоздями к win32api например, и на другие платформы впринципе не портируется.
Или например он написан под cocoa и appkit и никогда не будет собираться ни под что кроме мака
j123123 # 0 ⇈
Потому что тогда получается так, что только на винде его и можно удобно редактировать, и только вот в этой конкретной IDE, а бывают ведь и другие ОС, и еще можно кросскомпилировать и удаленно отлаживать что-то, пользуясь при этом не виндой.
booratihno # 0 ⇈
Ты кстати в своем Makefile вполне можешь завязаться на наличие perl, bash, sed, awk, и удачи тебе в сборке это под другую ОС
j123123 # 0 ⇈
Будто бы есть что-то хорошее в том, что код под винду собирается только под виндой.
> Ты кстати в своем Makefile вполне можешь завязаться на наличие perl, bash, sed, awk, и удачи тебе в сборке это под другую ОС
perl, bash, sed, awk в винде можно из msys2 взять, с этим как-то попроще, чем если какую-то хуйню, наглухо завязанную на виндовый компилятор и SDK пытаться собирать в прыщах.
booratihno # 0 ⇈
Ну вот например есть проект (беру от балды)
https://plugring.farmanager.com/plugin.php?pid=312&l=ru
Это плагин в фару для посылки говна через MAPI (понятия не имею, кому это нужно).
MAPI есть только под винду, и FAR есть толкьо под винду.
На кой чорт тут вообще думать про другие ос?
>perl, bash, sed, awk в винде можно из msys2 взят
я видел попытки собрать всякое такое говно на винде, и это всегда был ад:
то у пользователя путь с ебанутыми символами, то еще что.
Кстати, завязка на bash тоже не позволит тебе портироваться дальше GNU:)
bormand # 0 ⇈
Ну вот так потом и получается, что "FAR есть толкьо под винду". Заебись подход.
Desktop # 0 ⇈
типа разработчик ФАРа должен был обязательно сделать его кроссплатформенным, чтобы лялиховоды вкусили плоды его работ? а не сильно ли это самонадеянно звучит?
guest # 0 ⇈
Очевидно, все эти технологии не нужны, ведь они не кросс-платформены
j123123 # 0 ⇈
> MAPI есть только под винду, и FAR есть толкьо под винду.
> На кой чорт тут вообще думать про другие ос?
А на кой черт надо так писать свои IDE и SDK, что собирать под винду эту хуиту возможно только из винды? Если у меня в контроллере некая OS, мне не надо почему-то в контроллер засовывать компилятор чтоб собрать под эту микроконтроллерную OS некую херню.
bormand # 0 ⇈
Эм, по-моему тут всё очевидно. Как и с маком. Манагеры сверху сказали -- нам нужен вендор-лок, чтобы винда/макбуки лучше продавались.
Desktop # 0 ⇈
- у тебя весь мир в контроллере, даже набо, даже нах-нах, мы уже поняли.
А винда тут при чём?
guest # 0 ⇈
Почему прыщепоттеринг не хочет писать кросс-платформенный софт, и предлагет свой софт на BSD даже не тестировать?
j123123 # 0 ⇈
bormand # 0 ⇈
В теории я, конечно, должен юзать последнюю версию и течь, а остальные просто снести. Но на практике это не работает.
booratihno # 0 ⇈
узнать, что у тебя теперь и новая не ставится, и старая не до конца удалилась
и все другие SDK и студии теперь у тебя тоже не ставятся, и пишут неизвестную ошибку.
И на форумах советуют сделать sfc /scannow, а более умные советуют переустановить Windows.
И только один чел нашел procmonом какой GUID в реестре нужно удалить, чтобы всё заработало
booratihno # 0 ⇈
prn.c , лол
https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42073
Какой смысл делать кросс компиляцию, тратить вермя на портирование SDK, разбираться с особенностями компиляторов (к примеру, экспорировать функции у линкера из вижала и gcc нужно по разному) если твой код все равно не будет работать на других ос?
Fike # 0 ⇈
j123123 # 0 ⇈
Почему у тебя "будет или не будет некий код работать под другими ОС" как-то увязывается с тем, "можно или нельзя компилировать этот код из некоторой-ОС под единственую-ОС-в-которой-код-будет-работать" ? Как это вообще соотносится?
MAKAKA # 0 ⇈
Твой код тоже не компилируется на bolrand c 3 под DOS, но тебя это нисколечки не волнует
Petro-san # 0 ⇈
bormand # 0 ⇈
MAKAKA # 0 ⇈
А исошки у нас и так обычно и образы дисков и с MBR, иначе как бы они с флешки грузились (без руфусов)?
bormand # 0 ⇈
MAKAKA # 0 ⇈
SetVolumeMountPoint("c:\\гавно", "d:\\гавно.bin") ?
Кстати, можешь попробовать еще vhdx: это и формат дисков для hyper-v, и их disk manager умеет прикручивать. Сейчас это модно:)
bormand # 0 ⇈
Он сложный, лень... А обычные vhd я умею генерить и цеплять, там простенький хедер в конце и всё.
MAKAKA # 0 ⇈
Я смутню помню, что там заголовок тома показывают драйверам файловых систем, и говорят "to je tvoje hovinko?", и кто первый согласится -- тот и прикручивает
bormand # 0 ⇈
MAKAKA # 0 ⇈
Поверх него драйвер партиций (который там понимает MBR, GPT, вот это всё), потом volumgr (который отличает софтварные рейды -- dynamic вот это всё), и потом файлуха
Petro-san # 0 ⇈
MAKAKA # 0 ⇈
j123123 # 0 ⇈
А почему возникла ситуация, что на это надо специально тратить время? Вот например взять некую ОС под микроконтроллеры, пусть это например будет RetroBSD, она предоставляет POSIX API и программное окружение unix и из нее даже можно компилировать код под нее же, притом работает она на микроконтроллере Microchip PIC32 с 128 килобайтами памяти и 512 килобайтами Flash: https://habr.com/ru/post/143679/
Почему-то там не возникало ситуации, что надо тратить время чтоб что-то под эту ОС собирать не из-под нее же. Почему? Может быть потому, что для RetroBSD никто не вендорлочил SDK и тулкит таким образом? Почему на винде такое возникло? Нахуя было вендорлочить? Хорошо ли это?
MAKAKA # 0 ⇈
Потому что не все компиляторы совместимы друг с другом, увы.
SDK для RetroBSD специально была сделана портируемой (и наверняка не на все существующие ОС) чтобы делать кросс-компиляцию, потому что на самом RetroBSD собирать не удобно.
Попробуй собрать ядро Linux на RetroBSD, или даже на OpenBSD (без GNU bitutils, gnu make, баша (там ksh), и гцц: шлангом и бздёвыми тулами с pmake). Скорее всего тебя ожидает сюрприз.
> POSIX API
Ты можешь использовать стандартную библиотеку си уровня C89 (VC не поддерживает c99), и собираться примерно одинаково всеми компиялторами, но далеко ты так не уедешь.
POSIX внезапно тоже покрывает далеко не все: начиная от сискола signal() (который в BSD и SystemV ведет себя по разному) и заканчивая epoll/kqueue в разных *nix нас ждут разные API.
Именно потому у любого крупнгого проекта есть огромные ОС-специфичные куски.
Тоже касается и сборки.
Неужели я могу просто так собрать clangом любую линуксовую и GNUшную тулу?
>Почему на винде такое возникло? Нахуя было вендорлочить?
SDK -- довольно крупная штука, и поддерживать её совместимость с разными компиляторами и OS это большая работа.
Смотри, Linux на Clang тоже не очень легко переносится
https://github.com/ClangBuiltLinux/linux/issues
И так, проблем много.
А есть ли бенефиты? Я ни одного не вижу.
Но разумеется, маркетинговое решение тут тоже есть: MS хочет, чтобы ты покупал Windows.
> Хорошо ли это?
Было бы отлично, если бы все ОС реализовывали одинаково SUS/POSIX, и все компиляторы работали бы одинаково.
Но увы...
j123123 # 0 ⇈
Как это мешает сделать кросскомпиляцию?
> Тоже касается и сборки.
С каких хуёв процесс сборки надо гвоздями прибивать к конкретной ОС? Компилятору нужно лишь читать из файла, писать в файл и аллоцировать/освобождать память, и всё, нихуя ничего платформоспецифичного компилятору делать не надо. Компилятору не нужно быть завязанным на какую-то хуйню вроде COM или реестр виндовса для компиляции чего-либо.
> SDK -- довольно крупная штука, и поддерживать её совместимость с разными компиляторами и OS это большая работа.
Что именно там ОС-специфичного? Повторяю, компилятору достаточно чтения файлов, запись в файлы, выделение памяти через malloc и освобождение через free.
> Смотри, Linux на Clang тоже не очень легко переносится
Это ты вообще в другую оперу полез. Я говорю не о том, чтоб хер пойми что хер пойми каким компилятором собиралось, а чтоб компилятор X который умеет компилировать код только !!ДЛЯ!! операционки W мог это делать не только в операционке W, а вообще в любой операционке, где есть возможность читать писать файлы и выделять память на хипе. С хрена ли ты приплел тот факт, что у разных компиляторов разные расширения?
MAKAKA # 0 ⇈
С таких, что ты не можешь скомпилировать любой код любым компилятором.
Ты не можешь взять Clang, и скомпилировать им Linux ядро "из коробки", не сделав предварительно телодвижений.
>С каких хуёв процесс сборки надо гвоздями прибивать к конкретной ОС?
Процесс сборки может быть прибит:
* к утилитам GNU (которых нет во многих ОС, пока ты их туда не поставишь)
* компилятору, которого нет на другой ОС
>Повторяю, компилятору достаточно чтения файлов
Сборка проекта состоит не только из компиляции .c файлов в объекты с последующей линковкой, но еще и хуевой кучи всего: от компиляции ресурсов, до генерации лексеров и парсеров.
На тебе жабаговно от гнушников
https://openjdk.java.net/groups/build/doc/building.html
Build Tools Requirements
* Autoconf
* GNU Make
* GNU Bash
Всё. Без этого говна ты ничего не соберешь.
>Компилятор X который умеет компилировать код только !!ДЛЯ!! операционки W мог это делать не только в операционке W
В смысле ты спрашиваешь меня, почему VisualC++ не портировали под Linux, чтобы ты там мог зачем-то собирать код под Win32API?
j123123 # 0 ⇈
Да. И какое это имеет отношение к вопросу о том, почему я не могу код специально для MSVC компилировать в MSVC который работает не в винде?
> Процесс сборки может быть прибит:
> * к утилитам GNU (которых нет во многих ОС, пока ты их туда не поставишь)
Эти утилиты непереносимы (вендорлокнуты)? Ну типа, может они к systemd привязаны, и без systemd они не запускаются?
> Сборка проекта состоит не только из компиляции .c файлов в объекты с последующей линковкой, но еще и хуевой кучи всего: от компиляции ресурсов, до генерации лексеров и парсеров.
Что в этом платформоспецифичного?
> В смысле ты спрашиваешь меня, почему VisualC++ не портировали под Linux, чтобы ты там мог зачем-то собирать код под Win32API?
Бинго!
MAKAKA # 0 ⇈
shell и make это части операционной системы (во всяком случае, в bsd). Тот факт, что приходится рядом с ними ставить еще и их GNUшные аналоги говорит нам о том, что для сборки проекта недостаточно портировать компилятор: нужно портировать и другие утилиты тоже.
Теперь смотрим, какие утилиты нужны винде:
>Что в этом платформоспецифичного?
В SDK есть .bat файлы, которые не работают на *nix по причине отсутствия там cmd.exe.
В SDK есть утилиты, использующие API операционки.
Компилятор ресурсов ``rc.exe`` импортирует user32.dll и kernel32.dll.
Наконец сам компилятор файл "cl.exe" импортирует следующие dll:
* ole32.dll
* kernel32.dll
* MSVCP140.dll (это как раз рантайм)
* ADVAPI32.dll
>Бинго!
Итого:
Чтобы портировать WinSDK и VisualC++ на Linux, там придется:
* Убрать завязку на наличие cmd.exe из SDK
* Убрать завязки на win32API (сделав свой слой абстракции, где этот функционал реализован поверх линуксовых сисколов)
Звучит как "дохуя работы", а какой в этом практический смысл я так и не понял.
Зачем собирать что-то для виндуоса на линуксе?
j123123 # 0 ⇈
Отсутствие cmd.exe это наименьшая из проблем. В wine есть свой cmd который может батники запускать.
> Зачем собирать что-то для виндуоса на линуксе?
Чтобы можно было юзать билд-серверы не на винде для сборки.
MAKAKA # 0 ⇈
Возможно можно запусьтить VisualC++ на Wine. Я не пробовал.
API винды частично закрыт, и я не уверен в стабильности этого решения:)
>Чтобы можно было юзать билд-серверы не на винде для сборки.
Зачем? Какой в этом смысл?
А в линуксе так делают, кстати? Убунту и дебиан собирают на FreeBSD и Solaris?
j123123 # 0 ⇈
Допустим чтоб арендовать в AWS хуйни и там компилировать под винду не в винде.
> А в линуксе так делают, кстати? Убунту и дебиан собирают на FreeBSD и Solaris?
С FreeBSD - https://gist.github.com/bijanebrahimi/62596745808f8667c40ff91b07d9e7b8
C Solaris - https://stackoverflow.com/a/2438768
Ну и наверняка можно и из FreeBSD под Solaris, и из Solaris под FreeBSD, но есть шанс напороться на хуевый сборочный скрипт, который тебе всю малину испортит.
6oHo6o # 0 ⇈
А на AWS нельзя поставить винду?
Просто если я виндоблядь, то у меня и админы виндобляди, и линукса не знают. Зачем плодить сущности и изучать что-то еще?
>wget https://ftp.gnu.org/gnu/binutils/binutils-2.27.tar.gz
Ну то есть начинать нужно с кучи левых сущностей?
А зачем? В чем смысл?
Fike # 0 ⇈
6oHo6o # 0 ⇈
Если я пишу, например, игру под Direct3D, то я вообще может линукс в глаза не видел. Зачем мне про него думать?
j123123 # 0 ⇈
А если я не хочу ставить винду? Нахуй ставить винду только ради компилирования хуйни под винду?
6oHo6o # 0 ⇈
Потому что VC++ не работает под другие ОС:)
Вообще винда так работает: чтобы что-то под нее сделать, обычно нужно поставить винду.
Нахуя ставить систему с GDI чтобы сделать на ней файлопомойку, например? Или веб сервер?
Но ставят же
j123123 # 0 ⇈
Кстати нахуя придумали эту поебень с ресурсами, если всю хуйню можно хранить просто как обычные данные, не внося новых сущностей?
bormand # 0 ⇈
А так то да, qt картинки просто эмбеддит как сишные массивы.
6oHo6o # 0 ⇈
У тебя есть .exe файл с иконкой и картинками, например
Fike # 0 ⇈
j123123 # 0 ⇈
Если б эта хрень была нужна только чтоб у .exe файла была иконка, я б этот вопрос не задавал.
6oHo6o # 0 ⇈
Но там можно хоть картинки хранить, хоть что
Fike # 0 ⇈
6oHo6o # 0 ⇈
Fike # 0 ⇈
да-да, можно задавать вопрос "а что хорошего в твоей шутке?"
6oHo6o # 0 ⇈
Ты против ембединга иконок? не нужно так делать?
Fike # 0 ⇈
j123123 # 0 ⇈
https://www.youtube.com/watch?v=LuSNjmEcVjY
TOPT # 0 ⇈
j123123 # 0 ⇈
Вообще, если внимательно перечитать сообщение https://govnokod.ru/27294#comment615192 то я указывал не только на проблему сборки для "проектов", вендорлокнутых на непереносимый тулчейн (тулчейн, который запускается только на винде), но и на проблемы что некая IDE хранит некую хуйню:
> "Самое главное -- макросы, инклуды, прочие опции конпелятора которые влияют на код. Вот это вот самое нужное в "проекте". Без этой инфы проще взять "ноутпад++" и не заморачиваться с "ИДЕ"."
которая делает более удобным редактирование что-то в этом "проекте", и эта хуйня работает только в этой ОС только в этой "ИДЕ", и извольте компилировать это только на винде, билдсерверы с прыщами тут не катят.
MAKAKA # 0 ⇈
Билдсервера на прыщах и так не катят же
j123123 # 0 ⇈
... то можно сделать так, чтоб работали. Или запускать через неэмулятор wine (не факт что прокатит).
> Билдсервера на прыщах и так не катят же
И это плохо
MAKAKA # 0 ⇈
Ну ты согласен, что это много работы: отпилить всё от Win32API?
>. Или запускать через неэмулятор wine (не факт что прокатит).
Когда что-то проприетарное реверс-инженерят всегда может что-то не прокатить)
>И это плохо
Ну блин, мне тоже не нравится, что винда не POSIX. Но с этим уже ничего не сделаешь.
Маємо те, що маємо
bormand # 0 ⇈
Какое-то потепление с их стороны есть.
6oHo6o # 0 ⇈
Потепление началось потому, что они поняли, что скоро станут не нужны.
Нахуя питонисту ебаться с виндой (где нет гуникорнов) если у него есть мак или убунта?
bormand # 0 ⇈
Нет конечно, но раньше и в виндовом нельзя было.
booratihno # 0 ⇈
bormand # 0 ⇈
Но даже в худшем случае это лучше чем виртуалка. Ёбли меньше на порядок.
booratihno # 0 ⇈
bormand # 0 ⇈
С новым контейнером на каждый билд оно таки чище и воспроизводимей.
booratihno # 0 ⇈
Но софт любит серануть в реестр или в %LOCALAPPDATA%, и увы
bormand # 0 ⇈
Поэтому пусть сидит в одноразовом контейнере.
booratihno # 0 ⇈
какой бугор ))
bormand # 0 ⇈
Хеш от пути к файлу (что логично), положения в нём (что логично) и какой-то матери.
booratihno # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
Мне казалось, что если ты хочешь линковаться с внешними чуваками, то ты делаешь extern "C".
А что там наманглит компиляторр для статической линковки в один бинарь тебе пофиг, не?
bormand # 0 ⇈
booratihno # 0 ⇈
у тебя sha пощитан от него?
bormand # 0 ⇈
Ну вот есть у тебя бинарь и его исходники. Как ты убедишься, что он из них собран?
Дебиан вон тоже на это дрочит, овер 90% пакетов байт в байт можно пересобрать.
booratihno # 0 ⇈
если дата сырцов новее бинаря, то нужно его пересобрать
если нет, то нет
bormand # 0 ⇈
booratihno # 0 ⇈
ты не знаешь что у тебя получится, пока не соберешь.
если ты уже собрал, то получи sha, и распостраняй бинарь и sha.
В какой момент я могу захотеть сам собрать бинарь заарнее зная что у меня получится?
bormand # 0 ⇈
guest # 0 ⇈
Если у меня автогенеренное имя лямбды другое, то как мне это мешает?
bormand # 0 ⇈
Но ты мне не доверяешь и боишься его запускать. Тогда я даю тебе исходники. Ты их читаешь и собираешь... но получается какая-то другая хуйня, в которой весь код перемешан потому что лямбды по-другому называются. А запустить свой собранный драйвер ты толком не можешь т.к. подписать тебе его нечем. В итоге ты ни то ни другой юзать не можешь.
Тут-то ты и задумываешься, как было бы заебись, если бы бинарь всегда собирался одинаково.
booratihno # 0 ⇈
хотя он конечно редкоземельный
bormand # 0 ⇈
guest # 0 ⇈
у меня на репе лежит deb-src и deb. Ты почитал код deb-src, собрал deb, и убедился, что я не пиздун
bormand # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
booratihno # 0 ⇈
от чего всетаки зависит имя лямды?
bormand # 0 ⇈
В gcc вроде только от контента цппшника. Анонимный неймпейс вроде от пути к файлу ещё.
booratihno # 0 ⇈
если я чрутнул всё, и сырцы лежат в fakeroot , то проблемы нет
bormand # 0 ⇈
В последних студиях вроде тоже починили.
booratihno # 0 ⇈
вообще есть ощущение, что крестобялди соснули
в няшной имена символов стабильны и предсказуемы
bormand # 0 ⇈
А так получается, что с одной стороны анонимная хуйня не должна торчать из своего объектника. А с другой стороны мёржить одинаковый код из хедеров то хочется, поэтому она не совсем приватная, comdat по сути.
Вот и начинается ёбля с тем как мёржить foo и foo и при этом не мёржить foo и foo.
guest # 0 ⇈
JloJle4Ka # 0 ⇈
MAKAKA # 0 ⇈
JloJle4Ka # 0 ⇈
bormand # 0 ⇈
Если найдёшь -- можешь торвальдса пригласить побухать. Он обещал проставиться.
JloJle4Ka # 0 ⇈
MAKAKA # 0 ⇈
Fike # 0 ⇈
bormand # 0 ⇈
Какой блокчейн )))
MAKAKA # 0 ⇈
Всегда пишу
hash(hash(hash(hash(hash($var))
bormand # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
Настоящий PBKDF2 примерно так и работает, только там хмак вместо хеша.
bormand # 0 ⇈
Х.з., возможно хотелось более стабильное имя, чтобы даже при небольших правках не менялось. Пока ты рядом новую лямбду не добавишь.
MAKAKA # 0 ⇈
удобно
Fike # 0 ⇈
bootcamp_dropout # 0 ⇈
Ты можешь паралельно распространить бинарь и собирать чтобы потом убедиться что все совпадает и использовать разданные бинарники
guest # 0 ⇈
нахуя мне 5000 раз собирать одно и тоже?
bootcamp_dropout # 0 ⇈
Нахуя - чтобы на деплой тратить не час а полчаса или не два часа а час
guest # 0 ⇈
компилировать на десяти машинах одно и тоже?
чем это быстрее?
и если Борманд утверждает, что на разных машинах у тебя разные имена лямбд, то и билд по вашему не "ррепродюсбл"
bootcamp_dropout # 0 ⇈
у тебя есть бинарь который раздать по сети 30 минут и сорцы которые компилировать 30 минут
ты предлагаешь его сначала собрать, потом раздать = 60 минут
я предлагаю параллельно раздать и собрать чтобы потом каждая машина смогла сверить sha бинарника и того чтобы собралось = 30 минут, компилируется только на одной машине которая зарепортит sha
guest # 0 ⇈
идею я понял, но если Борманд утверждает, что в зависимости от машины у тебя будут разные бинари, то получается,что и собирать их придется в виртуалке?
CHayT # 0 ⇈
^
you are here
bormand # 0 ⇈
Когда они уже до systemd доберутся...
j123123 # 0 ⇈
Не надо было его припиливать туда.
> Ну блин, мне тоже не нравится, что винда не POSIX. Но с этим уже ничего не сделаешь.
Для компиляции никакой POSIX не нужен. Компиляция - чтение файлов, запись в файлы, выделение и освобождения памяти. Это можно и на условной DOS делать, если убрать ебнутые ограничения на имена файлов.
6oHo6o # 0 ⇈
Ты предлагаешь юзать C89? А как делать многопроцесную компиляцию? -j4 как сделать?
j123123 # 0 ⇈
"-j4" не юзает никаких pthread-ов или чего-то такого. Это просто означает, что одновременно можно запускать 4 процесса компилятора/линкера/еще-какой-то-хуйни.
6oHo6o # 0 ⇈
Разве в c89 есть для этого API?
Я правда не знаю, могу ошибаться
j123123 # 0 ⇈
6oHo6o # 0 ⇈
Выходит, для портирования компилятора между прыщами и пиндой придется делать разный код.
И такого, я уверен, дофига: "за бесплатно" портировать не получится.
Алсо, винда же это не просто ядро, это еще туева хуча сервисов.
Захочешь ты там в SDK свой .exeшник подписать например, и тебе понадобится доступ к виндовому CryptoAPI, потому что у пользователя там лежит сертификат и ключ (в отличие от линуксов, где "openssl" это просто сторонняя тула, в винде это часть системы)
j123123 # 0 ⇈
Какие сложности у тебя возникнут с написание общей обертки под разные ОС, умеющие в эту многозадачность?
> Выходит, для портирования компилятора между прыщами и пиндой придется делать разный код.
Компилятор ничего про многопоточность знать не должен, вызывать несколько экземпляров компилятора параллельно - задача сборочных скриптов
> И такого, я уверен, дофига: "за бесплатно" портировать не получится.
Приведи реальный пример
6oHo6o # 0 ⇈
Любой код увеличивает сложность системы. Не стоит добавлять код, если он не решает никакую полезную задачу.
Задача "компилировать виндовый софт под линуксом" полезной не является к сожалению, потому что у нас пока нету ни одного реального примера такого желания от разработчика под windows.
>вызывать несколько экземпляров компилятора параллельно - задача сборочных скриптов
То есть нам еще нужно портировать и какие-то сборочные утилиты, и написать этот код в них?
>Приведи реальный пример
Ну вот нет кросс-платформенного запуска процессов.
signtool на винде умеет сходить в time server
https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool?redirectedfrom=MSDN
для работы с http у винды есть API, использующее настройки системы (прокси, аутентификацию, итд): все это придется переписывать
Да и сам Signtool завязан на CryptoAPI.
j123123 # 0 ⇈
У нас - это у кого? Вот пример: - кто-то такой херней занимается, значит кому-то оно надо.
j123123 # 0 ⇈
Хождение по http и всякие криптоапи - это уже не компилятор, а какая-то вспомогательная херня. Нехер было такую дикую поебень городить. Мне для компиляции хуйни через GCC не нужно никакое криптоапи и никакой http
bormand # 0 ⇈
Даже если ты технически сможешь запинать их тулчейн под прыщи (а это несложно), они тебя просто засудят нахуй за то что ты не с макакабука собирал.
Вендор лок такой вендор лок))
booratihno # 0 ⇈
шланг не сложно, а как ты будешь какие нить сториборды компилировать?
там же наверняка проприетарные тулы на Mach-O с кучей зависимостей?
bormand # 0 ⇈
А что это? Нам чисто сишку надо было, и то не разрешили. Шланга и библиотек вполне хватило бы.
booratihno # 0 ⇈
а вам нужна была corefoundation, или хватило бы тока bsdшных api?
Если тока BSD, то может можно было как-то DarwinBSD собрать?
guest # 0 ⇈
j123123 # 0 ⇈
В с89 есть функция system(), только там надо ждать завершение того запущенного процесса, так что второй параллельный процесс ей не породить.
6oHo6o # 0 ⇈
В линуксах у тебя чуть ли не в сисколе есть argv, а в винде это строка, и их нужно правильно склеить:)
А еще ты захочешь наверное чтобы новый процесс наследовал от тебя какие-то дескрипторы, или чтобы его завершения можно было ожидать (типа wait()), или проложить с ним какой-то pipe, чтобы общаться.. и все это нифига не портабельно на винду без кастомного кода
j123123 # 0 ⇈
В винде это строка если у тебя https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-winmain
Обычный main там тоже есть, и работает он как обычно
https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-160
6oHo6o # 0 ⇈
https://devblogs.microsoft.com/oldnewthing/20100917-00/?p=12833
боль
https://web.archive.org/web/20190109172835/https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/
j123123 # 0 ⇈
Хмм... а зачем это компилятору?
6oHo6o # 0 ⇈
а как мне знать, что они завершились?
j123123 # 0 ⇈
Это уже проблема не компилятора. Это проблема той штуки, которая их (процессы компилятора) запускает. И в самом компиляторе с этим ничего делать не надо.
j123123 # 0 ⇈
6oHo6o # 0 ⇈
ну блядь, в 1995-м году MS вообще не думал, что они как-то будут с юниксом серьезно соприкасаться
Нахуя было вообще брать VMS вместо Unix для NT?
Я бы с радостью отменил Windows, и заменил бы его на что-то типа Mac OS (которая SUS), чтобы не держать в голове по два вида каждой сущности, но увы
j123123 # 0 ⇈
bormand # 0 ⇈
Desktop # 0 ⇈
а проекты визуалки ты можешь открывать и в других IDE, как и икскодовские
j123123 # 0 ⇈
guest # 0 ⇈
Desktop # 0 ⇈
j123123 # 0 ⇈
Fike # 0 ⇈
6oHo6o # 0 ⇈
bormand # 0 ⇈
bormand # 0 ⇈
Функция аналогичным образом описывает свой контракт на входе. Если тупла не кастанулась -- значит каких-то утверждений не хватило.
З.Ы. Что-то я боюсь PoC этой хуйни пилить, как бы дьявола не призвать.
booratihno # 0 ⇈
bormand # 0 ⇈
Desktop # 0 ⇈
bormand # 0 ⇈
CHayT # 0 ⇈
CHayT # 0 ⇈
booratihno # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
bormand # 0 ⇈
6oHo6o # 0 ⇈
Хорошо, если так.
Мечтаю о таком для джвы, чтобы например функции с пометкой @Slow нельзя было вызвать из треда, обрабатывающего гуйные события (функции с пометкой @EDT, например)
bormand # 0 ⇈
В SDK вроде тоже есть аннотации про in/out и связи между размером и поинтером, но я не уверен что везде.
guest # 0 ⇈
в требовании
IRQL PASSIVE_LEVEL
значит ли это, что я не могу позвать её из обработчика прерывания?
В MSDN я не вижу на ней никакой аннотации, но может быть она есть в .h файле
или это вот то самое IrqlPsPassive ?
bormand # 0 ⇈
Саму аннотацию в хедере поищи.
6oHo6o # 0 ⇈
Круто, что такая штука есть
зы
нашел
вот это
_IRQL_requires_max_(PASSIVE_LEVEL)
?
bormand # 0 ⇈
6oHo6o # 0 ⇈
Потому что Walter Oney в книжке про WDM про это ничего не писал.
серый котейка в ботинок ссал
bormand # 0 ⇈
6oHo6o # 0