Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
Скачиваю какой-то проект, с гитхаба например. Хочу собрать. И что я вижу?
Вот например.
Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.
Это не программирование на С++, а черти что. Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
Я наверное что-то делаю не так. Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.). И как правило именно так и получается. Все, никакого мусора. А тут — ну я не знаю что с этим делать.
Ну хорошо, я терпеть это не могу, но я знаю про cmake. Программисты любят костыли и придумывают новые для обхода старых.
Скачиваю последнюю версию, скармливаю ей это все, нажимаю Configure... ошибка! В самом синтаксисе cmakefiles.
вот такая
CMake Error at cmake/Modules/LibtorrentMacros.cmake:75 (_cxx_standard_to_year):
_cxx_standard_to_year Function invoked with incorrect arguments for
function named: _cxx_standard_to_year
Call Stack (most recent call first):
CMakeLists.txt:503 (select_cxx_standard)
CMake Error at cmake/Modules/LibtorrentMacros.cmake:76 (if):
if given arguments:
"GREATER_EQUAL" "2011"
Unknown arguments specified
Call Stack (most recent call first):
CMakeLists.txt:503 (select_cxx_standard)
Зачем мне с этим разбираться?
Смотрю там есть файл .pro. Вспоминаю что в Студии есть расширение для Qt, открываю через это расширение — открылось! Расширение сгенерировало solution. Пытаюсь пересборать — ошибка. Даже не компиляции, а какая-то мутная ошибка невозможности выполнить Custom Build для файла который нужно обработать программой moc. Опять фигня, не относящаяся к программированию никаким боком.
В итоге я плюну на все это, и как делал уже не раз — заведу пустой проект в Студии, добавлю туда чистые исходники из скачанного проекта и получу нужный результат. Возможно не сразу, но получу. Для простых проектов обычно сразу получается, для больших и сложных — через несколько итераций.
Потому что чистые исходники на С/С++, написанные нормальным образом, как правило компилируются. Иногда приходится подправить какие-то мелочи, добавлять библиотеки которых у меня нет — но по крайней мере это все понятно, компилятор ругнется например на "нет такого-то инклуда" и я полезу его искать, найду и в итоге добавлю новую библиотеку в каталог с библиотеками.
Что я хочу сказать?
А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Здравствуйте, neFormal, Вы писали:
F>ладно, ты неосилятор. но есть же люди, которые знают и разбираются. F>они могут написать тебе сборщик, каким ты его хочешь видеть. F>просто заплати.
Я как-то раз искал конверторы для БОЛЬШИХ файлов. Нужно было перегнать кучу данных из dbf в постгрес. Это потом я уже узнал слово ETL и Pentaho Spoon, а тогда я за каким-то хреном стал искать утилиты. Можно было например сделать csv из dbf, но они получались какие-то кривенькие, и постгрес их не импортировал. В ходе сборки разных утилит, make, make install и всё такое, я познакомился с чудесным миром autotools, который до того времени как-то обходил стороной. То там makefile.ac какие-то не те инструкции содержит, то ещё чего, а одна из утилит потребовала для себя gnu lisp, и стала собирать самоё себя через оный лисп, где-то на середине процесса свалившись с ошибкой. Всё делалось на убунте.
В итоге, работающая корректно утилита была найдена, собрана и через неё, iconv и какую-то матерь всё было переложено в постгрес.
Теперь вот что. Я писал на ассемблере под дос, резиденты, для собственного интереса. Я писал на си-с-классами, когда ещё не началось победное шествие темплейтов с stl, а были модны т.н. "паттерны проектирования". Я писал на яве, на C#, на FoxPro всяком, на JS, на xslt, на дельфях, на питоне и даже на прологе чуть-чуть. Достаточно много писал на SQL.
Но вся эта культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры, где vim ваш умеет только бибикать и всё портить, где на клавиатуре нет курсорных клавиш — она прошла мимо меня. И знакомиться я с ней не желаю, наоборот — я желаю ей смерти, вместе со всеми её носителями.
Зачастую "программисты-осиляторы" вроде тебя испытывают слабо объяснимое отвращение к SQL. Видите ли, байтиков не видно, выдрачивать нечего. Да ещё и платить надо, за базы-то нормальные. Но именно sql и вообще реляционные базы являются хорошим примером того, как надо делать. Есть некое множество, если полная алгебра действий над объектами. Оно замкнуто, оно работает хорошо. Это правильная автоматизация.
А убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования. Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка! Нет, вася, надо было тебе, васе, это обратно в глотку засунуть, сразу же, пока оно не распространилось. Или, вася, делай нормально, или вообще никак не делай. Засилие убогих инструментов сдерживает развитие инструментария нормального. Где maven для си? Где nuget хотя бы? Ась? Чому оно такое всё кривое? Почему это вообще надо "осиливать"?
Как я и писал выше в теме, тут нужен интерпол и прокуратура. Чтобы народишко, который любит всякое говно, этим говном не увлекался.
Ничего из широко используемых программ не было написано с использованием вот этой всей субкультурки. Ни оракл, ни ms office, ни скайп, ни аська какая-нибудь (я понимаю, что в 2019 году вместо бесплатной аськи предпочтителен платный slack (жрите, жрите, то ли ещё будет в мире SaaS), но массовость была именно у аськи), ни corel draw, ни первый doom со вторым, ни norton commander, ни ещё множество разных программ, которыми люди пользуются в офисах и дома. 95% полезного софта, с чем множество людей буквально выросло рядом, было сделано именно под винду, именно в студии, и именно без кроссплатформенности.
Ваш линуксовый восход в РФ начался с нулевых годов и апача (русского) с php. На этом можно было писать сайты, где показывались сиськи. Вот это ваши истоки, "реального мира".
Кстати, расскажите мне, если вы знаете, каким образом собирается ms exchange, и почему именно на нём сидят множество контор, например московских. И почему именно мир, породивший оный exchange, оказался столь успешен, что альтернативщики по сей день не сделали ничего сравнимого. Наверное, до сих пор из vim выход найти не могут. Бесконечный тупик у них.
PS: В какой-то момент гуглам это всё безобразие надоело, и они сделали Golang, который не даёт возможностей для особенного разгула фантазии у разных изобретателей. И go так попёр, что потеснил практически все прочие языки. Хороший язык, палка для битья по рукам там прямо в компилятор встроена.
Здравствуйте, 00011011, Вы писали:
0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
Да нет, просто у тебя вместо языка здорового человека язык курильщика, велосипедостроение возведенное в сотую степень.
Здравствуйте, Amygdala, Вы писали:
A>Платные проекты, что я покуппал с исходниками, так вот идеально как ты пишешь и выглядят. Нажал на одну кнопкуи все скомпилилось.
Бесплатные такие тоже есть. Я видел платные очень энтерпрайзные проекты такие, что это вообще кошмар сборщика. Например, часть файлов надо собрать в одной версии Delphi, часть в другой, потом кое-что из результата пропатчить в 16-ричном редакторе и продолжить сборку в еще одной версии Delphi. И все эти манипуляции толком не описаны, являются чуть ли не сакральным знанием.
Читай README.rst, там все написано 0>Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты
Да, читать документацию — это сложно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Skorodum, Вы писали:
0>>Это не программирование на С++, а черти что. S>Это реальное программирование на С++. Welcome to the real world
Потому C++ под никсами всегда был болью.
Особенно после полноценной VS.
S>Судя по списку файлов в первом случае авторы поддреживают две системы сборки: CMake и qmake. Если обе для вас "самопальные утилиты", то это значит, что вы работали в очень тепличных условиях
Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке.
Вот только непонятно почему маршрутчики считают что это нормально и все должны страдать как они?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
CC>>Потому C++ под никсами всегда был болью. S>Боль — это поддерживать сложную сборку под несколько ОС, компиляторов и IDE, но это задача реального мира и за нее хорошо платят
При этом заботливо поддерживаются версии Alpha, Sparc Sun Solaris, Sun OS 68000k, Vax DEC, PDP-10 и прочее давно сдохшее дерьмо.
А на сборку под виндой клали большущий болт.
"Реальный мир", такой реальный.
Да что там винда, меня поразило, что добавленные опции (yes/no) конфига сборки ядра ломают билд. Например в одном из случаев — не хватало точки с запятой в конце строки.
Т.е. эти деятели не только собранное не тестируют (а как тестировать несобираемое ?), но даже сам факт сборки не проверяют.
Также очень веселым оказалось красноглазое решение обернуть gcc в питон-скрипт, который без параметров не делает ничего, а при компиляции файлов сообщает что скоро его задепрекейтят.
Разумеется это сломало kbuild где-то очень глубоко внутри.
Наружу добралось только сообщение "multiple target patterns" (тут ремарка о сверх-информативных сообщениях буханки, которые, ясное дело, не чета виндовым).
Это нормально, это можно. Подумаешь ядро годовой давности не собрать, в том же виде и тем же компилятором.
А вот добавить поддержку отступов пробелами в грёбаных makefile — никак нельзя.
Потому что в парсинг очень трудно это обязательно сломает ОЧЕНЬ НУЖНУЮ УТИЛИТУ 1488 года. Какую и почему — никто не знает. Но сломает — 146%
С — совместимость.
S>В реальном мире МС переходит на линуховые тулзы, а не наоборот (CMake, git)
Бугага.
Это она понторезов мягко к себе переманивает. Ну и обычным людям несколько упрощает жизнь, ковыряться в сплошном и густом unix-way становится попроще.
S>А не надо путать в кучу личные привычки и универсальное удобство S>Если вам нужна разработка только под МС — так сидите на студийных солюшенах приковынные цепью к одной IDE S>За возможность сборки на разных платформах/компиляторах/IDE приходиться платить.
Здравствуйте, jamesq, Вы писали:
J>Формат меняется, потому что MS хочет от тебя бабла.
От меня — не хочет. Community Edition бесплатна.
И от мелких контор не хочет (до 5 пользователей).
И от пишущих опенсорс не хочет.
J>Когда, если ты собираешься внедрить новую студию в конторе, ты обязан купить её всю сразу на все компьютеры программистов, что у тебя есть.
Что, правда ? Даже если программист не использует студию ?
Ну и если для большой конторы 500 баксов на программиста это ппц какие деньги — сомневаюсь что условия работы будут хорошими.
J>Иначе вы там конфликты будете получать.
Те, кто остался без студии, пойдут бить остальных ?
Здравствуйте, CreatorCray, Вы писали:
НС>>Да нет, просто у тебя вместо языка здорового человека язык курильщика, велосипедостроение возведенное в сотую степень. CC>Плохому девелоперу язык мешает?
Здравствуйте, 00011011, Вы писали:
vsb>>В современных языках обычно так. В С++ вроде cmake стандарт де-факто, ну autotools это ещё юниксовое наследие. А что, старый добрый ./configure && make не срабатывает?
0>Мне нужно именно под студию собрать, чтобы поразбираться в коде, в отладчике походить и т.д. 0>Просто ради сборки я бы и заморачиваться не стал бы, скачал бы готовый бинарник и пользовался бы
Ну это уже вопросы к студии, почему она не поддерживает индустриальный стандарт autotools. Если человек писал проект в линуксе используя vim, как от него можно требовать поддержки студии.
А что, в студии нельзя прицепиться к работающей программе? Т.е. просто создать новый проект, накидать туда все эти файлы исходников, чтобы студия про них знала, собрать бинарник извне с отладочной информацией и подцепиться.
Здравствуйте, neFormal, Вы писали:
F>это стандартный софт. и тебе стоило бы о нём знать. F>дык заплати — будет тебе сборщик.
Это говно, а не софт. Поделие от гоблинов для морлоков.
За это не платить надо, а палкой бить за изобретуцию с порнотехноложеством. Деньги тут не помогут.
Здравствуйте, Skorodum, Вы писали:
НС>>А ты не путай отношение к тебе, и к обожаемому тобой языку, это не одно и тоже. S>Вежливость это не ругать то, чего не знаешь.
Глупость сейчас сказал.
S> Если ты занимаешься задачами, где и C# подойдет — прекрасно, у него есть свои достоинства, но не стоит критиковать решения, которые созданы для задач о которых ты не знаешь.
А вот очередной переход на личности это точно к вежливости отношения не имеет.
S>Есть задачи, где С/С++ нет никой альтернативы и не появится в обозримой исторической перспективе.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да нет, просто у тебя вместо языка здорового человека язык курильщика, велосипедостроение возведенное в сотую степень.
Плохому девелоперу язык мешает?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
CC>>Особенно после полноценной VS. S>В реальном мире МС переходит на линуховые тулзы, а не наоборот (CMake, git)
Хипстерство страшное дело. Гит вылез на поддержке веток, но юзабилити у него кошмарный.
CC>>Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке. S>Студийные XML-солюшены это что угодно, но не "комфортная машина". Банально изменения в файле проекта не удобно смотреть.
Да как то не возникало каких либо проблем посмотреть на diff со старыми vcproj
Есессно diff был типа BC или Araxis, а не консольное угробище
S>А не надо путать в кучу личные привычки и универсальное удобство
Универсальным может быть только неудобство.
И к этому универсальному говну всё постепенно сползает.
S>За возможность сборки на разных платформах/компиляторах/IDE приходиться платить.
...кровью
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Dair, Вы писали:
D>уже были GNU Make (1976)
говно мамонта, которое за >40 лет так и не научилось поддерживать пробелы в makefile
D>даже autotools (1996).
Смотри:
configure:3396: checking for arm-linux-gnueabi-g++
configure:3426: result: no
...
configure:3440: checking for g++
configure:3456: found /usr/bin/g++
configure:3467: result: g++
configure:3483: WARNING: using cross tools not prefixed with host triplet
И потом всё обычным g++ компилит.
У меня g++ для арма не стоял, только gcc.
А тупой автоконф обладает искусственным интеллектом: пытаетcя откомпилить всем подряд, чем-то вроде компилится и похер, что вообще другая архитектура.
D>А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому.
Обратные слеши — наследие CP/M (1974), и она тогда была гоооораздо популярнее чем эти ваши юниксы.
Если бы не аутисты, полюбившие залипать на бегущие в Unix консоли строчки — всё могло сложиться совсем по-другому
Здравствуйте, Skorodum, Вы писали:
S>"Жопой" это когда нельзя автоматически установить toolchain для С++ одной командой на голой ОС.
"жопой" это когда установленный тулчейн содержит говно, палки и изоленту, которые ломают билд, а вместо ошибок выводят мусор (выше был пример).
"жопой" это когда автотул берёт первый попавшийся компилятор, кладя хер на указанную архитектуру
А тулчейн можно установить вообще без команд, парой кликов мышью. Да и устаналивается он один раз, и этот процесс погоды не делает.
Впрочем, за подсчётом количества команд пройдите к оберонщикам, там синтаксический оверхед в почёте.
Здравствуйте, dmitritch, Вы писали:
D>ну это тебе надо, а разработчики этих проектов может быть студию вообще в глаза не видели ни разу в жизни
Обычно подобное состояние у людей зовётся синдромом Маугли. Т.е. найден дикий разработчик, воспитанный чёрными терминалами. Передвигается на четвереньках, воет на perl.
Здравствуйте, Skorodum, Вы писали:
S>Простой пример где студия из коробки очень counterintuitive: горячие клавиши для закрытия вкладок. Это должно быть "ctrl+w" как в любом браузере
Уууу... Опять свой устав принесён в чужой монастырь?
Ещё с прошлого века это Ctrl-F4, как во всей ОС и в любом браузере под эту ОС.
S>Или использование xml для проектов.
Ну а XCode в чём хранит? plist это тот же XML, просто ещё и кривой.
S>Про догонят тоже спорно, т.к. например QtCreatot перешел на clang для автодополнения кода.
Не знаю куда там перешёл QT но вот в XCode вроде как тот же CLang и парсит он отвратительно, банальный #ifdef вышибает из него опору и здоровенные куски кода просто игнорируются — банальный refactor rename не видит там ни одного символа, что приводит к неожиданным результатам.
Вижуалка на том же коде работает замечательно.
И это лишь малая доля того, что сломано.
S>Там вложены многие-многие челокеко-года и Студия вряди ли догонит с самописным парсером.
Как IDE XCode пока не дотягивает даже до связки Студия 2008 + VAX, какое там!
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Слава, Вы писали:
С>Обычно подобное состояние у людей зовётся синдромом Маугли. Т.е. найден дикий разработчик, воспитанный чёрными терминалами. Передвигается на четвереньках, воет на perl.
Либо наоборот, когда для разработчика слова "программирование" и "msvs" слова с одним смыслом.
И отсутсвие в проекте подкаталога с пачки разных .sln файлов для разных версии студии вызывает панику.
Этот топик, кстати, с такого начался.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Слава, Вы писали:
F>>>это стандартный софт. и тебе стоило бы о нём знать. F>>>дык заплати — будет тебе сборщик. С>>Это говно, а не софт. Поделие от гоблинов для морлоков. С>>За это не платить надо, а палкой бить за изобретуцию с порнотехноложеством. Деньги тут не помогут.
F>ладно, ты неосилятор. но есть же люди, которые знают и разбираются.
It is generally true that if you can fool developers into thinking they are "mastering" something hard (as opposed to learning tolerance for something badly designed), you can build a fiercely loyal priesthood.
Здравствуйте, 00011011, Вы писали:
0>Это не программирование на С++, а черти что. Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
это стандартный софт. и тебе стоило бы о нём знать.
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Здравствуйте, Слава, Вы писали:
С>Я как-то раз искал конверторы для БОЛЬШИХ файлов. Нужно было перегнать кучу данных из dbf в постгрес. Это потом я уже узнал слово ETL и Pentaho Spoon, а тогда я за каким-то хреном стал искать утилиты. Можно было например сделать csv из dbf, но они получались какие-то кривенькие, и постгрес их не импортировал. В ходе сборки разных утилит, make, make install и всё такое, я познакомился с чудесным миром autotools, который до того времени как-то обходил стороной. То там makefile.ac какие-то не те инструкции содержит, то ещё чего, а одна из утилит потребовала для себя gnu lisp, и стала собирать самоё себя через оный лисп, где-то на середине процесса свалившись с ошибкой. Всё делалось на убунте.
что-то делал, решил не разбираться, что-то не заработало... плохой autotools.
С>Теперь вот что. Я писал на ассемблере под дос, резиденты, для собственного интереса. Я писал на си-с-классами, когда ещё не началось победное шествие темплейтов с stl, а были модны т.н. "паттерны проектирования". Я писал на яве, на C#, на FoxPro всяком, на JS, на xslt, на дельфях, на питоне и даже на прологе чуть-чуть. Достаточно много писал на SQL. С>Но вся эта культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры, где vim ваш умеет только бибикать и всё портить, где на клавиатуре нет курсорных клавиш — она прошла мимо меня. И знакомиться я с ней не желаю, наоборот — я желаю ей смерти, вместе со всеми её носителями.
пока весь мир переходит на такую же схему работы, у одного погромиста не хватает сил учиться.
С>Зачастую "программисты-осиляторы" вроде тебя испытывают слабо объяснимое отвращение к SQL. Видите ли, байтиков не видно, выдрачивать нечего. Да ещё и платить надо, за базы-то нормальные. Но именно sql и вообще реляционные базы являются хорошим примером того, как надо делать. Есть некое множество, если полная алгебра действий над объектами. Оно замкнуто, оно работает хорошо. Это правильная автоматизация.
autotools и SQL. сравнение, конечно, божественное.
особенно про байтики понравилось. после упоминания баша-то.
С>А убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования. Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка! Нет, вася, надо было тебе, васе, это обратно в глотку засунуть, сразу же, пока оно не распространилось. Или, вася, делай нормально, или вообще никак не делай. Засилие убогих инструментов сдерживает развитие инструментария нормального. Где maven для си? Где nuget хотя бы? Ась? Чому оно такое всё кривое? Почему это вообще надо "осиливать"?
дык мавен же говно. ладно бы ещё sbt какой помянул.. но мавен. фу, отвратительно!
а Вася всё правильно сделал: выбрал максимально универсальный и распространённый вариант.
С>Как я и писал выше в теме, тут нужен интерпол и прокуратура. Чтобы народишко, который любит всякое говно, этим говном не увлекался.
С>Ничего из широко используемых программ не было написано с использованием вот этой всей субкультурки. Ни оракл, ни ms office, ни скайп, ни аська какая-нибудь (я понимаю, что в 2019 году вместо бесплатной аськи предпочтителен платный slack (жрите, жрите, то ли ещё будет в мире SaaS), но массовость была именно у аськи), ни corel draw, ни первый doom со вторым, ни norton commander, ни ещё множество разных программ, которыми люди пользуются в офисах и дома. 95% полезного софта, с чем множество людей буквально выросло рядом, было сделано именно под винду, именно в студии, и именно без кроссплатформенности.
ничего из широко используемых программ не было написано в вижуалке: ни емакс, ни баш, ни перл, ни irssi.
С>Ваш линуксовый восход в РФ начался с нулевых годов и апача (русского) с php. На этом можно было писать сайты, где показывались сиськи. Вот это ваши истоки, "реального мира".
ну да, пока виндовозы пытались поднять кривой IIS, линуксоиды уже запустили и показали миру сиськи.
С>Кстати, расскажите мне, если вы знаете, каким образом собирается ms exchange, и почему именно на нём сидят множество контор, например московских. И почему именно мир, породивший оный exchange, оказался столь успешен, что альтернативщики по сей день не сделали ничего сравнимого. Наверное, до сих пор из vim выход найти не могут. Бесконечный тупик у них.
это легко объяснимо, как и привязка к софту от мелкософта типа вижуалки:
— всё дело в варезе
пока ты воровал софт, вася писал мейкфайлы руками и учился.
прошли года — вася стал успешным, а у кого-то до сих пор ms exchange
С>PS: В какой-то момент гуглам это всё безобразие надоело, и они сделали Golang, который не даёт возможностей для особенного разгула фантазии у разных изобретателей. И go так попёр, что потеснил практически все прочие языки. Хороший язык, палка для битья по рукам там прямо в компилятор встроена.
чего ж тебя тянет-то на гадость? голанг — это очень кастрированная поделка, которую ещё очень и очень сильно поменяют в будущем.
Здравствуйте, CreatorCray, Вы писали:
CC>Это отличная демонстрация подхода "а нам насрать что криво, как то шевелится и хрен с ним"
1. "Шевелиться" — это собираются старые проекты (и в 99% случаев они собираются без проблем на целевых платформах). Большего никому и не надо.
2. Кому "нам"? Хочешь — сделай лучше. Кому особо надо сделали CMake, meson, QBS, etc. Их и используют в новых проектах.
CC>Да насрать что там когда было. Вон, похожие идеи в телефонах были и до iPhone, но сделали всё удобно именно в Apple.
Ну да, а МС обосралась с телефонами несколько раз
CC>Так и с С++ — вижуалка сделала программирование удобным, а в nix продолжают пользоваться палками-копалками.
На любой голой линухе можно начать программировать или собрать проект за 30 секунд. Установка IDE на винде это приключение, CI/CD на винде — это боль и ад (стало чуть лучше, но все равно).
В nix есть не только Vi, но и QtCreator, который во многом получше Студии будет.
Здравствуйте, Skorodum, Вы писали:
CC>>Да насрать что там когда было. Вон, похожие идеи в телефонах были и до iPhone, но сделали всё удобно именно в Apple. S>Ну да, а МС обосралась с телефонами несколько раз
МС обосралась с маркетингом. А сами винфоны — отличная штука, если бы их еще делали.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, CreatorCray, Вы писали:
D>>Потому что Microsoft потратила деньги чтобы сделать себе IDE чтобы лучше продавать Windows. CC>Надо же, если хочешь развивать платформу — надо вкладываться в проектирование, тулсет и документацию! CC>Причём не херак херак и в продакшен а чтоб хорошо и удобно было.
кто в 2019м ещё пользуется вижуалкой?
это ж копролит эпохи доткомов. когда животные впервые вышли на сушу.
Здравствуйте, IID, Вы писали:
IID>Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ? ЗАЧЕМ ? (Кажется кто-то заврался.)
Даже если они так делают, то для подобных действий идеально подойдёт виртуалка со снапшотами.
Здравствуйте, CreatorCray, Вы писали:
C>>Например, Амазоном — там ещё круче, на билд-машинах вообще отключена всякая сеть (кроме localhost) для избежания даже возможности внешнего влияния на сборку. CC>Карго культ какой то.
Это современная практика в нормальных проектах.
CC>Какой смысл в этом геморрое?
Гарантия того, что проект собранный вчера будет работать точно так же, как и проект собранный сегодня.
C>>Из личного примера — в ходе сборки не убирался файл-флаг, который означал успех теста. Так что проваливающиеся тесты долго не обнаруживались. CC>А, т.е. прикрытие криворукости. И почему этот файл был насран куда то в левое место?
Потому, что люди ошибаются. И вместо "touch $(PREFIX)/testfile" пишут "touch $(PREFIX) /testfile".
Изоляция среды постройки гарантирует, что подобные ошибки не приводят к фатальным последствиям. Ровно как защита памяти — можно же всё идеально писать, нафига защита памяти некриворуким программистам?!?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
S>>В MSVС придется опции типа путей к библиотекам прописывать для всех вариантов. CC>Это в новых студиях идиоты сломали. Раньше один раз было достаточно.
Открой для себя пропсы. Делается пропс, подключается к желаемым конфигурациям. Все. Можно любые настройки так подключать, не только пути. Изменение в пропсе аффектится сразу на все.
Здравствуйте, IID, Вы писали:
IID>>>От меня — не хочет. Community Edition бесплатна. V>>Не совсем она бесплатная, под конец месяца отключается если, как понимаю, не зарегистрирована. IID>В чем заключается "небесплатность" ?
Гемор с регистрацией, которая "нежелательная фича"
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
In November 2001, a consortium was formed with a board of stewards to further the development of Eclipse as open-source software. It is estimated that IBM had already invested nearly $40 million by that time
Вот так вот, само по себе разработалось, сами по себе 40 лямов потратились...
Здравствуйте, Ikemefula, Вы писали:
S>>А зачем студенту делать что-то на C++? С какой целью?
I>Что бы стать С++ разработчиком надо писать на С++. Или у вас там всё иначе устроено, типа "пишу на питоне, хопа, пишу С++" ?
Не, начавшие учиться с питона необучаемы. Если человек начал в школе с Бейсика, продолжил Паскалем, а после в студенчестве Си, Си++, Жавой то к питону достигнет просветления и поймет, что неважно на чем писать.
Здравствуйте, Skorodum, Вы писали:
CC>>Ещё с прошлого века это Ctrl-F4, как во всей ОС и в любом браузере под эту ОС. S>Из коробки во всех двух браузерах (FF и Chrome) ctrl-w
Ctrl-F4 применялась для MDI ещё в Windows 3.1, когда авторы обоих браузеров ещё ходили в колготках.
Ссылаться на них как на законодателей моды для IDE, это нуу.. ммм... странно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
S>>Нет гарантии, что кто-то не установит софт для решения своих задач (наиболее типичная проблема). CC>А на билдсервер нету доступа для "решения своих задач". Если у кого то это типичная проблема то это проходной двор и бардак.
Другой пример вспомнил — одно из минорных обновлений JDK сломало Tomcat. Причём очень тонко сломало — оно падало в определённых случаях из-за неправильного использования gzip-сжатия.
Так как вся среда у нас полностью детерминирована, то ошибку нашли бисекцией за пару часов. В случае твоего любимого варианта: "куча копролита" это сделать было бы невозможно. Так как копролит не бисектится — это куча, данная в ощущениях.
Здравствуйте, 00011011, Вы писали:
0> Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make.
Здравствуйте, 00011011, Вы писали:
0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
Попробуйте собрать OpenSSL. Под Винду. В режиме совместимости с Visual Studio. Через полгода попробуйте снова, на другой машине. После этого придёт осознание что всё — тлен
0>Почему? Это вообще не затрагивает сам язык. Это просто обяжет всех разработчиков компиляторов и сред разработки следовать единой объектной модели проекта. 0>А то ведь кто во что горазд, в той же студии от версии к версии формат меняется!
Кого ты там обязывать собрался? И чем? Многие компиляторы вообще — консольные утилиты, которому ты просто указываешь имя файла с исходником, а он тебе объектный файл выдаёт. Вот так просто, и ничего больше.
Все эти проекты — навороты IDE. Куча народа только make файлами пользуются.
Формат меняется, потому что MS хочет от тебя бабла. Когда, если ты собираешься внедрить новую студию в конторе, ты обязан купить её всю сразу на все компьютеры программистов, что у тебя есть. Иначе вы там конфликты будете получать.
Здравствуйте, 00011011, Вы писали:
0>Даже не компиляции, а какая-то мутная ошибка невозможности выполнить Custom Build для файла который нужно обработать программой moc. Опять фигня, не относящаяся к программированию никаким боком.
А я периодически размышляю, нет ли во всех этих развесистых кастом билдах и скриптах какого-нибудь зловреда. Там ведь все равно сам черт ногу сломит, так что теоретически можно хоть слона там запрятать.
Здравствуйте, Слава, Вы писали:
С>Но вся эта культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры, где vim ваш умеет только бибикать и всё портить, где на клавиатуре нет курсорных клавиш — она прошла мимо меня.
Зато культуру убогого CMD ты впитал по полной
С>И знакомиться я с ней не желаю, наоборот — я желаю ей смерти, вместе со всеми её носителями.
Учиться в возрасте тяжело. Сочувтвую
С>Зачастую "программисты-осиляторы" вроде тебя испытывают слабо объяснимое отвращение к SQL.
Зачастую "программисты-НИосиляторы" вроде тебя испытывают слабо объяснимое отвращение к SQL...
С>Видите ли, байтиков не видно, выдрачивать нечего. Да ещё и платить надо, за базы-то нормальные. Но именно sql и вообще реляционные базы являются хорошим примером того, как надо делать. Есть некое множество, если полная алгебра действий над объектами. Оно замкнуто, оно работает хорошо. Это правильная автоматизация.
В мире "осиляторов" есть PostgreSQL и MySQL которые собираются autotools и CMake и имеют прекрасную командную строку
С>А убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования.
Ну так особо одаренные зачем-то стали использовать "\".
С>Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка! Нет, вася, надо было тебе, васе, это обратно в глотку засунуть, сразу же, пока оно не распространилось. Или, вася, делай нормально, или вообще никак не делай. Засилие убогих инструментов сдерживает развитие инструментария нормального.
Это про МС, их компилятор, командную строку, остутсвие пакетного менеджера и т.д. Ну сейчас они стали немного исправляться.
С>Где maven для си?
Ест CMake, есть meson, QBS.
С>Где nuget хотя бы? Ась? Чому оно такое всё кривое?
Где в вашем виндовом мире sudo apt install?
С>Почему это вообще надо "осиливать"?
Решает задачу и за это платят
С>Как я и писал выше в теме, тут нужен интерпол и прокуратура. Чтобы народишко, который любит всякое говно, этим говном не увлекался.
Это про проекты основанные на Студийных солюшенах?
С>Ничего из широко используемых программ не было написано с использованием вот этой всей субкультурки.
И далее он пишет про Го
С>Ни оракл, ни ms office, ни скайп, ни аська какая-нибудь (я понимаю, что в 2019 году вместо бесплатной аськи предпочтителен платный slack (жрите, жрите, то ли ещё будет в мире SaaS), но массовость была именно у аськи), ни corel draw, ни первый doom со вторым, ни norton commander, ни ещё множество разных программ, которыми люди пользуются в офисах и дома. 95% полезного софта, с чем множество людей буквально выросло рядом, было сделано именно под винду, именно в студии, и именно без кроссплатформенности.
Ты это в каком браузеры пишешь? ИнтернетЭксполорер 6.0?
С>Ваш линуксовый восход в РФ начался с нулевых годов и апача (русского) с php. На этом можно было писать сайты, где показывались сиськи. Вот это ваши истоки, "реального мира".
Ваша винда в РФ началась с пиратства
С>Кстати, расскажите мне, если вы знаете, каким образом собирается ms exchange, и почему именно на нём сидят множество контор, например московских. И почему именно мир, породивший оный exchange, оказался столь успешен, что альтернативщики по сей день не сделали ничего сравнимого. Наверное, до сих пор из vim выход найти не могут. Бесконечный тупик у них.
Кстати, расскажите мне, если вы знаете, в какой системе контроля версий храняться исходники МС? И почему имеено гитом пользуется весь мир? Почему имено мир, породивший оный гит оказался столь успешен, что альтернативщики по сей день не сделали ничего сравнимого. Наверное, до сих пор со студией мучаются. Бесконечный тупик у них.
С>PS: В какой-то момент гуглам это всё безобразие надоело, и они сделали Golang, который не даёт возможностей для особенного разгула фантазии у разных изобретателей. И go так попёр, что потеснил практически все прочие языки. Хороший язык, палка для битья по рукам там прямо в компилятор встроена.
Хороший язык, прямо из "осиляторной тусовки"
Здравствуйте, IID, Вы писали:
D>>уже были GNU Make (1976) IID>говно мамонта, которое за >40 лет так и не научилось поддерживать пробелы в makefile
Ну, это, конечно, серьёзная проблема
D>>даже autotools (1996). IID>А тупой автоконф обладает искусственным интеллектом: пытаетcя откомпилить всем подряд, чем-то вроде компилится и похер, что вообще другая архитектура.
А теперь давай то же самое элегантно в MSVS.
Я не говорю что make и/или автоконф есть венец творения и больше ничего не надо. Надо, мне автоконф не нравится вообще, Cmake гораздо практичнее (но тоже уныл). Но тезис коллеги CreatorCray'а был в том что "C++ под Unix плохо после полноценной VS". Я указал на то, что C++ под Unix был до, а иногда и задолго до MSVS.
D>>А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому. IID>Обратные слеши — наследие CP/M (1974), и она тогда была гоооораздо популярнее чем эти ваши юниксы.
Я, конечно, в 1974 ещё не родился, но вот википедия подсказывает что
CP/M 2.2 had no subdirectories in the file structure, but provided 16 numbered user areas to organize files on a disk. To change user one had to simply type "User X" at the command prompt, X being the number of the user wanted
То есть, там обратного слэша для разделения путей не было вообщеб потому что не было поддиректорий. "A:FILENAME.EXT" — всё.
IID>Если бы не аутисты, полюбившие залипать на бегущие в Unix консоли строчки — всё могло сложиться совсем по-другому
Но ведь в CP/M тоже была только консоль. GUI на тот момент был редкостью и кажущимся излишеством.
Здравствуйте, IID, Вы писали:
IID>Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ? ЗАЧЕМ ? (Кажется кто-то заврался.)
Здравствуйте, Skorodum, Вы писали:
CC>>Это отличная демонстрация подхода "а нам насрать что криво, как то шевелится и хрен с ним" S>1. "Шевелиться" — это собираются старые проекты (и в 99% случаев они собираются без проблем на целевых платформах). Большего никому и не надо.
Как правило эти не собираются с кучей невнятных ошибок.
S>Ну да, а МС обосралась с телефонами несколько раз
И?
S>Установка IDE на винде это приключение
Да какое то скучное приключение. Много раз его проходил — тыц, тыц, подождать... Скукота, никакой интриги.
S>В nix есть не только Vi, но и QtCreator, который во многом получше Студии будет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Cyberax, Вы писали:
C>Да, это сейчас нормальная и рекомендуемая практика.
Кем?
IID>>ЗАЧЕМ ? (Кажется кто-то заврался.) C>Для того, чтобы исключить взаимное влияние разных билдов.
Какое влияние? У вас что, процесс билда меняет весь environment?
Что то тут похоже выдаётся нужда за добродетель.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, IID, Вы писали:
J>>Формат меняется, потому что MS хочет от тебя бабла. IID>От меня — не хочет. Community Edition бесплатна.
Не совсем она бесплатная, под конец месяца отключается если, как понимаю, не зарегистрирована.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Cyberax, Вы писали:
C>И реальные инженеры (а не 1С-ники), которые работают с системами в сотни миллионов строк кода, это понимают и пытаются ограничить последствия ошибок.
Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А ты не путай отношение к тебе, и к обожаемому тобой языку, это не одно и тоже.
Вежливость это не ругать то, чего не знаешь. Если ты занимаешься задачами, где и C# подойдет — прекрасно, у него есть свои достоинства, но не стоит критиковать решения, которые созданы для задач о которых ты не знаешь.
Есть задачи, где С/С++ нет никой альтернативы и не появится в обозримой исторической перспективе. Инфраструктура вокруг этих задач равзивается и пересекается с твоим миром, но это не повод для жесткого батхерта.
Здравствуйте, CreatorCray, Вы писали:
I>>То есть, в обозримом будущем у XCODE ни единого шанса приблизиться к вижле нет. CC>Да блин, основы уже больше 10 лет не менялись. Пусть хотя бы сделают так же.
Не согласен.
* Из коробки у Студии ужасно переутяжеленный интерфейс: миллион нафиг не нужных кнопочек и менюшечек. Как раз за последнии 10 лет все постпенно осознали, что чистый и минималистичный интерфейс куда приятнее. Студию после установки надо пару часов дорабатвать напильком до более-менее приличного вида. Даже в МС это осознали и VSCode выглядит куда приятнее.
* Редактирование свойств проекта должно быть редактированием нормального кода, а не ползаньем по десятку окошек.
Здравствуйте, CreatorCray, Вы писали:
S>>Интересно, про XCode хороших отзывов пока вообще не слышал. (Сам не пробовал.) CC>Да потому что она counterintuitive. Пойдёт после vim/gdb но после вижуалки вызывает недоумение как можно так всё плохо сделать имея примеры как надо делать хорошо.
А что, трудоёмкость учитывать не надо ?
"Сделали хорошо" почти всегда означает — "долго думали и тщательно имплементили" MSVS вот такая потому, что в неё закопаны два десятка лет работы тысяч разработчиков, а до того это были отдельные тулы, в каждый из которых было закопано лет десять-пятнадцать сотен разработчиков.
То есть, в обозримом будущем у XCODE ни единого шанса приблизиться к вижле нет.
Здравствуйте, vsb, Вы писали:
vsb>Ну это уже вопросы к студии, почему она не поддерживает индустриальный стандарт autotools. Если человек писал проект в линуксе используя vim, как от него можно требовать поддержки студии.
Этих индустриальных стандартов столько, что шанс встретить опенсорс на autotools — как попугая увидать. Т.е. можно, но надо спецом идти в зоопарк.
Здравствуйте, Michael7, Вы писали:
M>Например, Qt строго формально вообще не на C++ написана. Используются некоторые расширения, которых нет в языке, а компилируется компилятором C++ только после того как специальный препроцессор (qmake) развернет их.
MOC (meta-object compiler), qmake это система сборки а-ля CMake.
Здравствуйте, 00011011, Вы писали:
0>Это не программирование на С++, а черти что.
Это реальное программирование на С++. Welcome to the real world
0>Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
Судя по списку файлов в первом случае авторы поддреживают две системы сборки: CMake и qmake. Если обе для вас "самопальные утилиты", то это значит, что вы работали в очень тепличных условиях
0>Я наверное что-то делаю не так.
Ну да, вы делаете что-то не так. Все эти файлы уже более-менее стандарт для проектов.
0>Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.).
Для "HelloWorld" и студенческой курсовой пойдет
0>И как правило именно так и получается.
Это просто говорит чем и в каких условиях вы занимаетесь. Ингода этого достаточно, но в большинстве случаев — нет.
0>Ну хорошо, я терпеть это не могу, но я знаю про cmake. Программисты любят костыли и придумывают новые для обхода старых. 0>.... 0>Зачем мне с этим разбираться?
CMake ужасен, но это уже почти стандарт
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. JSONCompilationDatabase
0>Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Мечты-мечты...
Здравствуйте, 00011011, Вы писали:
0>Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.
В живых должен остаться только один. (С)
CMakeList.txt — тот самый де-факто уже стандарт.
0>Это не программирование на С++, а черти что.
Это оно и есть.
0>Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
Вижу еще настройки для CI-сервака.
Но вручную тебе ничего с ними делать не надо, это для специального билда на стороне такого сервака, скрипт CMake их подхватывает, когда вызван с некими переменными.
В общем, от тебя требуется вызвать CMake стандартным образом.
0>Я наверное что-то делаю не так. Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.). И как правило именно так и получается. Все, никакого мусора. А тут — ну я не знаю что с этим делать.
0>CMakeLists.txt:503 (select_cxx_standard) 0>Зачем мне с этим разбираться?
Потому что три стандарта сменились за относительно короткий срок.
Укажи стандарт явно.
0>Потому что чистые исходники на С/С++, написанные нормальным образом, как правило компилируются.
А иногда по ходу билда нужно сгенерить код.
0>Иногда приходится подправить какие-то мелочи, добавлять библиотеки которых у меня нет — но по крайней мере это все понятно, компилятор ругнется например на "нет такого-то инклуда"
О том, что нет такой-то библиотеки ты узнаешь еще на этапе CMake.
0>и я полезу его искать, найду и в итоге добавлю новую библиотеку в каталог с библиотеками.
Дудки. Там такой же CMake, всё то же самое.
Зато, когда поставишь ту либу с помощью CMake, то оный на целевой программе обнаружит зависимость и пропишет в файле проекта все нужные пути.
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом.
При чём тут компилятор?
Например, компилятор C# ничего не знает про MS Build.
Зато CMake знает и умеет генерить в том числе и в MS Build.
Здравствуйте, CreatorCray, Вы писали:
CC>Потому C++ под никсами всегда был болью. CC>Особенно после полноценной VS.
У виндовз-программистов какое-то извращённое Микрософтом представление о мире. Да, Микрософт сделал довольно неплохую VS под себя. Но подходить к ней надо как к инструменту Микрософт для Микрософт, вещь в себе. При этом на момент создания VS (1997) уже были GNU Make (1976) и даже autotools (1996). А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому.
CC>Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке. CC>Вот только непонятно почему маршрутчики считают что это нормально и все должны страдать как они?
Это ты приучен к левой дюймовой резьбе, поэтому правая метрическая тебя вгоняет в тоску.
Кстати тут же опенсорс — ну сделай проект под Студию, выложи в общий доступ.
Здравствуйте, neFormal, Вы писали:
F>>>ладно, ты неосилятор. но есть же люди, которые знают и разбираются. S>>
S>>It is generally true that if you can fool developers into thinking they are "mastering" something hard (as opposed to learning tolerance for something badly designed), you can build a fiercely loyal priesthood.
Ну, ты тоже из интернета.
F>а ничего, что всё изменяется результатом? и если ты не "мастеришь" в чём-то, то просто не можешь что-то сделать.
Может, это и не было бы нужно делать. Однако, набигают люди, которые уже вложили кучу времени в изучение и освоение корявых технологий, и пытаются заставить всех остальных потратить время тоже.
Здравствуйте, Sharov, Вы писали:
S>Я cmake не знаю, но как он решают эти пробелмы? Т.е. по факту у нас действительно 8 комбинаций, Debug/Release переключается по шелчку. Как cmake помогает избежать 8 комбинаций?
В MSVС придется опции типа путей к библиотекам прописывать для всех вариантов.
Здравствуйте, Sharowarsheg, Вы писали:
S>То, что они не осилили, а также то, что они не предложили альтернатив, не отменяет того, что со сборкой дела обстоят не совсем хорошо (чтобы не сказать срань господня).
Да на самом деле отлично дела со сборкой обстоят: нормальные проекты сейчас собиаются из единого файла проекта под разные платформы и разными компиляторами. Поддерживать это объективно сложно
S>Ещё более приятный вариант, когда ты делаешь что-то настолько сложное, что никто нихрена не может в этом разобраться.
Никто это "Слава", CreatorCray и ТС
S>По мере того, как ты всё более и более усложняешь это нечто, ты получаешь всё больше и больше денег, и порог входа всё больше и больше. Это прекрасно работает, пока не кончается.
Это подход МС: сделать сложно и залочить всех.
Здравствуйте, Sharowarsheg, Вы писали:
S>Почему не нормальны. Я вот скажем, пишу под Windows. Не знаю, причём тут CMD, но вот эти всё дикие сборочные скрипты мне не нравятся.
А что нравится? Вот стоит задача чтобы проект собирался под Win/Linux/Apple. Как решать? Причем с генерацией кода lex/yacc, генерацией питонвского API и зависимостями от нескольких внешних библиотек. И все это автоматически в CI.
МС не осилило кросс-платформенную сборку, а "осиляторы" худ-бедно, но справились.
S>Не то, чтобы я стенаю по этому поводу, но если тема зашла, то я вполне могу сказать, что это костыли, подпёртые костылями, унаследованные через поколения теперь уже людей, а не софта.
Да никто не использует autotools для новых проектов, вам надо — можете написать новый файл проекта У всяких линуховых дистрибутивов процесс налажен и все работает и с autotools.
S>Иногда кто-то соизволит в исходники включить файл проекта для MSVS, тогда ещё куда ни шло, и то не всегда.
Жалуйтесь в МС, чтобы они поддерживали нормальные системы сборки типа CMake(вроде уже)/Meson/QBS.
Здравствуйте, Cyberax, Вы писали:
CC>>Карго культ какой то. C>Это современная практика в нормальных проектах.
Это попытка прикрыть кучу говна руками.
C>Гарантия того, что проект собранный вчера будет работать точно так же, как и проект собранный сегодня.
Только если в проекте пц и бардак до такой степени что его нельзя пересобрать 2 раза подряд и получить одно и то же.
C>Потому, что люди ошибаются. И вместо "touch $(PREFIX)/testfile" пишут "touch $(PREFIX) /testfile".
Ну а таким образом баг не чинится а заметается под коврик
Оно то кое как работает, но воняет некомпетентностью.
C>Изоляция среды постройки гарантирует, что подобные ошибки не приводят к фатальным последствиям.
Это просто игнорирование ошибок. Офигенная методика, чо!
Софт, который там собирают поди так же пишется?
C>Ровно как защита памяти — можно же всё идеально писать, нафига защита памяти некриворуким программистам?!?
Напомню что защита памяти приводит к exception и panic если кто то пытается её нарушить.
А тут воткнули catch (...) на самом верхнем уровне и решили exceptions ловить больше нигде не надо.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Там такое говно что лучше бы не справлялись чем так.
Ну это не тебе решать
CC>Можно было сделать нормально, но они предпочли не разобраться а просто притащить весь свой монастырь.
Да все более-менее работает, если руки откуда надо растут. МС и этого не осилила.
Здравствуйте, Ops, Вы писали:
S>>Сборка должна работать с минимальными требованиями и никакая IDE и GUI для этого не нужны. Ops>А git должен работать без всякого мусора от лялиха, но тут рядом отстаивают необходимость этот мусор, и всякий сопутствующий ему цыгвын, обязательно таскать вместе с ним. Двойные стандарты?
Ты немного путаешься.
"Сборка должна работать" — это значит взяли новый сервак, поставили в стойку, запустили командочку "do all" и проект собрался. А не так, что надо Васе-старшему-разработчику (т.к. это только он знает) провести пару недель в RDP, устанавливая нужный софт, прописывая переменные окружения, конфиги и пути.
"git должен работать без всякого мусора" — а вот это зачем? Что это даёт?
Если бы приходилось для работы git устанавливать кучу мусора вручную, прописывать всякую байду — это да, проблема. А если у тебя есть setup.exe, а то и тупо "sudo apt install git" который в один клик ставит работающее окружение, но травмирует твоё чувство прекрасного — то это проблемы не в технологии, а в психиатрии.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Skorodum, Вы писали:
S>Нет гарантии, что сервер не обновился.
Обновление ж делается не как fire and forget.
S>Нет гарантии, что кто-то не установит софт для решения своих задач (наиболее типичная проблема).
А на билдсервер нету доступа для "решения своих задач". Если у кого то это типичная проблема то это проходной двор и бардак.
S>Не документированно кто, что и когда установил на этот сервер
С чего бы? Левые люди ничего туда ставить не могут, кроме нужного тулсета там никогда ничего нет.
S>Воспроизвети этот билд сервер или увеличить производительность — большой геммор
С чего бы? Там ж build farm а не одна машина.
CC>>Там в итоге бинари подписываются, так что хеши будут всегда разными просто по определению. S>С чего этого? Время сборки включено в процесс подписывания?
Подпись timestamped
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Nikolaz, Вы писали:
N> Засуньте свой QtCreator с его отладчиком в одно место.
На кывте с 2002 года, а жаргон как у студента провинциального вуза...
N>На работе есть один достаточно нехилый по размеру проект (около 50 .pro файлов). N>Так вот он в отладке просто еле шевелится. Народ "дебажит" через логи
Это у вас какая-то локальная проблема. Количество .pro файлов ни о чем не говорит, т.к. к дебагу они напрямую не относятся. Чтобы утверждать, что проблема в QtCreator надо посмотреть как работает голый отладчик или другая IDE с теми же исполняемыми файлами (в самом QtCreator отладчика даже нет, он вызывает GDB/CDB).
Для примера я отлаживал сам QtCreator в QtCreator — никаких особых проблем
N>А основной аргумент со стороны руководящего звена в пользу QtCreator был вообще отпадный: N>"Мы покупаем библиотеку Qt, а так там уже есть QtCreator, то разрабатываем на нём."
1. Студий умеет работать с pro файлами через плагин (раньше точно умела)
2. Если у вас коммерческая поддержка, то в чем проблема написать в Qt?
3. Можно генерить makefile и пользоваться чем душе угодно.
N>p.s. Ничего личного.
Да пожалуйста, только оставайтесь в рамках приличий.
Здравствуйте, IID, Вы писали:
IID> AB>Удивляет, что кто-то <пока еще> так НЕ делает и еще умудряется этим хвастаться. IID> Ничего удивительного. Буханке не доверяют даже её одепты. Отчаявшись искоренить дерьмо — смирились с участью вечного подтирания жопы. Дискуссия Cyberax-а и CreatorCray очень показательна.
Какое дремучее невежество... По ощущениям от прочтения данной подветки ты и компания отстали от индустрии (при чем безотносительно ОС) лет на 15+. Как буд-то до сих пор лабаете телефонный справочник на турбо-паскале в подвале богом забытого НИИ.
Здравствуйте, Skorodum, Вы писали:
CC>>VM + snapshot тут будет куда более подходящее решение. S>Ну примерно так и делается
Напомню что речь как раз шла не об откате на снапшот а на переустановку скриптами всего build environment с нуля.
Что как раз и вызывало недоумение "нафига так корячиться".
IID>>Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ?
C>Да, это сейчас нормальная и рекомендуемая практика.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, IID, Вы писали:
AB>>Удивляет, что кто-то <пока еще> так НЕ делает и еще умудряется этим хвастаться. IID>Ничего удивительного. Буханке не доверяют даже её одепты. Отчаявшись искоренить дерьмо — смирились с участью вечного подтирания жопы. Дискуссия Cyberax-а и CreatorCray очень показательна.
Весь код — это глюкодром. ВООБЩЕ весь код, без исключения. Даже в TeX есть баги.
И реальные инженеры (а не 1С-ники), которые работают с системами в сотни миллионов строк кода, это понимают и пытаются ограничить последствия ошибок. Тогда как 1С-ники просто считают, что надо писать "без ошибок".
Здравствуйте, Anton Batenev, Вы писали:
AB>Какое дремучее невежество... По ощущениям от прочтения данной подветки ты и компания отстали от индустрии (при чем безотносительно ОС) лет на 15+. Как буд-то до сих пор лабаете телефонный справочник на турбо-паскале в подвале богом забытого НИИ.
Ох и не говори, петровна. Отстали, ещё как.
Лет 10-15 назад тех, кто не осиливал разобраться в причинах, и всё решал полной переустановкой, называли "эникейщик".
А теперь, видимо, это девопс...
Одепты буханки хвастались стабильностью и аптаймом в несколько лет.
А теперь на острие прогресса мода и безграмотность. Небось блокчейн тоже используете, да ?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC.
НС>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах.
Одна ошибка раз в год может спокойно перевесить суммарную стоимость всех билдов вместе взятых.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Оно куда идеальнее, чем накатывать на голый образ тулы при каждой сборке.
Это уже детали реализации. При использовании тех же контейнеров все будет кэшировано и без изменения файла, описывающего контейнер, никаких реальных накатываний не будет.
НС>Если тебя одолевает паранойя по поводу того, что враги подменят образ внезапно, то всегда можно собирать образ/контейнер при помощи того же CI, но строго только при изменении скриптов подготовки ВМ.
Дела не во врагах, а в следовании DRY принципу. Инфраструктура для сборки должна быть кодом и должа быть частью проекта. Раньше такое было невозможно, теперь — легко и удобно.
При том что именно он тут основной источник проблем.
·> Можно лабать вебсайтики на священном c# в родной Студии. Но вот захочется (а в любом сколько-нибудь нетривиальном проекте захотеть придётся) во время билда чего-нибудь необычного, прогонять какие-нибудь selenium-тесты, да ещё и на разных браузерах, разных версий — вот сложность и попёрла.
Ну как обычно, начинаем резко сползать с билда на тесты.
Впрочем, у меня все это гоняется, и селениумы и много чего еще (например, один из проектов собирается под 13 платформ, и тесты тоже на всех них гоняются). Но чего то описанных ужасов со сборкой нет — прекрасно работает на куче разных билд-серверов и локально на машинах разработчиков. Так что могу только согласиться с IID — сначала разводят фантастический, с наслоениями, бардак, спихнув сборку на самых низкоквалифицированных разработчиков, а потом придумывают чудовищные с инженерной точки зрения костыли.
S>>за libgit больше "осиляторов", чем сторонников *.sln. CC>это ж вообще ортогональные вещи
Конечно, но тут высказывают огульные притензии к "осилятором" и "красноглазикам" за то, что они, видители, как-то плохо гит на винду портировали.
Здравствуйте, Dair, Вы писали:
D>В далёком 199забытом году мои одно-тогда-ещё-группники испортили себе мозг Windows'ом и Visual Studio. А я начал писать под Linux. Xcode — это уже потом. Да и Qt Creator потом. Основные инструменты — vim и gdb.
Ну тогда все еще хуже Даже в далеких 199х много раз пробовал самые разные операционки, но так и не пришел к такому — да чего там мучиться набил в виме пару экранов текста и все, что надо получил
Меня всегда веселит, когда какой нибудь линуксоид говорит — да в линуксе ставить программы просто и демонстрирует — набрав строчку абаракадабр
Или рассказывает про отладку упоминая gdb, даже в 90х был борландоский турбодебагер, после которого даже на софтайс смотреть не хотелось, хоть и возможностей в нем было больше
Я вообще думаю, что человек смогший постичь XCode очень умный, но даже чтоб назваться очень умным такой подвиг совершать — не стану
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, vsb, Вы писали:
vsb>>Ну это уже вопросы к студии, почему она не поддерживает индустриальный стандарт autotools. Если человек писал проект в линуксе используя vim, как от него можно требовать поддержки студии.
MD>Этих индустриальных стандартов столько, что шанс встретить опенсорс на autotools — как попугая увидать. Т.е. можно, но надо спецом идти в зоопарк.
autotools вообще-то из-за своей специфики рекомендуется только для того, что, как предполагается, будет ставиться на недружественную систему, где левый компилятор, тупейший make, кривоватый шелл, и так далее, и оно 100% Unix-ориентировано (хотя бы из-за того же sh). Как только этот предел пройден — считается, что присутствуют gcc/clang, binutils, gmake (недолюбливаю из-за некоторых свойств, но умеет зараза таки много), возможно bash, и так далее, можно включать другие средства, как тот же cmake.
Поэтому поддержка autotools в VS — бессмысленно.
А вот про cmake можно было бы уже и подумать. Но раз cmake умеет делать проект для VS, то уже есть на что смотреть (если можно поверх такого проекта, не патча его, собирать с доп. опциями).
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Dair, Вы писали: D>>уже были GNU Make (1976)
Вообще-то просто make. GNU стартовал на 11+ лет позже.
D>>А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому. IID>Обратные слеши — наследие CP/M (1974), и она тогда была гоооораздо популярнее чем эти ваши юниксы.
CP/M не имела иерархии каталогов FS и соответственно никакого разделителя пути. Это дерьмо с \ было введено в MS-DOS 2.0.
IID>Если бы не аутисты, полюбившие залипать на бегущие в Unix консоли строчки — всё могло сложиться совсем по-другому
"Аутисты" сделали GUI раньше — SGI IRIS в 85-м поверх System V имела полноценную графику (а не зародыш, как в Windows 1.0).
Здравствуйте, CreatorCray, Вы писали:
S>>Про догонят тоже спорно, т.к. например QtCreatot перешел на clang для автодополнения кода. CC>Не знаю куда там перешёл QT но вот в XCode вроде как тот же CLang и парсит он отвратительно, банальный #ifdef вышибает из него опору и здоровенные куски кода просто игнорируются — банальный refactor rename не видит там ни одного символа, что приводит к неожиданным результатам.
Ну так на билд-машину не поставили, видимо, нормальный clang. Вот мега-гении из Apple и не могут ничего сделать.
А так, для clang есть режим разбора с игнорированием условной компиляции. Оно не 100% надёжно (C++, однако), но работает в части случаев.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Skorodum, Вы писали:
S>>>Ctrl-F4 применялась для MDI ещё в Windows 3.1, когда авторы обоих браузеров ещё ходили в колготках. S>>1. MDI != tabs. N>А вот тут хотелось бы обоснования. Табы браузера это настолько соответствует классическому MDI, что я при всём желании разницы не нахожу.
Ну каноничного определения тут нет, но MDI это свободно плавающие окошки, а TDI это все же одно окно.
N>Ну тут разве что рукой тянуться быстрее (поэтому, пока работает Ctrl+W, я его использую).
+1
N>В браузере нет той безумно навороченной функциональности, как в IDE
В браузерах все на порядок круче, включая встроенную IDE.
N>и обычно нет необходимости в таком количестве шорткатов.
Просто ты не пользуешься, веб девелоперы пользуются.
Здравствуйте, bisoft, Вы писали:
C>>Мне проще текст прочитать — в нём можно делать поиск. А как мышкой найти нужный пункт? А если это надо в скрипт вставить и запустить на удалённом узле? B>Ну нажал F1 и так же можно делать поиск Ну речь как раз о том, что надо использовать то, что более подходящее и проще.
Так ведь не проще. Удобный CLI намного приятнее GUI.
Особенно учитывая последние достижения в области usability для CLI. Например, умный автокомплит для команд.
Здравствуйте, Dair, Вы писали:
D>Потому что Microsoft потратила деньги чтобы сделать себе IDE чтобы лучше продавать Windows.
Nokia/Digia тратятся на QtCreator который под Win/Linux/Mac.
Здравствуйте, vsb, Вы писали:
H>>autotools это неюзабельное нечто. А этот их m4 прямо создан для того, чтобы на нём было невозможно писать. vsb>Почему? По-моему хороший препроцессор.
У него две принципиальные проблемы.
1. Писать что-то сложнее чем просто подстановку строки вместо слова — это учить его специфический язык... лет 20 это был самый извращённый язык из класса функциональных, хотя позже язык плюсовых шаблонов его перебил. Для примера можно посмотреть на предлагаемые реализации foreach — даже при наличии времени и вдохновения разбираться с его играми вокруг pushdef/popdef как-то стрёмно.
2. В принципе не предусматривается возможности "заэскейпить" символы квотинга. Вот если у тебя по умолчанию `' — ты не сможешь такие символы вставить в текст, вообще.
Для autotools это выливается, например, в то, что там квотинг заменён на [], и в результате в шелле нельзя использовать [, можно только test.
Лечится переходом на многосимвольный квотинг — я сделал в нашем проекте <* и *>, ну и очевидными методами "склейки" (даже просто написать <<**>* уже сработает, хотя выглядит ужасно).
vsb> Как-то применял, уж не помню точно для чего, но он свою задачу хорошо выполнил. А какой препроцессор лучше m4?
Смотря для чего и где. Если автоматизированно из языка программирования, то лучше смотреть на шаблонизаторы типа Jinja. Сейчас таких натворено для веб-серверов — десятки, и там достаточно правильных возможностей вплоть до вычислений и скриптований на ходу внутри блоков подстановок.
Здравствуйте, _NN_, Вы писали:
D>>А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому.
_NN>Обычно прямые слэши проблем не вызывают:
А теперь то же самое на уровне WinAPI, только добавить "\\?\", как рекомендуется тут чтобы не иметь проблем с длиной пути, с легаси типа невозможности работать с com1.*, aux.* и так далее... и всё сломалось.
То есть, чтобы с этим работать, надо всё равно все пути преобразовывать самим.
Это и есть — сделали через %опу "на отцепись".
Здравствуйте, Skorodum, Вы писали:
B>>Я вообще думаю, что человек смогший постичь XCode очень умный, но даже чтоб назваться очень умным такой подвиг совершать — не стану S>Интересно, про XCode хороших отзывов пока вообще не слышал. (Сам не пробовал.)
Я первым буду?
Кроме того, что он сам только под macOS, как инструмент разработки C++ вполне приемлемо.
Иногда, впрочем, они выпускают какие-то сырые версии (последней такой сырой версией была 9.0), которые часто крэшатся. Но вот сейчас у меня 10.1, она стабильна и вполне всем хороша.
Здравствуйте, 00011011, Вы писали:
0>Почему? Это вообще не затрагивает сам язык. Это просто обяжет всех разработчиков компиляторов и сред разработки следовать единой объектной модели проекта.
Дело в том, что еще с языка Си нет никакой модели проекта вообще, вернее модель одна, она сводится к компиляции одного большого файла, который получается после всех препроцессоров. Только недавно стали пытаться добавить на уровне языка модули. Линковщик так выходит, что за рамками стандарта (не считая некоторых директив). Это с одной стороны дает очень большую гибкость, с другой приводит к таким вот неприятностям.
M>>Что делать, если для одного проекта используется несколько языков?
0>Это как? Результатом является или исполняемый модуль, или библиотека. Если проект использует библиотеку, написанную на другом языке — то значит там внутри должна быть секция "зависимости", в ней "проекты, собираемые другими инструментами" и внутри массив этих внешних проектов (или массив пар ключ-значение: проект — инструмент).
Просто по определению не выйдет стандартизировать поведение сборщиков других языков. Но на самом деле все еще интереснее. Например, Qt строго формально вообще не на C++ написана. Используются некоторые расширения, которых нет в языке, а компилируется компилятором C++ только после того как специальный препроцессор (qmake) развернет их. И вот как это со стандартом совместить? Не говоря о том, что заставить комитет никого не может, следование стандарту в общем-то добровольное.
Здравствуйте, 00011011, Вы писали:
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта
Увы, нереально.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>В современных языках обычно так. В С++ вроде cmake стандарт де-факто, ну autotools это ещё юниксовое наследие. А что, старый добрый ./configure && make не срабатывает?
Мне нужно именно под студию собрать, чтобы поразбираться в коде, в отладчике походить и т.д.
Просто ради сборки я бы и заморачиваться не стал бы, скачал бы готовый бинарник и пользовался бы
M>>Что делать, если для одного проекта используется несколько языков? 0>Это как? Результатом является или исполняемый модуль, или библиотека.
Результатом является приложение, с конфигами, всеми файлами, вощем все что требуется для инсталляции. "исполняемый модуль, или библиотека" это лишь два вырожденных случая.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 00011011, Вы писали:
0>Зачем мне с этим разбираться?
Чтобы использовать эту библиотеку?
0>Смотрю там есть файл .pro. Вспоминаю что в Студии есть расширение для Qt, открываю через это расширение — открылось! Расширение сгенерировало solution. Пытаюсь пересборать — ошибка. Даже не компиляции, а какая-то мутная ошибка невозможности выполнить Custom Build для файла который нужно обработать программой moc. Опять фигня, не относящаяся к программированию никаким боком.
Согласен, но чтобы использовать Qt проекты нужно хотябы в базе знать как работает Qt сборка
0>В итоге я плюну на все это, и как делал уже не раз — заведу пустой проект в Студии, добавлю туда чистые исходники из скачанного проекта и получу нужный результат. Возможно не сразу, но получу. Для простых проектов обычно сразу получается, для больших и сложных — через несколько итераций.
Qt проект не соберется 0>Потому что чистые исходники на С/С++, написанные нормальным образом, как правило компилируются. Иногда приходится подправить какие-то мелочи, добавлять библиотеки которых у меня нет — но по крайней мере это все понятно, компилятор ругнется например на "нет такого-то инклуда" и я полезу его искать, найду и в итоге добавлю новую библиотеку в каталог с библиотеками.
0>Что я хочу сказать? 0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Возможно с появлением модулем мы будем двигаться в этом направлении, да и сейчас уже студия cmake понимает, так же из cmake можно сгенерировать проект для студии, с абсолютными путями, но доработав напильником можно жить.
Здравствуйте, Anton Batenev, Вы писали:
AB>Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make.
Здравствуйте, CreatorCray, Вы писали:
CC>Потому C++ под никсами всегда был болью.
Боль — это поддерживать сложную сборку под несколько ОС, компиляторов и IDE, но это задача реального мира и за нее хорошо платят
Чисто разработка не особо отличатся между платформами. За небольшими отличиями все более-менее одинаково. (В Студии отладчик хороший, но редактор и автодополнение — похуже, чем, например, в Креаторе, но это все не особо принципиально.)
CC>Особенно после полноценной VS.
В реальном мире МС переходит на линуховые тулзы, а не наоборот (CMake, git)
CC>Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке.
Студийные XML-солюшены это что угодно, но не "комфортная машина". Банально изменения в файле проекта не удобно смотреть.
CC>Вот только непонятно почему маршрутчики считают что это нормально и все должны страдать как они?
А не надо путать в кучу личные привычки и универсальное удобство
Если вам нужна разработка только под МС — так сидите на студийных солюшенах приковынные цепью к одной IDE
За возможность сборки на разных платформах/компиляторах/IDE приходиться платить.
Здравствуйте, 00011011, Вы писали:
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Считаю, что выделенный файл проекта вообще не нужен. Вся сборка должна описываться на самом языке программирования.
Здравствуйте, B0FEE664, Вы писали:
BFE> AB>Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make. BFE> Нет. Не собираются.
Скорее всего, ты просто чего-то не умеешь / не знаешь.
Здравствуйте, Michael7, Вы писали:
M>Бесплатные такие тоже есть. Я видел платные очень энтерпрайзные проекты такие, что это вообще кошмар сборщика. Например, часть файлов надо собрать в одной версии Delphi, часть в другой, потом кое-что из результата пропатчить в 16-ричном редакторе и продолжить сборку в еще одной версии Delphi. И все эти манипуляции толком не описаны, являются чуть ли не сакральным знанием.
Ага, я примерно такое на предыдущей работе видел, только под .NET. Проект из репозитория — реально на гигабайты, я только пока закончится чекаут из TFS пару часов дожидался. И он вообще не собирается, с кучей каких-то мутных ошибок. Огромная куча зависимостей от внешних либ, из них многие указаны в конфигах NuGet или проектах с неверной версией, а еще некоторые надо патчить вручную (где, что и как — нигде не написано). Куча развесистых скриптов, которые, естественно, постоянно падают с невнятными ошибками.
И самое забавное — что авторы всего этого чуда техники считали себя неимоверно отличными спецами, круче них только яйца.
Здравствуйте, PPA, Вы писали:
PPA>тоже не очень нравится когда нужно качать зависимости из разных мест. PPA>я все либы скидываю в один репозитарий, чтобы одним солюшеном собиралось сразу после git clone
Используй тогда уж сабмодули, чтобы не терять историю зависимостей.
Здравствуйте, Igore, Вы писали:
I>Согласен, но чтобы использовать Qt проекты нужно хотябы в базе знать как работает Qt сборка
Ты так говоришь, как будто это что-то хорошее. Все эти Qt-шные препроцессоры — это ж говно полное, и обман людей рассказами про плюсы. Только сумрачный красноглазый гений мог такое родить.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops> BFE>> AB>Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make. Ops> BFE>> Нет. Не собираются. Ops> AB>Скорее всего, ты просто чего-то не умеешь / не знаешь. Ops> Чего надо знать при "стандартных configure && make"?
Обычно ничего, но вот у ТС-а какие-то проблемы с этим и я почти уверен, что там тривиальная мелочь.
Здравствуйте, 00011011, Вы писали:
0>Это не программирование на С++, а черти что. Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
Как видим, тут достаточно знать CMake. Остальные системы сборки можно игнорировать.
0>Я наверное что-то делаю не так. Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.). И как правило именно так и получается. Все, никакого мусора. А тут — ну я не знаю что с этим делать.
Это подходит только для простеньких проектов — ну там курсовых работ, CD-ejector'ов и т.п.
Здравствуйте, Dair, Вы писали:
D>>>уже были GNU Make (1976) IID>>говно мамонта, которое за >40 лет так и не научилось поддерживать пробелы в makefile D>Ну, это, конечно, серьёзная проблема
Это отличная демонстрация подхода "а нам насрать что криво, как то шевелится и хрен с ним"
D>Но тезис коллеги CreatorCray'а был в том что "C++ под Unix плохо после полноценной VS". Я указал на то, что C++ под Unix был до, а иногда и задолго до MSVS.
Да насрать что там когда было. Вон, похожие идеи в телефонах были и до iPhone, но сделали всё удобно именно в Apple.
Так и с С++ — вижуалка сделала программирование удобным, а в nix продолжают пользоваться палками-копалками.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Я привык к отсутствию геморроя и необходимости превозмогать на пустом месте.
Это что сейчас было? Это такой толстый троллинг что-ли?
Как мне добиться отсутствия геморроя при практически любом мерже .sln и .vcxproj файлов? Как мне без нереального превозмогания понять по change'у в несколько сотен ( а часто и тысяч ) строк что вообще изменилось в системе сборки проектов? Почему порой даже небольшие изменения в проектах выливаются в гигантские change'и? Уже даже одно это — просто showstopper, что уж там говорить о массе других не менее серьезных проблем.
Да, как IDE студия была и сейчас остается вне конкуренции, но MSBuild как система сборки годиться только для проектов уровня laba2
Здравствуйте, CreatorCray, Вы писали:
D>>Ну, это, конечно, серьёзная проблема CC>Это отличная демонстрация подхода "а нам насрать что криво, как то шевелится и хрен с ним"
У Майкрософт же ровно то же самое — обратные слэши и отсутствие POSIX-совместимости — шевелится и хрен с ним.
D>>Но тезис коллеги CreatorCray'а был в том что "C++ под Unix плохо после полноценной VS". Я указал на то, что C++ под Unix был до, а иногда и задолго до MSVS. CC>Да насрать что там когда было. Вон, похожие идеи в телефонах были и до iPhone, но сделали всё удобно именно в Apple. CC>Так и с С++ — вижуалка сделала программирование удобным, а в nix продолжают пользоваться палками-копалками.
Потому что Microsoft потратила деньги чтобы сделать себе IDE чтобы лучше продавать Windows.
Вот почему-то никто не потратил денег чтобы сделать IDE под *nix. А ты обвиняешь почему-то платформу, хотя она-то вообще ни при чём.
Сами по себе как-то появились Eclipse, Netbeans, Code::Blocks и Qt Creator. А теперь и платный CLion.
Здравствуйте, Ops, Вы писали:
Ops>Ты так говоришь, как будто это что-то хорошее.
Оно не хорошее и не плохое. Оно работает и альтернативы ему особо нет. Никакой проблемы в промежуточном шаге сборки нет, т.к. любая сборка за пределами main.cpp в любом случае это несколько шагов.
Ops>Все эти Qt-шные препроцессоры — это ж говно полное, и обман людей рассказами про плюсы.
В чем там обман? В том, что на голых плюсах этого не сделать?
Ops>Только сумрачный красноглазый гений мог такое родить.
Других особо и не было когда Qt начиналась (1991).
Здравствуйте, Voivoid, Вы писали:
V>Как мне добиться отсутствия геморроя при практически любом мерже .sln и .vcxproj файлов? Как мне без нереального превозмогания понять по change'у в несколько сотен ( а часто и тысяч ) строк что вообще изменилось в системе сборки проектов? Почему порой даже небольшие изменения в проектах выливаются в гигантские change'и? Уже даже одно это — просто showstopper, что уж там говорить о массе других не менее серьезных проблем.
+1
V>Да, как IDE студия была и сейчас остается вне конкуренции, но MSBuild как система сборки годиться только для проектов уровня laba2
Студия вне конкуренции только в отладчике. Без плагинов (зачастую платных) она проигрывают во многом QtCreator.
Еще сюда добавить что понятие "инфраструктура-как-код" у МС вообще недоразвито. Когда можно будет в голой винде в командной строке автоматически установить компилятор?
Здравствуйте, Sharowarsheg, Вы писали:
F>>прибежали люди, которые не осилили, потому и требовали запретить-не-пущать. ни альтернатив, ни логики... S>То, что они не осилили, а также то, что они не предложили альтернатив, не отменяет того, что со сборкой дела обстоят не совсем хорошо (чтобы не сказать срань господня).
это и называется "отсутствие логики в заявлении". совершенно не аргументированно
F>>осиляторы же аргументировали тем, что за эти навыки платят. и не то, чтобы это было плохо. S>Ещё более приятный вариант, когда ты делаешь что-то настолько сложное, что никто нихрена не может в этом разобраться. По мере того, как ты всё более и более усложняешь это нечто, ты получаешь всё больше и больше денег, и порог входа всё больше и больше. Это прекрасно работает, пока не кончается.
в реальности всё наоборот.
мир изменился настолько, что инструмент нужен только для поддержки небольшой части юзеров. зачастую это дистро-строители или работающие со старыми системами
никто не придумывал autotools специально, чтобы унизить и так слабых программистов. инструмент просто решал свои задачи.
F>>если же мы будем себя ограничивать чьими-то хотелками, то не сможем дать юзерам те вещи, которые им нужны. F>>я понимаю, что в волшебном шиндовс-мирке есть только вижуалка и софт учёта склада, но в реальности есть много других потребностей. S>В волшебном виндовс-мирке есть дофига всего, вообще говоря.
Здравствуйте, Ops, Вы писали:
D>>Да, Microsoft это добавил то ли в XP, то ли в 2000, не помню. Ops>А красноглазое ниасилило, ибо к людям всегда жопой, а не лицом.
зато пользоваться можно без боли
сейчас же гиганты больше в сторону красноглазых решений перетягиваются
т.е. понимаешь, где остриё прогресса, а где отсталость и запустение
Здравствуйте, Ops, Вы писали:
Ops>А красноглазое ниасилило, ибо к людям всегда жопой, а не лицом.
"Жопой" это когда нельзя автоматически установить toolchain для С++ одной командой на голой ОС.
Здравствуйте, Skorodum, Вы писали:
S>>То, что они не осилили, а также то, что они не предложили альтернатив, не отменяет того, что со сборкой дела обстоят не совсем хорошо (чтобы не сказать срань господня). S>Да на самом деле отлично дела со сборкой обстоят: нормальные проекты сейчас собиаются из единого файла проекта под разные платформы и разными компиляторами. Поддерживать это объективно сложно
Мне периодически приходится по необходимости собирать опенсорцные проекты под винду, и нет, обычно не собирается. Можно себе представить, что я не имею дела с нормальными проектами (не исключено), но результата это не меняет — всё равно без плясок не собирается.
S>>Ещё более приятный вариант, когда ты делаешь что-то настолько сложное, что никто нихрена не может в этом разобраться. S>Никто это "Слава", CreatorCray и ТС
Ну, ещё я, и еще куча народу, которая молчит. А другая куча закопала миллион человеко-часов на разибирательства. Я даже не уверен, что из этого хуже.
S>>По мере того, как ты всё более и более усложняешь это нечто, ты получаешь всё больше и больше денег, и порог входа всё больше и больше. Это прекрасно работает, пока не кончается. S>Это подход МС: сделать сложно и залочить всех.
Это подход всех, насколько я вижу. Всем денег хочется, ну или возможности попонтоваться.
Здравствуйте, Skorodum, Вы писали:
S>Разговор-то про то, что используя нормальные средства эту проблему решить можно. И большинство решений пришли из open-source мира. МС сильно отстает в этой области, а порой и целенаправленно тормозит. Аpple тоже.
S>>Это подход всех, насколько я вижу. Всем денег хочется, ну или возможности попонтоваться. S>Да и это понятно. Не нормальны стенания адептов Win CMD, которым не нравится мир за пределами их песочницы.
Почему не нормальны. Я вот скажем, пишу под Windows. Не знаю, причём тут CMD, но вот эти всё дикие сборочные скрипты мне не нравятся. Не то, чтобы я стенаю по этому поводу, но если тема зашла, то я вполне могу сказать, что это костыли, подпёртые костылями, унаследованные через поколения теперь уже людей, а не софта. Иногда кто-то соизволит в исходники включить файл проекта для MSVS, тогда ещё куда ни шло, и то не всегда.
Здравствуйте, neFormal, Вы писали:
F>кто в 2019м ещё пользуется вижуалкой? F>это ж копролит эпохи доткомов. когда животные впервые вышли на сушу.
По существу не полностью согласен, но это плюсую за ответ в духе IID и CratorCray.
Здравствуйте, neFormal, Вы писали:
F>магазин, цена, распространённость.
Лучше бы этого магазина вообще не было. Как и кучи ограничений, с ним связанных. Централизация, цензура и реклама в каждом втором приложении, которая оказывается ещё и выгоднее для создателя программы, чем продажа за деньги.
Здравствуйте, IID, Вы писали:
IID>Ты не ответил на вопрос. КАЖДАЯ сборка ? IID>Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ?
Да, это сейчас нормальная и рекомендуемая практика.
IID>ЗАЧЕМ ? (Кажется кто-то заврался.)
Для того, чтобы исключить взаимное влияние разных билдов.
Здравствуйте, Sharov, Вы писали:
C>>В MSVS поддержка всех комбинаций потребует 16 вариантов сборки (Debug/Release * 8 комбинаций). И это только в одной библиотеке! S>Я cmake не знаю, но как он решают эти пробелмы? Т.е. по факту у нас действительно 8 комбинаций, Debug/Release переключается по шелчку. Как cmake помогает избежать 8 комбинаций?
В текущем виде, действительно, никак (по крайней мере без рукописных надстроек и велосипедов).
У симейка, вообще, есть серьёзные проблемы, которые пока никому не известны, если глубоко не копать.
К примеру, это: https://gitlab.kitware.com/cmake/cmake/issues/18946
Из-за этого косяка ничего уже нельзя поменять, потому-что by design, и если начать исправлять, то сломается вообще весь cmake. Тут только поможет одно: взять и выкинуть старьё и написать заново. Но придётся переписать все существующие модули и скрипты, что просто нереально!
Как результат парсеры на cmake пишутся через большую Ж. А без парсинга там делать особо нечего, потому-что вокруг и около постоянно какие-то списки данных, структуры и строки. А как ты будешь что-то парсить, если у тебя контейнер строка и контейнер список, это одно и тоже? Тупик.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Skorodum, Вы писали:
S>Отличное высказывание. Хорошо описывает природу бурных эмоций "Славы" и CreatorCray.
Ты похоже понял эту фразу как то по своему.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
S>Еще сюда добавить что понятие "инфраструктура-как-код" у МС вообще недоразвито.
Дык и не надо. Тут подходы просто другие.
S> Когда можно будет в голой винде в командной строке автоматически установить компилятор?
А нахрена? Мне не надо голый компилятор, я не хочу хреначить в vi
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>>>Карго культ какой то. C>>Это современная практика в нормальных проектах. CC>Это попытка прикрыть кучу говна руками.
И чем её заменить? Идеальными программистами в вакууме?
C>>Гарантия того, что проект собранный вчера будет работать точно так же, как и проект собранный сегодня. CC>Только если в проекте пц и бардак до такой степени что его нельзя пересобрать 2 раза подряд и получить одно и то же.
Нет. Нужна гарантия, а не "мамой клянусь". Каким образом будем ГАРАНТИРОВАТЬ это?
C>>Потому, что люди ошибаются. И вместо "touch $(PREFIX)/testfile" пишут "touch $(PREFIX) /testfile". CC>Ну а таким образом баг не чинится а заметается под коврик CC>Оно то кое как работает, но воняет некомпетентностью.
Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC.
C>>Ровно как защита памяти — можно же всё идеально писать, нафига защита памяти некриворуким программистам?!? CC>Напомню что защита памяти приводит к exception и panic если кто то пытается её нарушить.
Вот! Просто заметает ошибки под ковёр! Идеальные программисты ошибок не допускают.
CC>А тут воткнули catch (...) на самом верхнем уровне и решили exceptions ловить больше нигде не надо.
Кстати, после этого случая добавили тест, что финальный слой в Docker'е (т.е. результат постройки) не может иметь новых файлов за пределами префикса.
Как в варианте "тонна копролита, которую Вася настроил руками через RDP" достичь этого?
Здравствуйте, Skorodum, Вы писали:
CC>>Там в итоге бинари подписываются, так что хеши будут всегда разными просто по определению. S>С чего этого? Время сборки включено в процесс подписывания? https://en.wikipedia.org/wiki/Code_signing#Time-stamping
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>Потому, что люди ошибаются. И вместо "touch $(PREFIX)/testfile" пишут "touch $(PREFIX) /testfile".
А это то самое, про что я выше писал. Культура, которая обусловлена средой разработки. Ошибка действительно типовая, вот только вылавливаться она должна компилятором. А для sh компиляторов не бывает, не написали. Зачем инженеру компилятор.
Здравствуйте, ·, Вы писали:
·>Ты немного путаешься.
Нет.
·>"Сборка должна работать" — это значит взяли новый сервак, поставили в стойку, запустили командочку "do all" и проект собрался. А не так, что надо Васе-старшему-разработчику (т.к. это только он знает) провести пару недель в RDP, устанавливая нужный софт, прописывая переменные окружения, конфиги и пути.
И что мешает так сделать? То, что ты не знаешь, как? Ну так оно легко гуглится, студию можно установить в 2 строчки. Твой "do all" ведь все равно скриптовать надо?
·>"git должен работать без всякого мусора" — а вот это зачем? Что это даёт?
А что дает вырезание GUI из студии, за которое вы радеете?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Тебе явно чем-то мешают IDE и GUI
Проблемы с чтением и художественная резьба по цитатам? Требовать наличия IDE для сборки — этот тупиковый путь и даже у МС есть подвижки в этом направлении.
Ops>А CLI, не использующий GUI, там есть, непонятно только, чем плох — ты это в секрете держишь.
Плох тем, что его установку трудно автоматизировать.
Здравствуйте, Ops, Вы писали:
C>>Нет. Нужна гарантия, а не "мамой клянусь". Каким образом будем ГАРАНТИРОВАТЬ это? Ops>А как ты будешь гарантировать работу в реальном окружении, которое не обнуляется каждый час или день?
Обнулять рабочее окружение каждый день
Здравствуйте, CreatorCray, Вы писали:
CC>>>Это попытка прикрыть кучу говна руками. C>>И чем её заменить? Идеальными программистами в вакууме? CC>Хехе, что, набрали кого смогли?
Ну так чем заменять будем? Люди имеют свойство ошибаться. В том числе и мега-гении из Apple — см. Touchbar.
C>>Нет. Нужна гарантия, а не "мамой клянусь". Каким образом будем ГАРАНТИРОВАТЬ это? CC>Так ты просто прячешь баги, какие ещё гарантии? Только что ком говна будет незаметно рости.
Гарантии в том, что билд будет ВСЕГДА повторяемым. Сейчас идёт работа над идеальной повторяемостью — чтобы артефакты можно было с точностью до бита повторять.
C>>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC. CC>И вы решили кривософт оставить как есть и сделать вид что это ок?
Нет, пока нашли — пропустили несколько багов.
C>>Вот! Просто заметает ошибки под ковёр! CC>Программа навернулась с access violation. Это не заметение под ковёр, это как раз наоборот обосратушки всем на обозрение.
Вот! Заметание! Нормальные программы не должны с AV падать. AV должен вызывать взрыв компьютера у того, кто допустил ошибку.
C>>Как в варианте "тонна копролита, которую Вася настроил руками через RDP" достичь этого? CC>Вообще надо начинать с избавления от тонны копролита CC>Запрети процессу билда запись куда либо кроме target folder. Любыми доступными тебе способами.
Есть и другие проблемы. Например, мега-гений может установить другую версию MSVS на хост, с другими багами.
Здравствуйте, Cyberax, Вы писали:
C>Ну так чем заменять будем? Люди имеют свойство ошибаться.
Теми, кто может
C>В том числе и мега-гении из Apple — см. Touchbar.
Тачбар придумывали не программисты, надеюсь им икается.
C>Гарантии в том, что билд будет ВСЕГДА повторяемым. Сейчас идёт работа над идеальной повторяемостью — чтобы артефакты можно было с точностью до бита повторять.
Может просто надо прекратить порочные практики, которые приводят к тому что билд рушит свой же environment?
CC>>Программа навернулась с access violation. Это не заметение под ковёр, это как раз наоборот обосратушки всем на обозрение. C>Вот! Заметание! Нормальные программы не должны с AV падать.
Ну так у вас программа вместо того чтоб на тестах с AV упасть просто молча exception схарчит. Просто потому что вы за ней тут же прибираете и насранную кучу увидеть не сможете.
C>Есть и другие проблемы. Например, мега-гений может установить другую версию MSVS на хост, с другими багами.
У вас настолько бардак в билдсистеме?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, IID, Вы писали:
IID>Открой для себя пропсы. Делается пропс, подключается к желаемым конфигурациям. Все. Можно любые настройки так подключать, не только пути. Изменение в пропсе аффектится сразу на все.
Я просто когда то закрыл для себя студии новее 2008й. VAX покрывает практически все нужды в intellisense, а компилер прикручен сторонний.
На работе же сейчас гнусный XCode
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, _Raz_, Вы писали:
_R_>Здравствуйте, Skorodum, Вы писали:
S>>А тебе слабо? Вот есть голая винда. Как автоматизировать установку git/CMake/компилятора? _R_>
_R_>https://chocolatey.org/
1. Выделил. Нет на голой винде choco
2. Опять же устанавливается компилятор от "осилиторов". Так что это аргумент больше в пользу "осиляторов", а не МС
Здравствуйте, Cyberax, Вы писали:
C>Так как вся среда у нас полностью детерминирована, то ошибку нашли бисекцией за пару часов. В случае твоего любимого варианта: "куча копролита" это сделать было бы невозможно. Так как копролит не бисектится — это куча, данная в ощущениях.
Мне вообще странно, что людям, занимающимся разработкой ПО за деньги, надо объяснять преимущества подхода Infrastructure as code
Здравствуйте, IID, Вы писали:
IID> Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ? ЗАЧЕМ ? (Кажется кто-то заврался.)
Удивляет, что кто-то <пока еще> так НЕ делает и еще умудряется этим хвастаться.
Здравствуйте, Anton Batenev, Вы писали:
AB>Удивляет, что кто-то <пока еще> так НЕ делает и еще умудряется этим хвастаться.
Ничего удивительного. Буханке не доверяют даже её одепты. Отчаявшись искоренить дерьмо — смирились с участью вечного подтирания жопы. Дискуссия Cyberax-а и CreatorCray очень показательна.
Здравствуйте, Skorodum, Вы писали:
S> ..., но и QtCreator, который во многом получше Студии будет. Засуньте свой QtCreator с его отладчиком в одно место.
На работе есть один достаточно нехилый по размеру проект (около 50 .pro файлов).
Так вот он в отладке просто еле шевелится. Народ "дебажит" через логи
А основной аргумент со стороны руководящего звена в пользу QtCreator был вообще отпадный:
"Мы покупаем библиотеку Qt, а так там уже есть QtCreator, то разрабатываем на нём."
Здравствуйте, Ops, Вы писали:
I>>Согласен, но чтобы использовать Qt проекты нужно хотябы в базе знать как работает Qt сборка Ops>Ты так говоришь, как будто это что-то хорошее. Все эти Qt-шные препроцессоры — это ж говно полное, и обман людей рассказами про плюсы. Только сумрачный красноглазый гений мог такое родить.
Реальность она не плохая или хорошая, она просто есть, тоже самое справедливо и для protobuf, odb, и других библиотек которые используют кодогенерацию, и если тебе хочется упростить себе жизнь используя их, то нужно их знать хотя бы на минимальном уровне, вот в С++23 может появится reflection, и тогда можно начинать говорить что можно бы все это сделать на чистом С++. А так тебя никто не заставляет использовать Qt, берешь WxWidget или еще что нибудь и вперед, не уверен правда что это будет проще, но более чисто как ты хочешь.
Здравствуйте, Anton Batenev, Вы писали:
AB>Какое дремучее невежество... По ощущениям от прочтения данной подветки ты и компания отстали от индустрии (при чем безотносительно ОС) лет на 15+.
Не надо выдавать нужду за добродетель.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, ·, Вы писали:
IID>>установка КЕМ-ТО софта на билд сервер для решения своих задач ·>Любопытно. А откуда у вас софт на билд-серверах появляется?
Биткоин майнеры "для решения своих задач" на билд серверах не появляются совсем
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
S>У нас нет физических серверов, а установка ПО, это строчки кода в исходниках проекта, вся история полностью отражена в системе контроля версий.
Строчки кода и переустановка при каждом билде это ортогональные вещи.
IID>>Права нарезать не могут, ошибку найти не могут. S>Права доступа тут проблему не меняют никак. Всегда есть люди которые могут что-то изменить без особых следов.
Какой бардак
IID>>Могут только переустанавливать. S>Могут автоматизировать и документировать процесс на 100%.
Нет, не могут. Могли бы — сделали бы последовательные билды стабильными. Без костылей с полной переустановкой.
Здравствуйте, IID, Вы писали:
IID>·>Т.е. у вас происходит именно это: "установка КЕМ-ТО [2-3 человека] софта на билд сервер для решения своих задач [задачи билда]". Верно? IID>Верно. Только существенную часть ты в скобки поместил.
Т.е. кликать мышой в RDP можно (лишь бы рука не дрогнула). А описать в виде скрипта — внезапно дыра в безопасности. Ну точно подвал в НИИ и турбопаскаль.
IID>>>Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности. IID>·>А какая должна быть идея о том что там можно запускать и как это контролируется? IID>Самое простое и правильное — билсервер никогда и ничего не исполняет из репозитория.
Почему? (Хинт: репозиториев можно ВНЕЗАПНО иметь несколько — для кода проекта и для инфраструктуры. У разных репов могут быть разные права доступа, способы верификации, ревью, sign-off изменений).
А как это у вас контролируется? Лишь бы рука не дрогнула?
IID>Если очень надо — придётся кропотливо настраивать права. Чтобы исполяемое могло сделать ровно то, что ему разрешено. И то это не панацея, LPE никто не отменял. IID>А тут вы бессильны, потому как даже пробел в пути диагностировать не можете (из обсуждения выше), предпочитая сносить всё дотла.
Как вы это диагностируете?
IID>Ты просто представь на секунду, что такой бардак случится в каком-нибудь Apple, MS или Google ?
Гугл вроде как один из пионеров IaC.
IID>Достаточно устроиться сотрудником, и через заливки в GIT можно атаковать билдсервер, красть сертификаты (или хотя бы подписывать свой код ими), ослаблять шифрование, вносить закладки (невидимые, вносимые в момент компиляции пропатченным в памяти компилятором).
У вас что, в любой репо любой сотрудник может заливать всё что угодно? Вот и нашли в чём у вас проблема. Чините.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IID, Вы писали:
IID> Достаточно устроиться сотрудником, и через заливки в GIT можно атаковать билдсервер, красть сертификаты (или хотя бы подписывать свой код ими), ослаблять шифрование, вносить закладки (невидимые, вносимые в момент компиляции пропатченным в памяти компилятором).
Для этого тебе придется войти в сговор с очень большим числом людей (что теоретически возможно, но на практике практически нереально), а воспроизводимые сборки позволяют разрывать контур внесения "ошибки" практически в любом месте и достаточно дешево.
Билд-сервер (во "взрослой" компании) — это не одиночная физическая машинка, а сотни и тысячи физических серверов на каждом из которых может быть запущено множество разнообразных задач (сборки, тестирования, разработки и т.д.) в разной степени изоляции. Никто не ходит на эти сервера по ssh, ничего не устанавливает/обновляет/настраивает — их в 99.99% случаев обслуживает автоматика.
Здравствуйте, Cyberax, Вы писали:
C>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC.
И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах.
Здравствуйте, IID, Вы писали:
S>>Код описывает всю инфрастуктуры и все шаги для сборки, и это часть проекта. IID>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Чтобы 100% гарантировать, что текущий билд никак не зависит от предыдущих. Это самый простой и дешевый способ. Очевидно почему?
IID>Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Это никакой гарантии не даёт. Думаю, что очевидно почему.
IID>Кроме того сборка на билд-сервере может существенно отличаться от сборки на машинах разработчиков.
И что? Разработчики обычно разрабатывают как им удобно, нередко каждый по-своему.
IID>Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации.
Угу. И соответственно отдельные репы с ограниченным доступом.
S>>У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще. IID>Они не устанавливают на билд-сервер что-попало, в отличе от вас.
Они устанавливают что получится как попало куда попало.
S>>Минусы вашего подхода очевидны, но вы с Креатором упираетесь почему-то. IID>Да бог с ним, с нашим подходом. Вы сначала сумейте показать плюсы своего.
Полный контроль над процессом билда и окружением, история всех изменений, привычный процесс внесения изменений (пулл-реквесты, ревью и т.п.). Элементарно делать откаты к любой версии. Диффы, надёжная структурированная история. Безопасные эксперименты. Восстановление окружения с нуля (сдохло железо — не беда, нажали кнопочку — всё снова поднялось на другом серваке). Масштабирование (как эти твои 2-3 человека вносят гарантированно идентичные изменения на нескольких билд-серверах?)
В общем, я не понимаю, почему надо рассказывать о преимуществах vcs вроде бы взрослым людям.
IID>Пока что заметно только раздутое ЧСВ и упорное нежелание конструктивно отвечать (тот же пример с замыливанием ошибки).
Вот тут
человек вообще согласился, что одна ошибка — не считается.
Если хочется, то девовские билды можно делать инкрементально и ловить такие баги, а релизные — с нуля.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Образ ВМ, снапшоты? Не, не слышал.
Это решение, но не идеальное: как документировано состояние ВМ? Нет никакой гарантии, что описанный процесс сборки в каком-нибудь README.md и ВМ полностью соотвествуют друг другу. ВМ полностью отвязана от проекта.
Следующий логичный шаг после "ВМ и снапшотов" это создавать ВМ или контейнеры из описания, которое хранится в самом проекте. Всякие Travis, Azure, и прочие GitLab эту задачу и решают.
Здравствуйте, IID, Вы писали:
IID>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Если делать через docker, промежуточные шаги кешируются и образы переиспользуются. Если не было изменений в пререквизитах то время тратится только на последний билд-степ.
IID>Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Здравствуйте, Skorodum, Вы писали:
НС>>Оно куда идеальнее, чем накатывать на голый образ тулы при каждой сборке. S>Это уже детали реализации.
S> При использовании тех же контейнеров
Вы прям как то дружно с Кибераксом потеряли контекст.
НС>>Если тебя одолевает паранойя по поводу того, что враги подменят образ внезапно, то всегда можно собирать образ/контейнер при помощи того же CI, но строго только при изменении скриптов подготовки ВМ. S>Дела не во врагах, а в следовании DRY принципу. Инфраструктура для сборки должна быть кодом и должа быть частью проекта.
J>Кого ты там обязывать собрался? И чем? Многие компиляторы вообще — консольные утилиты, которому ты просто указываешь имя файла с исходником, а он тебе объектный файл выдаёт. Вот так просто, и ничего больше.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах. I>>Одна ошибка раз в год может спокойно перевесить суммарную стоимость всех билдов вместе взятых.
НС>Вопрос не в стоимости, вопрос в трате времени разработчиков. Ну и с такой паранойей надо не С++ использовать точно, ибо шансов наломать дров в коде намного порядков больше, чем в криптах сборки.
Такое применяется вне зависимости, с++ или нет. Нужны гарантии, что билд, деплой, и тд запустится в чистом окружении.
Здравствуйте, Ikemefula, Вы писали:
I>А ты в курсе, что у разных проектов приоритеты разные ? У одних цена ошибки считается миллионами долларов или даже жизнями
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Так это ж "мутные файлы" и идиология от "осиляторов" НС>Это к ТС. Речь про apt зашла совсем в другом контексте.
Да в этой ветке уже сложно найти хоть какую-то связанную мысль
S>>З.Ы. MS приходит к тому, что есть у "осиляторов" уже 5+ лет. Так и до вас с IID дойдет НС>Ну да, куда ж без красноглазого хамства.
Вот честно, лень искать сейчас по топику, но тон тут задал "про-MS" лагерь в лице ТС, "Славы", IID и CreatorCray.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Используют в том числе и плюсы
НС>Конечно. Как аргументы заканчиваются — сразу всплывают разработчики АЭС. Закон Годвина для КСВ.
Какие еще АЭС? Стоимость билдов вместе взятых на обычном проект это деньги сравнимые с ЗП одного разработчика за тот же период. То есть, сумма в масштабе бизнеса очень маленькая.
Вот скажем софт для оператора такси, если он глючит, то всего за вечер суммарные потери превысят заработок всей команды за месяц. 1000 таксистов недополучит по 1000 рублей заказов. А это ЗП трех-четырех девелоперов в месяц. 1000 такси это совсем небольшое количество.
С торговыми точками, складами, доставкой, логистикой и тд все гораздо веселее.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот только основной код системы, как правило, на порядки больше и на порядки сложнее. НС>В результате вероятность появления багов в нем на много порядков выше. Но вы жертвуете временем билда чтобы наловить каких то очень редких блох, заметляя фикс в основном коде. Логика.
Это не столь очевидно. Процесс сборки это склейка/использование нескольких больших и очень сложных систем (система сборки, компиляторы, etc). И сложность там растет совсем не ленейно. Собственно весь топик об этом: если надо сделат HelloWorld под Win, то все просто и в студии, а если надо кроссплатформенный HelloWorld, то все становится намного веселее, а если надо несколько библиотек, кодогенерацию, подписи, etc, то все становится совсем весело и вероятность ошибки довольно велика (зачаствую из-за внешних багов или "фич").
Еще такой момент: с языком программирования программист обычно работает каждый день и более менее знает, а вот средства которые используются раз в полгода — приходиться гуглить, поэтому вероятность ошибки нельзя сравнивать просто по количеству кода.
Здравствуйте, Skorodum, Вы писали:
S>Это не столь очевидно. Процесс сборки это склейка/использование нескольких больших и очень сложных систем (система сборки, компиляторы, etc). И сложность там растет совсем не ленейно. Собственно весь топик об этом: если надо сделат HelloWorld под Win, то все просто и в студии, а если надо кроссплатформенный HelloWorld, то все становится намного веселее
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, Marty, Вы писали:
D>Я не фанат Creator'а, но он мне более интуитивно понятен чем Студия.
D>В Студии я вообще не понимаю как этим пользоваться до сих пор — нет привычки.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>По твоему, Селениум тесты это проблема в языке ?
НС>По моему кто то не умеет цитировать.
По моему кое кто отвечает только на удобные вопросы.
НС>И какой смысл задавать одн и и те же вопросы, если я на них уже ответил? Забыл что один раз на это сообщение уже ответил?
Например, ты скипнул вопрос: "Каким образом язык вынуждает людей спихивать сложную работу на низкоквалифицированых разработчиков ? "
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Да и при нормалном инструментарии, налаженном процессе и прямых руках разработка на плюсах ничуть не медленнее, чем на каких-нибудь C# или Java (особенно в областях где оснавная часть кода это алгоритмы, а не формы). НС>Ну да, только почему то приходится при сборке каждый раз все с нуля накатывать, абы чего не вышло.
Язык тут ни при чём.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, bisoft, Вы писали:
D>>В Студии я вообще не понимаю как этим пользоваться до сих пор — нет привычки. B>Это просто не надо было портить себе мозг XCode
В далёком 199забытом году мои одно-тогда-ещё-группники испортили себе мозг Windows'ом и Visual Studio. А я начал писать под Linux. Xcode — это уже потом. Да и Qt Creator потом. Основные инструменты — vim и gdb.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Ты пишешь, что язык только усугубляет проблему. Это и ежу ясно. Но что бы язык усугубил проблему, она должна откуда то взяться.
НС>Иногда количество переходит в качество.
Общие слова. То есть, аргументов нет.
I>>Так каким образом язык вынуждает людей спихивать сложную работу на низкоквалифицированых разработчиков ?
НС>Обычным. Чем нуднее и скучнее работа, тем больше соблазна спихнуть его на джуна, который прав не имеет.
А язык тут при чем? Ты описываешь ситуацию, когда проект пустили на самотек. Виноват в этом почемуто язык. Почему — в ответ только общие слова.
Здравствуйте, Ikemefula, Вы писали:
I>А язык тут при чем? Ты описываешь ситуацию, когда проект пустили на самотек. Виноват в этом почемуто язык. Почему — в ответ только общие слова.
Нет, я ответил вполне конкретно почему. Если тебя мой ответ не устраивает (а тебя, очевидно, устроит только один ответ) — ничем помочь не могу.
Здравствуйте, AlexGin, Вы писали:
AG>P.S. Чтобы всё это хозяйство не конфликтовало, ставим в хронологическом порядке — AG>т.е. сначала ставим студию 2013, а в самом конце — ставим 2017-ю.
А если надо позже добавить более раннюю? (а это более чем реальный и частый вариант запроса)
Всё переустанавливать? Ну гениально, чо.
Здравствуйте, Dair, Вы писали:
D>>>Да, Microsoft это добавил то ли в XP, то ли в 2000, не помню. Ops>>А красноглазое ниасилило, ибо к людям всегда жопой, а не лицом. D>Потому что "красноглазое", как ты выражаешься, не имеет единого центра принятия решений. В отличие от Microsoft.
У Microsoft тоже с этим не ладно Шизофрение дульче мелодие — в полный рост.
Но когда прижимает, да, они кое-как приходят к ответу. Unix тоже, но сам процесс выглядит иначе.
Здравствуйте, CreatorCray, Вы писали:
D>>А я начал писать под Linux. Xcode — это уже потом. Да и Qt Creator потом. Основные инструменты — vim и gdb. CC>В приличном обществе не принято говорить о подобных извращениях!
VIM нынче умеет автодополнение, навигацию, рефакторинги. GDB с плугинами на Питоне тоже вполне можно использовать. Непривычно после IDE, но вполне себе эффективно.
Здравствуйте, netch80, Вы писали:
N>Либо, наоборот, от достаточного количества опыта и понимания, что если начинался C++ ещё нормально, то то, что происходило позже, это типичная ситуация полёта тачанки со взбесившимися конями с обрыва, когда спрыгивать невозможно, и единственное, что остаётся — кричать "Уррраа!!!"
Это совсем другая проблема, совершенно ортогональная тому, что для многих задач альтернатив С++ нет и "выбором курильщика" будет использование практически любого другого языка для подобных задач.
N>В некоторой степени такая проблема есть у всех, но у C++ она в разы сильнее, чем у аналогов-конкурентов.
За С++ нет какой-то компании или одного человека, "естественная эволюция" со всеми плюсами и минусами
N>Ну, да, есть. Только пока что 99% случаев это "уже есть мегатонна кода на C++, мы не можем её переписать", и только 1% на "нет альтернатив". Для C вторая цифра заметно больше — процентов, может, 20.
За исключением деталей утверждение верное для любых других языков в не меньшей степени, но зачем переписывать и использовать другие языки?
N>Но обе ужимаются на глазах — от их областей отгрызают по кусочку и Java/C#, и Rust, Go, Swift, и прочие.
Не, первые два сейчас в основном отгрызают кусочки друг у друга, остальные создали новую нишу. Нет особой конкуренции, так сильные стороны языков достаточно очевидны. Это симбиоз, особенно яркий пример: С++ и python.
Здравствуйте, netch80, Вы писали:
N>А вот про cmake можно было бы уже и подумать. Но раз cmake умеет делать проект для VS, то уже есть на что смотреть (если можно поверх такого проекта, не патча его, собирать с доп. опциями).
Это уже прошлое. Сейчас CMake умеет работать а-ля сервер и IDE должна просто спросить что ей нужно знать о проекте. Примерно как language server protocol.
Здравствуйте, bisoft, Вы писали:
B>Ну тогда все еще хуже Даже в далеких 199х много раз пробовал самые разные операционки, но так и не пришел к такому — да чего там мучиться набил в виме пару экранов текста и все, что надо получил B>Меня всегда веселит, когда какой нибудь линуксоид говорит — да в линуксе ставить программы просто и демонстрирует — набрав строчку абаракадабр
А искходный код для вас тоже абаракадабра и программируете вы кидая формочки с помощью мышки?
B>Или рассказывает про отладку упоминая gdb, даже в 90х был борландоский турбодебагер, после которого даже на софтайс смотреть не хотелось, хоть и возможностей в нем было больше
Только вот gdb жив, а Borland умер
B>Я вообще думаю, что человек смогший постичь XCode очень умный, но даже чтоб назваться очень умным такой подвиг совершать — не стану
Интересно, про XCode хороших отзывов пока вообще не слышал. (Сам не пробовал.)
Здравствуйте, Skorodum, Вы писали:
S>Интересно, про XCode хороших отзывов пока вообще не слышал. (Сам не пробовал.)
Да потому что она counterintuitive. Пойдёт после vim/gdb но после вижуалки вызывает недоумение как можно так всё плохо сделать имея примеры как надо делать хорошо.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>>>Вот, скажем, для Тайпскрипта студент на коленке может налабать препроцессор для определенных нужд.
S>>А зачем студенту делать что-то на C++? С какой целью?
I>Что бы стать С++ разработчиком надо писать на С++. Или у вас там всё иначе устроено, типа "пишу на питоне, хопа, уже С++" ?
Если человек учится на "С++ разработчика", то зачем сравнение с каким-то TypeScript?
Зачем на C++ писать "препроцессор для определенных нужд"?
I>>>Специфика есть, но вот экономика сильно не в пользу плюсов.
S>>На каких проектах (в смысле из какой предметной области)?
I>В разных.
Ну а конкретнее? Очевидно, что C++ подходит далеко не для всех задач. Благо, с начала 2000-х на C++ уже перестали писать все подряд. Соответственно, C++ остался там, где он нужен. И поэтому интересно, где же при этом экономика сильно не в пользу плюсов?
Здравствуйте, Ikemefula, Вы писали:
I>А что, трудоёмкость учитывать не надо?
Пользователю мало того что не видно как устали те, кто это писал, так ещё и не интересно.
I>"Сделали хорошо" почти всегда означает — "долго думали и тщательно имплементили" MSVS вот такая потому, что в неё закопаны два десятка лет работы тысяч разработчиков, а до того это были отдельные тулы, в каждый из которых было закопано лет десять-пятнадцать сотен разработчиков.
Эта работа уже проделана — смотри на результат и учись.
I>То есть, в обозримом будущем у XCODE ни единого шанса приблизиться к вижле нет.
Да блин, основы уже больше 10 лет не менялись. Пусть хотя бы сделают так же.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, bisoft, Вы писали:
B>>>Меня всегда веселит, когда какой нибудь линуксоид говорит — да в линуксе ставить программы просто и демонстрирует — набрав строчку абаракадабр S>>А искходный код для вас тоже абаракадабра и программируете вы кидая формочки с помощью мышки?
B>Ну я ж не спорю, что все можно выучить, но зачем? B>Можно готовить в современной мультиварке, а можно на костре, так зачем себя мучить то? B>Можно придумать одно объяснение — заблудился в дремучем лесу и приходится B>Какие еще вы можете придумать объяснения для совершения таких подвигов сегодня?
Где вы нашли в командной строке какие-то "подвиги" и "мучения"?
Здравствуйте, CreatorCray, Вы писали:
CC>Уууу... Опять свой устав принесён в чужой монастырь?
Опять попытка играть в монополию, там где ее уже давно нет.
CC>Ещё с прошлого века это Ctrl-F4, как во всей ОС и в любом браузере под эту ОС.
Из коробки во всех двух браузерах (FF и Chrome) ctrl-w
S>>Или использование xml для проектов. CC>Ну а XCode в чём хранит? plist это тот же XML, просто ещё и кривой.
XCode такой же кривой
S>>Про догонят тоже спорно, т.к. например QtCreatot перешел на clang для автодополнения кода. CC>Не знаю куда там перешёл QT но вот в XCode вроде как тот же CLang и парсит он отвратительно, банальный #ifdef вышибает из него опору и здоровенные куски кода просто игнорируются — банальный refactor rename не видит там ни одного символа, что приводит к неожиданным результатам.
Ну это проблема не Clang, а взаимодействия IDE и Clang: сам-то Clang ничего не знает о том с какими #define будет собираться проект.
CC>Вижуалка на том же коде работает замечательно. CC>И это лишь малая доля того, что сломано. S>>Там вложены многие-многие челокеко-года и Студия вряди ли догонит с самописным парсером. CC>Как IDE XCode пока не дотягивает даже до связки Студия 2008 + VAX, какое там!
Вполне возможно, я XCode не пользовалься никогда (хотя вот только что закончил настройку CI очередного проекта на MacOS).
Здравствуйте, Sinclair, Вы писали:
S>Ctrl-F4 применялась для MDI ещё в Windows 3.1, когда авторы обоих браузеров ещё ходили в колготках.
1. MDI != tabs.
2. Интерфейс развивается и то, что казалось удобным вчера, сегодня может быть сделано куда удобнее.
S>Ссылаться на них как на законодателей моды для IDE, это нуу.. ммм... странно.
Нет, т.к. браузер это одно из основных приложений сегодня (где ты это сообщение читаешь?)
Здравствуйте, Skorodum, Вы писали:
S>1. MDI != tabs. S>2. Интерфейс развивается и то, что казалось удобным вчера, сегодня может быть сделано куда удобнее. S>Нет, т.к. браузер это одно из основных приложений сегодня (где ты это сообщение читаешь?)
О да, ну конечно же Ctrl-W — это офигенный шаг вперёд по сравнению с Ctrl-F4.
И ещё раз повторимся, чисто на всякий случай: Ctrl-F4 под виндой работает во всём. Включая, естественно, FF, Chrome, Edge, IE, офис. И, да, Visual Studio тоже.
Я никогда в жизни Ctrl-W не пользовался и не собираюсь, мне привычно Ctrl-F4/Alt-F4 для закрытия, соответственно, текущего окна / текущего приложения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, bisoft, Вы писали:
N>>Где вы нашли в командной строке какие-то "подвиги" и "мучения"? B>Ну давайте проверим — перечислите мне все ключи команды ls не смотря подсказку.
Перечислите мне все пункты в меню настройки сетевой карты.
Здравствуйте, bisoft, Вы писали:
B>В том то и дело, что проще потыкать мышкой, чем читать 17 кб текста только по команде ls
Нет. ls -al работает для меня последние 16 лет без всяких изменений, а вот настройки сетевой карты в винде поменялись уже много раз.
Здравствуйте, bisoft, Вы писали:
C>>Перечислите мне все пункты в меню настройки сетевой карты. B>В том то и дело, что проще потыкать мышкой, чем читать 17 кб текста только по команде ls
Мне проще текст прочитать — в нём можно делать поиск. А как мышкой найти нужный пункт? А если это надо в скрипт вставить и запустить на удалённом узле?
Здравствуйте, Skorodum, Вы писали:
S>Или использование xml для проектов.
И что в этом плохого? Недостаточно модно и молодежно?
Не, ты может и не в курсе, но на заре появления тулинга для core хипстота пропихнула для проектов json. В ответ прилетело такое количество тухлых помидоров от комьюнити, что сие поделие, не смотря на потраченные немалые усилия, быстренько закопали обратно.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Особенно учитывая последние достижения в области usability для CLI. Например, умный автокомплит для команд. НС>Великие достижения, как для 2019 года то.
Да, а что? Реально удобно стало.
Здравствуйте, Skorodum, Вы писали:
B>>В том то и дело, что проще потыкать мышкой, чем читать 17 кб текста только по команде ls S>Нет. ls -al работает для меня последние 16 лет без всяких изменений, а вот настройки сетевой карты в винде поменялись уже много раз.
В виндах ещё и netsh имеется, неизменный. А вот в альтернативных системах GUI как не было, так и нет.
Здравствуйте, 00011011, Вы писали:
0>Что я хочу сказать? 0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом.
Было бы хорошо, но это будет не C++.
0> Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Что делать, если для одного проекта используется несколько языков?
Но вообще самого дико раздражает, что куча проектов собирается только в какой-то вымудренной конфигурации на компе авторов и в произвольном случае надо еще пердолиться, настраивая систему под них.
Здравствуйте, Michael7, Вы писали:
M>Было бы хорошо, но это будет не C++.
Почему? Это вообще не затрагивает сам язык. Это просто обяжет всех разработчиков компиляторов и сред разработки следовать единой объектной модели проекта.
А то ведь кто во что горазд, в той же студии от версии к версии формат меняется!
M>Что делать, если для одного проекта используется несколько языков?
Это как? Результатом является или исполняемый модуль, или библиотека. Если проект использует библиотеку, написанную на другом языке — то значит там внутри должна быть секция "зависимости", в ней "проекты, собираемые другими инструментами" и внутри массив этих внешних проектов (или массив пар ключ-значение: проект — инструмент).
В современных языках обычно так. В С++ вроде cmake стандарт де-факто, ну autotools это ещё юниксовое наследие. А что, старый добрый ./configure && make не срабатывает?
Здравствуйте, 00011011, Вы писали:
0>Мне нужно именно под студию собрать, чтобы поразбираться в коде, в отладчике походить и т.д.
Так проблема в твоей зависимости от студии и подходе МС "мы такие крутые монополисты будем вводить свои собственные стандарты и решения". Но даже МС уже исправляются и двигаются навстречу прогессу: перешли на гит, вводят поддержку CMake.
Ну и поддержка кроссплатформенной сборки и разработки это почти всегда боль разной степени
Здравствуйте, Dair, Вы писали:
D>cmake умеет в качестве выхода выдавать студийный проект. Только у него на входе не CMake, а qmake. Был не прав, не заметел CMakeLists.txt
Здравствуйте, Mr.Delphist, Вы писали:
MD>Попробуйте собрать OpenSSL. Под Винду. В режиме совместимости с Visual Studio.
Ну я собирал.
Активно используются макросы для построения имён, в итоге по имени из ошибки ничего не находится. Т.к. это имя — составное.
Самая жесть — сплошь и рядом куски исходников (не хидеров!) инклудятся в другие исходники.
Причём один и тот же включается по нескольку раз. С переопределением макросов между инклудами, меняющих включаемое содержимое.
Такая себе кодогенерация.
MD>Через полгода попробуйте снова, на другой машине. После этого придёт осознание что всё — тлен
Один раз пройдя по щедро разложенным граблям уже перестанешь удивляться, и легко справишься.
Здравствуйте, IID, Вы писали:
IID>Активно используются макросы для построения имён, в итоге по имени из ошибки ничего не находится. Т.к. это имя — составное.
Это да — тоже долго искал один кусок где он объявлен. Оказалось — макрос-based
IID>Один раз пройдя по щедро разложенным граблям уже перестанешь удивляться, и легко справишься.
Не-а
Например, если удосужишься поставить себе другой Perl к тому времени (что со всякими Go/Chocolatier — раз плюнуть, даже не заметишь, пекетный менеджер сделает всё за тебя). Потому что надо строго ActivePerl, иначе велкам в исходники патчить один хитрый regexp, который интерпретируется по-разному, и ломает билд неожиданным переводом строки.
Здравствуйте, Слава, Вы писали:
F>>это стандартный софт. и тебе стоило бы о нём знать. F>>дык заплати — будет тебе сборщик. С>Это говно, а не софт. Поделие от гоблинов для морлоков. С>За это не платить надо, а палкой бить за изобретуцию с порнотехноложеством. Деньги тут не помогут.
ладно, ты неосилятор. но есть же люди, которые знают и разбираются.
они могут написать тебе сборщик, каким ты его хочешь видеть.
просто заплати.
Здравствуйте, AlexRK, Вы писали:
ARK>Считаю, что выделенный файл проекта вообще не нужен. Вся сборка должна описываться на самом языке программирования.
Так?
Здравствуйте, Skorodum, Вы писали:
ARK>>Считаю, что выделенный файл проекта вообще не нужен. Вся сборка должна описываться на самом языке программирования. S>Так? S>
Здравствуйте, AlexRK, Вы писали:
ARK>Я бы сказал даже так: ARK>
ARK>gcc build_the_project.cpp
ARK>
Так не получиться: нужна какая-то опция компилятору, говорящая, что этот файл особый и нужно запустить бинарь после сборки.
S>>Императивные языки для этого не особо подходят. ARK>Почему?
Например потому что придется ручками разрешать порядок сборки на основе зависимостей между проектами. Куда проще писать "A needs B needs C" и оставить на откуп системы сборки разрешение порядка.
Здравствуйте, Skorodum, Вы писали:
ARK>>Я бы сказал даже так: ARK>>
ARK>>gcc build_the_project.cpp
ARK>>
S>Так не получиться: нужна какая-то опция компилятору, говорящая, что этот файл особый и нужно запустить бинарь после сборки.
Этот файл не особый. А какой бинарь надо запускать, не понял.
S>>>Императивные языки для этого не особо подходят. ARK>>Почему? S>Например потому что придется ручками разрешать порядок сборки на основе зависимостей между проектами. Куда проще писать "A needs B needs C" и оставить на откуп системы сборки разрешение порядка.
Это должно поддерживаться на уровне языка. Никакие системы сборки не нужны. Мало того, такие языки уже есть — Jai от Джонатана Блоу, например.
Здравствуйте, AlexRK, Вы писали:
ARK>Этот файл не особый. А какой бинарь надо запускать, не понял.
Бинарь который собирет проект build_the_project.cpp компилируется в "средство сборки" которое уже соберает проект. Только так твоя идея имеет теоретический смысл в мире С++.
А как ты хотел? Одной строкой собрать проект?
ARK>Это должно поддерживаться на уровне языка.
Прекрасно, тогда это какой-то императивный язык. И системы сборки такие есть, например QBS.
ARK>Никакие системы сборки не нужны.
И компиляторы? Ну ок, где-то можно жить с Python и JS
ARK>Мало того, такие языки уже есть — Jai от Джонатана Блоу, например.
Давай хелловорлд на нем!
Здравствуйте, Skorodum, Вы писали:
ARK>>Этот файл не особый. А какой бинарь надо запускать, не понял. S>Бинарь который собирет проект build_the_project.cpp компилируется в "средство сборки" которое уже соберает проект. Только так твоя идея имеет теоретический смысл в мире С++.
Да, надо было изначально сделать оговорку, что я говорил не о С++, а вообще (тема вроде как в language agnostic разделе). Если брать конкретно С++, то "просто так" взять и сделать иначе, разумеется, нельзя — нужна модификация языка и компиляторов.
S>А как ты хотел? Одной строкой собрать проект?
Да, именно так.
ARK>>Это должно поддерживаться на уровне языка. S>Прекрасно, тогда это какой-то императивный язык. И системы сборки такие есть, например QBS.
Да.
ARK>>Никакие системы сборки не нужны. S>И компиляторы? Ну ок, где-то можно жить с Python и JS
Компиляторы нужны. Они же должны и сборкой проектов заниматься.
ARK>>Мало того, такие языки уже есть — Jai от Джонатана Блоу, например. S>Давай хелловорлд на нем!
Здравствуйте, neFormal, Вы писали:
F>что-то делал, решил не разбираться, что-то не заработало... плохой autotools.
Вообще-то большая доля правды есть. Скомпилировать софт в произвольном случае (если не из репозитория) — это, да, сделал configure и потом make, а оно чих-пых валится с ошибками компиляции. Обычное дело. В особо клинических случаях еще и сам configure завершается с ошибками (и не по причине отсутствия нужных библиотек). Причем по идее configure как раз и придумали, чтобы автоматически готовить правильный Makefile так, чтобы все что нужно было на выходе.
Здравствуйте, Слава, Вы писали:
С>Но вся эта культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры, где vim ваш умеет только бибикать и всё портить, где на клавиатуре нет курсорных клавиш — она прошла мимо меня. И знакомиться я с ней не желаю, наоборот — я желаю ей смерти, вместе со всеми её носителями.
ДА!
С>А убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования. Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка! Нет, вася, надо было тебе, васе, это обратно в глотку засунуть, сразу же, пока оно не распространилось. Или, вася, делай нормально, или вообще никак не делай. Засилие убогих инструментов сдерживает развитие инструментария нормального. Где maven для си? Где nuget хотя бы? Ась? Чому оно такое всё кривое? Почему это вообще надо "осиливать"?
ДА!!!
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, neFormal, Вы писали:
F>что-то делал, решил не разбираться, что-то не заработало... плохой autotools.
Не дюд, это говно и палки.
F>ничего из широко используемых программ не было написано в вижуалке: ни емакс, ни баш, ни перл, ни irssi.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Michael7, Вы писали:
F>>что-то делал, решил не разбираться, что-то не заработало... плохой autotools. M>Вообще-то большая доля правды есть. Скомпилировать софт в произвольном случае (если не из репозитория) — это, да, сделал configure и потом make, а оно чих-пых валится с ошибками компиляции. Обычное дело. В особо клинических случаях еще и сам configure завершается с ошибками (и не по причине отсутствия нужных библиотек). Причем по идее configure как раз и придумали, чтобы автоматически готовить правильный Makefile так, чтобы все что нужно было на выходе.
ну, вообще странно брать рандомную фигню с интернета и ждать, что она нормально у тебя заработает.
у автором зачастую такой бардак в системе, что там надо собирать по кусочкам.
но это не проблема системы сборки.
Здравствуйте, CreatorCray, Вы писали:
F>>что-то делал, решил не разбираться, что-то не заработало... плохой autotools. CC>Не дюд, это говно и палки.
что было в далёком прошлом, то и работает.
проблема ещё в том, что новое мало кто хочет изучать. одни не хотят старого, другие нового. так не взлетели разные сборщики, тот же scons.
сейчас это заработает только при широкой инфраструктуре, что стоит непомерно дорого для разработчика.
F>>ничего из широко используемых программ не было написано в вижуалке: ни емакс, ни баш, ни перл, ни irssi. CC>
да, виндовый мирок не единственный на этой планете.
Здравствуйте, neFormal, Вы писали:
F>>>что-то делал, решил не разбираться, что-то не заработало... плохой autotools. CC>>Не дюд, это говно и палки. F>что было в далёком прошлом, то и работает.
Проблема в том что оно окуклилось и не эволюционирует.
F>проблема ещё в том, что новое мало кто хочет изучать. одни не хотят старого, другие нового. так не взлетели разные сборщики, тот же scons.
Ох не напоминай про scons. На нём криворучки такой пц вытворяют что просто атас.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 00011011, Вы писали:
0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
0>Скачиваю какой-то проект, с гитхаба например. Хочу собрать. И что я вижу? 0>Вот например. 0>Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.
В файле .appveyor.yml как раз описано то, что нужно сделать для сборки под VC++
p.s.
тоже не очень нравится когда нужно качать зависимости из разных мест.
я все либы скидываю в один репозитарий, чтобы одним солюшеном собиралось сразу после git clone https://github.com/pavel-pimenov/flylinkdc-r5xx
тут кстати можешь забрать проект сборки libtorrent
в отличии от того, что генерирует cmake — в нем относительные пути.
Здравствуйте, Dair, Вы писали:
IID>>говно мамонта, которое за >40 лет так и не научилось поддерживать пробелы в makefile D>Ну, это, конечно, серьёзная проблема
Бесит жутко, т.к. у меня по TAB подставляется 4 пробела. И чтобы набрать TAB приходится отвлекаться.
Дополнительно бесит, что такую элементарную задачу за столько лет так и не решили, а современные обезъянки и не будут решать, потому что тут так принято
Правильно выше "Слава" заметил:
культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры
...
убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования. Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка!
IID>>А тупой автоконф обладает искусственным интеллектом: пытаетcя откомпилить всем подряд, чем-то вроде компилится и похер, что вообще другая архитектура. D>А теперь давай то же самое элегантно в MSVS.
Ставишь ARM компилятор, выбираешь таргет ARM, нажимаешь F7.
Основная претензия к autoconf даже не в его этой самодеятельности, а в том что на выходе имеем ком невнятных ошибок. И приходится вручную разгребать логи и т.д., чтобы понять, что пошло не так.
IID>>Обратные слеши — наследие CP/M (1974), и она тогда была гоооораздо популярнее чем эти ваши юниксы.
D>Я, конечно, в 1974 ещё не родился, но вот википедия подсказывает что D>
CP/M 2.2 had no subdirectories in the file structure, but provided 16 numbered user areas to organize files on a disk. To change user one had to simply type "User X" at the command prompt, X being the number of the user wanted
D>То есть, там обратного слэша для разделения путей не было вообщеб потому что не было поддиректорий. "A:FILENAME.EXT" — всё.
Ты не туда смотришь.
Смотри на разделители параметров.
Здравствуйте, Anton Batenev, Вы писали:
BFE>> AB>Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make. BFE>> Нет. Не собираются.
AB>Скорее всего, ты просто чего-то не умеешь / не знаешь.
Чего надо знать при "стандартных configure && make"?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Не-а MD>Например, если удосужишься поставить себе другой Perl к тому времени (что со всякими Go/Chocolatier — раз плюнуть, даже не заметишь, пекетный менеджер сделает всё за тебя). Потому что надо строго ActivePerl, иначе велкам в исходники патчить один хитрый regexp, который интерпретируется по-разному, и ломает билд неожиданным переводом строки.
Открой для себя choco pin
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, 00011011, Вы писали:
0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
0>Скачиваю какой-то проект, с гитхаба например. Хочу собрать. И что я вижу? 0>Вот например. 0>Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.
новую библиотеку в каталог с библиотеками.
0>Что я хочу сказать? 0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Ну вообще-то не стандарт де-юре, но более менее аналог,
который используется большинством есть,
и современному программисту C++ волей неволей приходится с ним разбираться.
Вы его собственно и увидели. Раньше cmake использовали для генерации проекта для IDE.
Теперь большинство современных IDE умеют работать с CMakeLists.txt напрямую,
например
Здравствуйте, Слава, Вы писали:
С>Кстати, расскажите мне, если вы знаете, каким образом собирается ms exchange
С помощью аццкой системы постройки, которая состоит из кучи серверов, магических расшареных папок и требует соединения с MSSQL во время строительства.
Здравствуйте, Dair, Вы писали:
D>У виндовз-программистов какое-то извращённое Микрософтом представление о мире. Да, Микрософт сделал довольно неплохую VS под себя. Но подходить к ней надо как к инструменту Микрософт для Микрософт, вещь в себе.
Ну почему? Я например писал в студии код для BSD kernel — удобство было на голову выше чем у коллег, которые мудохались вприсядку кто с чем.
D>на момент создания VS (1997) уже были GNU Make (1976) и даже autotools (1996).
Ну так студия продолжила развитие а это говно мамонта так и осталось на уровне 78го и 96го.
D>Это ты приучен к левой дюймовой резьбе, поэтому правая метрическая тебя вгоняет в тоску.
Я привык к отсутствию геморроя и необходимости превозмогать на пустом месте.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Voivoid, Вы писали:
V>Как мне добиться отсутствия геморроя при практически любом мерже .sln и .vcxproj файлов?
В vcxproj они сильно всё подпортили
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Dair, Вы писали:
D>У Майкрософт же ровно то же самое — обратные слэши и отсутствие POSIX-совместимости — шевелится и хрен с ним.
Да чего вам всем так жмут эти слеши? Какая разница в какую сторону их ставить? В винде как раз хорошо — и так и так работает.
Ну а posix — говно мамонта, не нужен.
D>Потому что Microsoft потратила деньги чтобы сделать себе IDE чтобы лучше продавать Windows.
Надо же, если хочешь развивать платформу — надо вкладываться в проектирование, тулсет и документацию!
Причём не херак херак и в продакшен а чтоб хорошо и удобно было.
D>Вот почему-то никто не потратил денег чтобы сделать IDE под *nix. D>Сами по себе как-то появились Eclipse, Netbeans, Code::Blocks и Qt Creator. А теперь и платный CLion.
Взаимоисключающие параграфы, не?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sharowarsheg, Вы писали:
F>>ладно, ты неосилятор. но есть же люди, которые знают и разбираются. S>
S>It is generally true that if you can fool developers into thinking they are "mastering" something hard (as opposed to learning tolerance for something badly designed), you can build a fiercely loyal priesthood.
Здравствуйте, Cyberax, Вы писали:
C>В MSVS поддержка всех комбинаций потребует 16 вариантов сборки (Debug/Release * 8 комбинаций). И это только в одной библиотеке!
Я cmake не знаю, но как он решают эти пробелмы? Т.е. по факту у нас действительно 8 комбинаций, Debug/Release переключается по шелчку. Как cmake помогает избежать 8 комбинаций?
C>Следующий вопрос — это зависимости. В MSVS обычно просто фигачат всё в подкаталог, часто в виде бинарных файлов. Надо объяснять чем это плохо?
Чем же, избыточным копированием или с т.з. хранения в репо?
Здравствуйте, Sharowarsheg, Вы писали:
F>>ух ты! мнение чувака из интернета! ну всё, это подеба. S>Ну, ты тоже из интернета.
если моими постами начнут что-то доказывать, можешь презирать оппонента
F>>а ничего, что всё изменяется результатом? и если ты не "мастеришь" в чём-то, то просто не можешь что-то сделать. S>Может, это и не было бы нужно делать. Однако, набигают люди, которые уже вложили кучу времени в изучение и освоение корявых технологий, и пытаются заставить всех остальных потратить время тоже.
но было же наоборот:
прибежали люди, которые не осилили, потому и требовали запретить-не-пущать. ни альтернатив, ни логики...
осиляторы же аргументировали тем, что за эти навыки платят. и не то, чтобы это было плохо.
если же мы будем себя ограничивать чьими-то хотелками, то не сможем дать юзерам те вещи, которые им нужны.
я понимаю, что в волшебном шиндовс-мирке есть только вижуалка и софт учёта склада, но в реальности есть много других потребностей.
S>It is generally true that if you can fool developers into thinking they are "mastering" something hard (as opposed to learning tolerance for something badly designed), you can build a fiercely loyal priesthood.
Отличное высказывание. Хорошо описывает природу бурных эмоций "Славы" и CreatorCray.
Здравствуйте, Skorodum, Вы писали:
S>Оно не хорошее и не плохое. Оно работает и альтернативы ему особо нет. Никакой проблемы в промежуточном шаге сборки нет, т.к. любая сборка за пределами main.cpp в любом случае это несколько шагов.
Нет, проблема в магии, которая, вдобавок, сама не работает.
S>В чем там обман? В том, что на голых плюсах этого не сделать?
Не уверен, что сейчас не сделать.
S>Других особо и не было когда Qt начиналась (1991).
Сколько уже было мажорных релизов с ломающими изменениями?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Нет, проблема в магии, которая, вдобавок, сама не работает.
Никакой магии там нет, обычная кодогенерация, которая работает и с qmake и с CMake и с QBS. Студия через плагин умеет.
Ops>Не уверен, что сейчас не сделать.
Ну так сделай Думаешь все вокруг такие дураки, просто ленивые или любят дополнительные сложности?
S>>Других особо и не было когда Qt начиналась (1991). Ops>Сколько уже было мажорных релизов с ломающими изменениями?
Ты не понял. Речь про то, что тогда все гении были "красноглазыми", винды просто еще не было.
А ломающих бинаруную совместимость релизов было всего 4.
Здравствуйте, neFormal, Вы писали:
F>>>ух ты! мнение чувака из интернета! ну всё, это подеба. S>>Ну, ты тоже из интернета.
F>если моими постами начнут что-то доказывать, можешь презирать оппонента
Да это не столько доказательство, сколько было бы невежливо взять цитату без ссылки.
F>но было же наоборот: F>прибежали люди, которые не осилили, потому и требовали запретить-не-пущать. ни альтернатив, ни логики...
То, что они не осилили, а также то, что они не предложили альтернатив, не отменяет того, что со сборкой дела обстоят не совсем хорошо (чтобы не сказать срань господня).
F>осиляторы же аргументировали тем, что за эти навыки платят. и не то, чтобы это было плохо.
Ещё более приятный вариант, когда ты делаешь что-то настолько сложное, что никто нихрена не может в этом разобраться. По мере того, как ты всё более и более усложняешь это нечто, ты получаешь всё больше и больше денег, и порог входа всё больше и больше. Это прекрасно работает, пока не кончается.
F>если же мы будем себя ограничивать чьими-то хотелками, то не сможем дать юзерам те вещи, которые им нужны. F>я понимаю, что в волшебном шиндовс-мирке есть только вижуалка и софт учёта склада, но в реальности есть много других потребностей.
В волшебном виндовс-мирке есть дофига всего, вообще говоря.
Здравствуйте, Ops, Вы писали:
S>>Ну да, а МС обосралась с телефонами несколько раз Ops>МС обосралась с маркетингом. А сами винфоны — отличная штука, если бы их еще делали.
это телефон без оригинальной фичи.
поэтому у него аудитория — это виндопоклонники.
Здравствуйте, Skorodum, Вы писали:
S>Студия вне конкуренции только в отладчике. Без плагинов (зачастую платных) она проигрывают во многом QtCreator.
Да, раньше visual assist был must-have, но начиная где-то с vs2015 он не нужен, студия сама все делает отлично
Здравствуйте, Voivoid, Вы писали:
V>Да, раньше visual assist был must-have, но начиная где-то с vs2015 он не нужен, студия сама все делает отлично
Отлично это громко сказано, да и автодоплнение уровня Clang вряд ли даже в теории возможно без аналогичного подхода.
Интеграция с гитом там слабая.
Здравствуйте, Sharowarsheg, Вы писали:
S>Мне периодически приходится по необходимости собирать опенсорцные проекты под винду, и нет, обычно не собирается. Можно себе представить, что я не имею дела с нормальными проектами (не исключено), но результата это не меняет — всё равно без плясок не собирается.
Плохие проекты есть и в опен-сорс и в коммерческой разработке, качество и закрытость/открытость ПО это ортогональные понятия.
Разговор-то про то, что используя нормальные средства эту проблему решить можно. И большинство решений пришли из open-source мира. МС сильно отстает в этой области, а порой и целенаправленно тормозит. Аpple тоже.
S>Это подход всех, насколько я вижу. Всем денег хочется, ну или возможности попонтоваться.
Да и это понятно. Не нормальны стенания адептов Win CMD, которым не нравится мир за пределами их песочницы.
Здравствуйте, IID, Вы писали:
IID>"жопой" это когда установленный тулчейн содержит говно, палки и изоленту, которые ломают билд, а вместо ошибок выводят мусор (выше был пример).
toolchain это компилятор и линкер. Пойдет и от МС, но вот без танцев с бубном его не установить.
IID>А тулчейн можно установить вообще без команд, парой кликов мышью. буду вызывать IID.bat, чтобы он мышкой кликал
IID>Да и устаналивается он один раз, и этот процесс погоды не делает.
Про CI никогда не слышал? Вы релизы собираете на машинах разработчиков?
IID>Впрочем, за подсчётом количества команд пройдите к оберонщикам, там синтаксический оверхед в почёте.
Вопрос не в количестве, а в возможностях автоматизации. МС тут лет на 10 от линухи отстатала.
Здравствуйте, IID, Вы писали:
IID>Где я могу его пощупать ? Скачать готовую GUI среду. (За любое упоминание vim/emacs — сразу в сад).
Встроен в QtCreator с версии 4.8 ЕМНИП.
IID>Эээ... Что за апостасия! Какая тебе ещё интеграция, тебе консоли должно для всего хватать!
Представь себе не все люди фаната Vi В качестве редактора и для большинства гитовых операций я предпочитаю QtCreator.
Здравствуйте, Skorodum, Вы писали:
IID>>"жопой" это когда установленный тулчейн содержит говно, палки и изоленту, которые ломают билд, а вместо ошибок выводят мусор (выше был пример). S>toolchain это компилятор и линкер.
А ещё binutils и хидеры с либами. И что ?
Ты меня сейчас прям в ступор вогнал.
Я тебе: "у вас из штанины потекло". А ты в ответ: "2+2=4".
S>Пойдет и от МС, но вот без танцев с бубном его не установить.
Что за проблемы с установкой ?
IID>>А тулчейн можно установить вообще без команд, парой кликов мышью. S> буду вызывать IID.bat, чтобы он мышкой кликал
IID>>Да и устаналивается он один раз, и этот процесс погоды не делает. S>Вы релизы собираете на машинах разработчиков?
Странный вывод.
А вы перед каждым билдом тулчейн на голую ОС устанавливаете ?
S>Про CI никогда не слышал? S>Вопрос не в количестве, а в возможностях автоматизации. МС тут лет на 10 от линухи отстатала.
Элегантная (на самом деле нет) смена темы с установки тулчейна на автоматизацию билда Не ведусь.
Здравствуйте, IID, Вы писали:
S>>Пойдет и от МС, но вот без танцев с бубном его не установить. IID>Что за проблемы с установкой ?
То что нет аналога "sudo apt install gcc"
IID>А вы перед каждым билдом тулчейн на голую ОС устанавливаете ?
Представь себе в CI системе сборка идет на девственно чистой ОС (кроме винды конечно )
IID>Элегантная (на самом деле нет) смена темы с установки тулчейна на автоматизацию билда Не ведусь.
У тебя были притензии к отсутсвию прогресса в разработке ПО. Так вот самый большой тормоз тут МС.
Здравствуйте, Skorodum, Вы писали:
S>>Почему не нормальны. Я вот скажем, пишу под Windows. Не знаю, причём тут CMD, но вот эти всё дикие сборочные скрипты мне не нравятся. S>А что нравится? Вот стоит задача чтобы проект собирался под Win/Linux/Apple. Как решать? Причем с генерацией кода lex/yacc, генерацией питонвского API и зависимостями от нескольких внешних библиотек. И все это автоматически в CI. S>МС не осилило кросс-платформенную сборку, а "осиляторы" худ-бедно, но справились.
Нет, не справились. Под винду всё равно без плясок не собирается.
Здравствуйте, Skorodum, Вы писали:
S>>>Пойдет и от МС, но вот без танцев с бубном его не установить. IID>>Что за проблемы с установкой ? S>То что нет аналога "sudo apt install gcc"
Если тебе надо в режиме "усрусь но не покорюсь" — я уже писал, студия умеет устанавливаться из командной строки. Так что незачёт.
IID>>А вы перед каждым билдом тулчейн на голую ОС устанавливаете ? S>Представь себе в CI системе сборка идет на девственно чистой ОС (кроме винды конечно )
Ты не ответил на вопрос. КАЖДАЯ сборка ?
Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ? ЗАЧЕМ ? (Кажется кто-то заврался.)
S>У тебя были притензии к отсутсвию прогресса в разработке ПО. Так вот самый большой тормоз тут МС.
Здравствуйте, Ops, Вы писали:
F>>это телефон без оригинальной фичи. F>>поэтому у него аудитория — это виндопоклонники. Ops>Что за фича у ведра? "Теперь уж точно совсем не тормозит"?
Здравствуйте, Слава, Вы писали:
F>>магазин, цена, распространённость. С>Лучше бы этого магазина вообще не было. Как и кучи ограничений, с ним связанных. Централизация, цензура и реклама в каждом втором приложении, которая оказывается ещё и выгоднее для создателя программы, чем продажа за деньги.
какая ещё цензура? дроидный магазин, наверное, самый открытый
Здравствуйте, Sharov, Вы писали:
C>>В MSVS поддержка всех комбинаций потребует 16 вариантов сборки (Debug/Release * 8 комбинаций). И это только в одной библиотеке! S>Я cmake не знаю, но как он решают эти пробелмы? Т.е. по факту у нас действительно 8 комбинаций, Debug/Release переключается по шелчку. Как cmake помогает избежать 8 комбинаций?
CMake позволяет просто указать флаги и подключить библиотеку из файла сборки основного приложения. Так что библиотека будет скомпилирована с нужными настройками.
C>>Следующий вопрос — это зависимости. В MSVS обычно просто фигачат всё в подкаталог, часто в виде бинарных файлов. Надо объяснять чем это плохо? S>Чем же, избыточным копированием или с т.з. хранения в репо?
С тем, что пропадает версирование. Чёрт разберёт какие версии библиотек правильные. А если нужно обновить зависимости (из-за дырки в безопасности, например), то начинаются приседания. И это ещё без учёта множественных платформ.
Здравствуйте, Ops, Вы писали:
F>>для винды это настолько чудо, что не верят Ops>Конечно чудо — делать многократно одну и ту же работу, которую можно сделать 1 раз. Так чудесато только красноглазики могут.
При использовании контейнеров неизменная часть работы будет кэшироваться.
Здравствуйте, IID, Вы писали:
IID>Если тебе надо в режиме "усрусь но не покорюсь" — я уже писал, студия умеет устанавливаться из командной строки. Так что незачёт.
Серьезный вопрос: как? Мне вот прям сейчас это не надо, но вообще интересно.
IID>>>А вы перед каждым билдом тулчейн на голую ОС устанавливаете ? S>>Представь себе в CI системе сборка идет на девственно чистой ОС (кроме винды конечно ) IID>Ты не ответил на вопрос. КАЖДАЯ сборка ?
Проблемы с чтением? Да, у нас полная сборка на каждый коммит на всех целевых платформах с нуля, зависимые проекты тоже собираются, industrial development и все такое. Винда и MacOS к сожалению, не совсем чистые: МС дает образы с предустановленным софтом
IID>Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ?
Не откатываем, а берем образ голой ОС потом ставится все что надо и т.д. и т.п.
IID>ЗАЧЕМ ?
100% гарантия что все документированно и собирается с правильными версиями и настройками.
IID>(Кажется кто-то заврался.)
Кажется кто-то не знает как работают взрослые
S>>У тебя были притензии к отсутсвию прогресса в разработке ПО. Так вот самый большой тормоз тут МС. IID>Ты путаешь.
От тебя аргументов как не было так и нет
В общем судя по твоей реакции и вопросам у вас разработка ПО "на коленке", так что разговор особого смысла не имеет.
Здравствуйте, Sharowarsheg, Вы писали:
S>Нет, не справились. Под винду всё равно без плясок не собирается.
Это говорит только о том, что есть проекты которые плохо поддерживаются или плохо документированы
Создатели сресдтв более-менее справились, и задачу при желании решить можно хорошо. MS же средств для решения подобных задач не имеет в принципе. Так что все притензии IID, Славы, и CreatorCray выглядят глупо.
Здравствуйте, Skorodum, Вы писали:
CC>>А где можно посмотреть на этот успех? S>GitHub, MC, etc
Гитхаб состоит из мусора на 99%
MS просто хочет окучить ещё и красноглазых
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, neFormal, Вы писали:
F>а ничего, что всё изменяется результатом? и если ты не "мастеришь" в чём-то, то просто не можешь что-то сделать.
Сейчас увы верно вот это: "Если ты не смог починить что либо с помощью изоленты — значит ты просто использовал мало изоленты."
Так что херак херак и в продакшен стало делать ещё проще. Лепят из говна и палок и как только зашевелилось — всё, готовый продукт!
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
S>МС не осилило кросс-платформенную сборку, а "осиляторы" худ-бедно, но справились.
Там такое говно что лучше бы не справлялись чем так.
Можно было сделать нормально, но они предпочли не разобраться а просто притащить весь свой монастырь.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
IID>>"жопой" это когда установленный тулчейн содержит говно, палки и изоленту, которые ломают билд, а вместо ошибок выводят мусор (выше был пример). S>toolchain это компилятор и линкер. Пойдет и от МС, но вот без танцев с бубном его не установить.
Каких танцев? Если ты на винде хочешь чтоб работали линуксовые приседания — так это ты со своим уставом припёрся, тебе в другой монастырь надобно.
IID>>А тулчейн можно установить вообще без команд, парой кликов мышью. S> буду вызывать IID.bat, чтобы он мышкой кликал
Секта свидетелей консоли?
IID>>Да и устаналивается он один раз, и этот процесс погоды не делает. S>Про CI никогда не слышал? Вы релизы собираете на машинах разработчиков?
Билдсервер собирает. Не вижу надобности переустанавливать там тулсет каждый день.
S>Вопрос не в количестве, а в возможностях автоматизации. МС тут лет на 10 от линухи отстатала.
Что именно ты собрался автоматизировать то? Что у тебя там не работает?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
IID>>Что за проблемы с установкой ? S>То что нет аналога "sudo apt install gcc"
А тебе твои боги по другому под страхом смерти запрещают что ли?
IID>>А вы перед каждым билдом тулчейн на голую ОС устанавливаете ? S>Представь себе в CI системе сборка идет на девственно чистой ОС (кроме винды конечно ) Нах... Зачем? Или у вас там процесс сборки всё наглухо ушатывает?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Voivoid, Вы писали:
V>Да, раньше visual assist был must-have, но начиная где-то с vs2015 он не нужен, студия сама все делает отлично
Сравнивал — ассист всё же многие вещи делает более удобно и наглядно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
S>В MSVС придется опции типа путей к библиотекам прописывать для всех вариантов.
Это в новых студиях идиоты сломали. Раньше один раз было достаточно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
IID>>А вы перед каждым билдом тулчейн на голую ОС устанавливаете ? S>Представь себе в CI системе сборка идет на девственно чистой ОС (кроме винды конечно )
вы там что пытаетесь делать софт рандомно нажимая кнопки? Что, мозг вообще никто не включает?
Здравствуйте, CreatorCray, Вы писали:
C>>Да, это сейчас нормальная и рекомендуемая практика. CC>Кем?
Например, Амазоном — там ещё круче, на билд-машинах вообще отключена всякая сеть (кроме localhost) для избежания даже возможности внешнего влияния на сборку.
И вообще, читаем про repeatable build.
C>>Для того, чтобы исключить взаимное влияние разных билдов. CC>Какое влияние? У вас что, процесс билда меняет весь environment?
Из личного примера — в ходе сборки не убирался файл-флаг, который означал успех теста. Так что проваливающиеся тесты долго не обнаруживались.
Здравствуйте, Cyberax, Вы писали:
C>Например, Амазоном — там ещё круче, на билд-машинах вообще отключена всякая сеть (кроме localhost) для избежания даже возможности внешнего влияния на сборку.
Карго культ какой то.
Какой смысл в этом геморрое?
CC>>Какое влияние? У вас что, процесс билда меняет весь environment? C>Из личного примера — в ходе сборки не убирался файл-флаг, который означал успех теста. Так что проваливающиеся тесты долго не обнаруживались.
А, т.е. прикрытие криворукости. И почему этот файл был насран куда то в левое место?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Cyberax, Вы писали:
CC>>Это попытка прикрыть кучу говна руками. C>И чем её заменить? Идеальными программистами в вакууме?
Хехе, что, набрали кого смогли?
C>Нет. Нужна гарантия, а не "мамой клянусь". Каким образом будем ГАРАНТИРОВАТЬ это?
Так ты просто прячешь баги, какие ещё гарантии? Только что ком говна будет незаметно рости.
C>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC.
И вы решили кривософт оставить как есть и сделать вид что это ок?
CC>>Напомню что защита памяти приводит к exception и panic если кто то пытается её нарушить. C>Вот! Просто заметает ошибки под ковёр!
Программа навернулась с access violation. Это не заметение под ковёр, это как раз наоборот обосратушки всем на обозрение.
C>Как в варианте "тонна копролита, которую Вася настроил руками через RDP" достичь этого?
Вообще надо начинать с избавления от тонны копролита
Запрети процессу билда запись куда либо кроме target folder. Любыми доступными тебе способами.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ops, Вы писали:
D>>Да, Microsoft это добавил то ли в XP, то ли в 2000, не помню. Ops>А красноглазое ниасилило, ибо к людям всегда жопой, а не лицом.
Потому что "красноглазое", как ты выражаешься, не имеет единого центра принятия решений. В отличие от Microsoft.
Здравствуйте, CreatorCray, Вы писали:
CC>Гитхаб состоит из мусора на 99%
99% кода это мусора. Это абсолютно ортогонально ситсеме контроля версий.
CC>MS просто хочет окучить ещё и красноглазых
MS внутри использует гит.
Здравствуйте, CreatorCray, Вы писали:
CC>Дык и не надо. Тут подходы просто другие.
Теже самые. У MS Azure есть (мы, кстати, его и используем).
CC>А нахрена? Мне не надо голый компилятор, я не хочу хреначить в vi
Да вообще все равно каким редактором/IDE пользуется разработчик. У нас и Vim и VS Code и Qt Creator и Студия в ходу, чем хочешь — тем и пользуйся, хоть блокнотом.
Сборка должна работать с минимальными требованиями и никакая IDE и GUI для этого не нужны.
Здравствуйте, CreatorCray, Вы писали:
CC>А тебе твои боги по другому под страхом смерти запрещают что ли?
Да как угодно, только чтобы это было легко и можно было автоматизировать. Почему МС не хочет сделать это процесс легким —
CC>Нах... Зачем? Или у вас там процесс сборки всё наглухо ушатывает?
100% гарантия что все документированно, собирается с нужнынми параметрами, нужными версиями и нет влияния артефактов других процессов.
Здравствуйте, CreatorCray, Вы писали:
CC>Только если в проекте пц и бардак до такой степени что его нельзя пересобрать 2 раза подряд и получить одно и то же.
Какой длины будет инструкция для твоего текущего проекта, чтобы другой разработчик смог его собрать и получить точго такой же хэш от всех артефактов?
CC>Ну а таким образом баг не чинится а заметается под коврик
Таким образом он обнаруживается моментально.
C>>Изоляция среды постройки гарантирует, что подобные ошибки не приводят к фатальным последствиям. CC>Это просто игнорирование ошибок. Офигенная методика, чо!
Ровно наоборот — меньше вероятность того, что ошибки пройдут.
Здравствуйте, Skorodum, Вы писали:
CC>>Только если в проекте пц и бардак до такой степени что его нельзя пересобрать 2 раза подряд и получить одно и то же. S>Какой длины будет инструкция для твоего текущего проекта, чтобы другой разработчик смог его собрать
одна строка, билдит на build server, выдаёт URL где смотреть на прогресс/ашыпки и откуда скачать готовый tgz со всем что надо.
S>получить точго такой же хэш от всех артефактов?
Там в итоге бинари подписываются, так что хеши будут всегда разными просто по определению.
CC>>Ну а таким образом баг не чинится а заметается под коврик S>Таким образом он обнаруживается моментально.
Обнаружится он при втором прогоне, когда наступят на какашку от первого.
Но второй прогон памперс от первого выбросит и не увидит кровавого поноса.
C>>>Изоляция среды постройки гарантирует, что подобные ошибки не приводят к фатальным последствиям. CC>>Это просто игнорирование ошибок. Офигенная методика, чо! S>Ровно наоборот — меньше вероятность того, что ошибки пройдут.
Ошибки в билде должны приводить к фатальным последствиям для процесса билда чтоб их невозможно было пропустить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>одна строка, билдит на build server, выдаёт URL где смотреть на прогресс/ашыпки и откуда скачать готовый tgz со всем что надо.
Нет гарантии, что сервер не обновился.
Нет гарантии, что кто-то не установит софт для решения своих задач (наиболее типичная проблема).
Не документированно кто, что и когда установил на этот сервер (а если документированно, то нет гарантии, что описание не устарело).
Воспроизвети этот билд сервер или увеличить производительность — большой геммор
И т.д. и и т.п.
Все это решаемо с костылями и изолентой, либо контейнеры, виртуальные машины и установка необходимого софта с нуля.
CC>Там в итоге бинари подписываются, так что хеши будут всегда разными просто по определению.
С чего этого? Время сборки включено в процесс подписывания?
CC>...
фекальные аналогии и бред поскипан
CC>Ошибки в билде должны приводить к фатальным последствиям для процесса билда чтоб их невозможно было пропустить.
Здравствуйте, майор очевидность!
Здравствуйте, Skorodum, Вы писали:
S>Сборка должна работать с минимальными требованиями и никакая IDE и GUI для этого не нужны.
А git должен работать без всякого мусора от лялиха, но тут рядом отстаивают необходимость этот мусор, и всякий сопутствующий ему цыгвын, обязательно таскать вместе с ним. Двойные стандарты?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Skorodum, Вы писали:
S>·>https://en.wikipedia.org/wiki/Code_signing#Time-stamping S>Ок, но это не меняет факта, что хэш бинарей после компиляции можно сверять
В смысле? Выходной бинарь билда "applicaiton.exe" будет именно каждый раз разный т.к. зависит от физического времени. Другое дело, что сверять бинари можно не побайтно, а более хитро, игнорируя ожидаемую разницу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ops, Вы писали:
Ops>А git должен работать без всякого мусора от лялиха
А винда должна поддерживать посикс
Ops>но тут рядом отстаивают необходимость этот мусор, и всякий сопутствующий ему цыгвын, обязательно таскать вместе с ним.
Уже вроде не обязательно. Есть же WSL, а там все родное: apt install git.
З.Ы. Никто не мешает ни тебе, ни МС запилить свою версию гита с бледжеком и без зависимостей
Здравствуйте, ·, Вы писали:
·>В смысле? Выходной бинарь билда "applicaiton.exe" будет именно каждый раз разный т.к. зависит от физического времени. Другое дело, что сверять бинари можно не побайтно, а более хитро, игнорируя ожидаемую разницу.
Можно сверять до подписания.
Здравствуйте, Cyberax, Вы писали:
C>>>Гарантия того, что проект собранный вчера будет работать точно так же, как и проект собранный сегодня. CC>>Только если в проекте пц и бардак до такой степени что его нельзя пересобрать 2 раза подряд и получить одно и то же. C>Нет. Нужна гарантия, а не "мамой клянусь". Каким образом будем ГАРАНТИРОВАТЬ это?
Формальными методами, наверное. У вас там даже TLA+ начали внедрять.
Здравствуйте, Skorodum, Вы писали:
Ops>>А git должен работать без всякого мусора от лялиха S>А винда должна поддерживать посикс
Ну а чем тогда не устраивает студия с GUI для сборки? CLI инструменты в ней есть, а это в нагрузку, как ваш цыгвын к гиту. Я ж говорю, двойные стандарты.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Ну а чем тогда не устраивает студия с GUI для сборки?
Для работы GUI — полностью устраивает, не устраивает плохой CLI для CI.
Ops>CLI инструменты в ней есть, а это в нагрузку, как ваш цыгвын к гиту. Я ж говорю, двойные стандарты.
Не, не, двойные стандарты тут не при чем. Вы почему-то ожидаете, что кто-то должен забесплатно адаптировать мир к вашей песочнице. Ну какие-то осиляторы-энтузиасты сделали что-то, но вам и этого мало
Здравствуйте, Skorodum, Вы писали:
S>Проблемы с чтением и художественная резьба по цитатам? Требовать наличия IDE для сборки — этот тупиковый путь и даже у МС есть подвижки в этом направлении.
Как и требовать свалки ненужных утилит для контроля версий. Тебя никто не заставляет запускать эту IDE, она будет лежать рядом. Вот про эти двойные стандарты я и говорю: для гита ты такое считаешь нормальным, а для студии — нет.
S>Плох тем, что его установку трудно автоматизировать.
2 строчки. Гугл в помощь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
S>>Проблемы с чтением и художественная резьба по цитатам? Требовать наличия IDE для сборки — этот тупиковый путь и даже у МС есть подвижки в этом направлении. Ops>Как и требовать свалки ненужных утилит для контроля версий.
Unix-way — каждая утилита делает свою работу. Git'у нужны стандартные утилиты
Ops>2 строчки. Гугл в помощь.
А тебе слабо? Вот есть голая винда. Как автоматизировать установку git/CMake/компилятора?
Здравствуйте, Skorodum, Вы писали:
S>Unix-way — каждая утилита делает свою работу. Git'у нужны стандартные утилиты
Ops>>2 строчки. Гугл в помощь. S>А тебе слабо? Вот есть голая винда. Как автоматизировать установку git/CMake/компилятора?
Мне нет. Навскидку, строчек 5-10, но будет еще choco. За умеренную плату могу написать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Слава, Вы писали:
CC>>>Только если в проекте пц и бардак до такой степени что его нельзя пересобрать 2 раза подряд и получить одно и то же. C>>Нет. Нужна гарантия, а не "мамой клянусь". Каким образом будем ГАРАНТИРОВАТЬ это? С>Формальными методами, наверное. У вас там даже TLA+ начали внедрять.
Какие есть формальные методы, которые могут проверять скрипты сборки?
Здравствуйте, Ops, Вы писали:
S>>Unix-way — каждая утилита делает свою работу. Git'у нужны стандартные утилиты Ops>>>2 строчки. Гугл в помощь. S>>А тебе слабо? Вот есть голая винда. Как автоматизировать установку git/CMake/компилятора? Ops>Мне нет. Навскидку, строчек 5-10, но будет еще choco. За умеренную плату могу написать.
Какой кульбит! Теперь давай рассказывай как это противоречит тезису
Сборка должна работать с минимальными требованиями и никакая IDE и GUI для этого не нужны.
Choco ставит vcbuild tools или как их там, у которых никакого GUI нет, это не лежащая рядом Студия как ты обещал.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
С>>Формальными методами, наверное. У вас там даже TLA+ начали внедрять. C>Какие есть формальные методы, которые могут проверять скрипты сборки?
Вот уж не знаю, какие. Но слово "скрипты" мне уже не нравится. Этот весь sh с питоном. Если у языка, на котором пишется "программа" сборки, будет компилятор и проверка типов, то часть ошибок уже можно будет выловить на этапе компиляции. Возможны и дальнейшие шаги — рядом с императивной процедурой, которая делает нечто по шагам, пишется декларативная часть, которая указывает какие-то инварианты для этой процедуры, а солвер будет сверять декларацию и императивный код.
Здравствуйте, Ops, Вы писали:
Ops>·>Choco ставит vcbuild tools или как их там, у которых никакого GUI нет, это не лежащая рядом Студия как ты обещал. Ops>choco я для гита привел, студия через него не ставится, для нее другие 2 строчки нужно
Ты обещал "студия с GUI для сборки" — вот и давай свои строчки. Причём тут гит?..
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты обещал "студия с GUI для сборки" — вот и давай свои строчки.
Запросто. Раз ты гуглить не умеешь, то озвучивай предложения. ·>Причём тут гит?..
При том, что ты даже ветку прочитать не в состоянии.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Cyberax, Вы писали:
C>Какие есть формальные методы, которые могут проверять скрипты сборки?
Отсутствие turing complete скриптов, которые могут не только собрать билд но и разобрать половину здания в процессе
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
C>>Какие есть формальные методы, которые могут проверять скрипты сборки? CC>Отсутствие turing complete скриптов, которые могут не только собрать билд но и разобрать половину здания в процессе
Что конкретно полное по Тьюрингу в "touch / myfile"?
Здравствуйте, CreatorCray, Вы писали:
CC>>>Там в итоге бинари подписываются, так что хеши будут всегда разными просто по определению. S>>С чего этого? Время сборки включено в процесс подписывания? CC>Подпись timestamped
Берём timestamp из времени запуска билда. Какие проблемы-то? Для кросс-подписей просто сохраняем их, так как хэш файла будет всегда одинаковый, то и подписи не поменяются.
Более того, при полностью репродуцируемых сборках подпись вообще не нужна — достаточно хэша версии исходников.
Здравствуйте, Слава, Вы писали:
С>>>Формальными методами, наверное. У вас там даже TLA+ начали внедрять. C>>Какие есть формальные методы, которые могут проверять скрипты сборки? С>Вот уж не знаю, какие. Но слово "скрипты" мне уже не нравится. Этот весь sh с питоном.
Для реальных сборок сложных систем часто нужно проводить нетривиальные действия. И это не считая тестов, которые вообще могут быть отдельной не менее сложной системой.
Здравствуйте, CreatorCray, Вы писали:
C>>Ну так чем заменять будем? Люди имеют свойство ошибаться. CC>Теми, кто может
Нету таких.
C>>В том числе и мега-гении из Apple — см. Touchbar. CC>Тачбар придумывали не программисты, надеюсь им икается.
Нет, это только следствие. Apple goto fail — это их фсьо.
C>>Гарантии в том, что билд будет ВСЕГДА повторяемым. Сейчас идёт работа над идеальной повторяемостью — чтобы артефакты можно было с точностью до бита повторять. CC>Может просто надо прекратить порочные практики, которые приводят к тому что билд рушит свой же environment?
См. выше.
C>>Вот! Заметание! Нормальные программы не должны с AV падать. CC>Ну так у вас программа вместо того чтоб на тестах с AV упасть просто молча exception схарчит. Просто потому что вы за ней тут же прибираете и насранную кучу увидеть не сможете.
А у вас она просто работает. Может быть. А может и нет. Никто не знает.
C>>Есть и другие проблемы. Например, мега-гений может установить другую версию MSVS на хост, с другими багами. CC>У вас настолько бардак в билдсистеме?
Нет, у нас билд система повторяется с точностью до бита. Для любой версии. Например, мы можем точно воспроизвести версию 3 лет назад для того, чтобы проверить, что в ней есть (или нет) определённый баг.
Здравствуйте, CreatorCray, Вы писали:
C>>Что конкретно полное по Тьюрингу в "touch / myfile"? CC>То, что этот touch вызывает и потом проверяет.
А вот нифига, это была цель в Maven-скрипте, который типа декларативный.
Здравствуйте, Cyberax, Вы писали:
C>>>В том числе и мега-гении из Apple — см. Touchbar. CC>>Тачбар придумывали не программисты, надеюсь им икается. C>Нет, это только следствие. Apple goto fail — это их фсьо.
Да он как винда, уже много лет "уже не торт".
И всё же...
C>Нет, у нас билд система повторяется с точностью до бита. Для любой версии. Например, мы можем точно воспроизвести версию 3 лет назад для того, чтобы проверить, что в ней есть (или нет) определённый баг.
Строго говоря для этого было бы неплохо ещё и ОС поставить ту, что была тогда.
VM + snapshot тут будет куда более подходящее решение.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 00011011, Вы писали:
0> Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.
Если интересует сборка под windows, то из всех этих файлов интерес представляет ровно один: .appveyor.yml
Там внутри пошаговая инструкция по сборке проекта под windows.
0>Что я хочу сказать? 0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Замечу, что к такой точке зрения msvs абсолютно препендикулярен.
Попробуй qt creator. Там единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом.
Здравствуйте, Vain, Вы писали:
IID>>От меня — не хочет. Community Edition бесплатна. V>Не совсем она бесплатная, под конец месяца отключается если, как понимаю, не зарегистрирована.
Здравствуйте, Ops, Вы писали:
Ops>Мне нет. Навскидку, строчек 5-10, но будет еще choco.
1. Нет на голой винде сhoco.
2. Как с помощью сhoco установить C++ toolchain из MSVC2017?
Здравствуйте, CreatorCray, Вы писали:
CC>Строго говоря для этого было бы неплохо ещё и ОС поставить ту, что была тогда.
Ты не поверишь...
CC>VM + snapshot тут будет куда более подходящее решение.
Ну примерно так и делается
Здравствуйте, Marty, Вы писали:
M>А гитхаб — это не система контроля версий. Гитхаб — это сборка мусора. Помойка кодовая
Это абсолютно не важно. 90% кода это мусор и студенческие поделки, но это же значит, что вся используемые для этого ЯП нодо выкинуть. И git и github это пример мега-успеха и прогресса в разработке ПО.
Здравствуйте, Skorodum, Вы писали:
S>1. Нет на голой винде сhoco.
Он устанавливается в 2 строчки, 1-я — политика исполнения скриптов, 2-я — запуск его установки, все это в PS S>2. Как с помощью сhoco установить C++ toolchain из MSVC2017?
А он для гита и прочих красноглазых поделий, мне неинтересно в особенностях их инсталляторов копаться. Студия как раз в 2 строчки без choco ставится.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Igore, Вы писали:
Ops>>Ты так говоришь, как будто это что-то хорошее. Все эти Qt-шные препроцессоры — это ж говно полное, и обман людей рассказами про плюсы. Только сумрачный красноглазый гений мог такое родить. I>Реальность она не плохая или хорошая, она просто есть, тоже самое справедливо и для protobuf, odb, и других библиотек которые используют кодогенерацию, и если тебе хочется упростить себе жизнь используя их, то нужно их знать хотя бы на минимальном уровне, вот в С++23 может появится reflection, и тогда можно начинать говорить что можно бы все это сделать на чистом С++. А так тебя никто не заставляет использовать Qt, берешь WxWidget или еще что нибудь и вперед, не уверен правда что это будет проще, но более чисто как ты хочешь.
Так я не спорю с реальностью, и даже вынужденно пользуюсь всем этим, что не мешает мне давать таким явлениям оценки.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Skorodum, Вы писали:
S>На кывте с 2002 года, а жаргон как у студента провинциального вуза...
Просто наболело. Я вот объектив не вижу в чём QtCreator лучше VS, кроме кросплатформенности.
Отладчик, точнее интерфейс к нему со стороны QtCreator, выглядит уныло по сравнению с VS.
S>Чтобы утверждать, что проблема в QtCreator надо посмотреть как работает голый отладчик или другая IDE с теми же исполняемыми файлами
Эти же проекты в виде солюшена в VS летают на ура.
S>(в самом QtCreator отладчика даже нет, он вызывает GDB/CDB)
Может в этом и есть причина тормозов.
Здравствуйте, Nikolaz, Вы писали:
N>Просто наболело. Я вот объектив не вижу в чём QtCreator лучше VS, кроме кросплатформенности.
Субъективно "из коробки" редактор и интеграция с гитом на голову лучше. Лагов меньше, навигация лучше ("перейти к..."), код лучше парсит.
Поддержка нескольких компиляторов менее болезненна.
N>Отладчик, точнее интерфейс к нему со стороны QtCreator, выглядит уныло по сравнению с VS.
Согласен.
N>Эти же проекты в виде солюшена в VS летают на ура.
Значит это баг. Такой разницы быть не должно. Напишите в поддержку.
N>Может в этом и есть причина тормозов.
Может быть, там вроде питоновская прослойка, но тормозить не должно.
Здравствуйте, Skorodum, Вы писали:
S>Мне вообще странно, что людям, занимающимся разработкой ПО за деньги, надо объяснять преимущества подхода Infrastructure as code
Да потому что багов в этом коде образуется немеряно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, IID, Вы писали:
IID>Ничего удивительного. Буханке не доверяют даже её одепты. Отчаявшись искоренить дерьмо — смирились с участью вечного подтирания жопы. Дискуссия Cyberax-а и CreatorCray очень показательна.
Извините что встреваю в столь прекрасный срачь, но что такое буханка?
Здравствуйте, Cyberax, Вы писали:
C>И реальные инженеры (а не 1С-ники), которые работают с системами в сотни миллионов строк кода, это понимают и пытаются ограничить последствия ошибок. Тогда как 1С-ники просто считают, что надо писать "без ошибок".
Это админы деградировали до аникейщиков. На билдсервере к копаются все кому захочется, ставят "софт для решения своих задач".
Права нарезать не могут, ошибку найти не могут.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
S>>Мне вообще странно, что людям, занимающимся разработкой ПО за деньги, надо объяснять преимущества подхода Infrastructure as code CC>Да потому что багов в этом коде образуется немеряно.
Нет. Там декларативный подход и обычно оно либо работает, либо нет, примерно так:
* взять Ubuntu 16.04,
* установить git, cmake, gcc, etc
* "cmake && make"
* опубликовать
Ошибки там могут быть только в запятых, путях и отступах и они фатальны.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
CC>>>VM + snapshot тут будет куда более подходящее решение. S>>Ну примерно так и делается CC>Напомню что речь как раз шла не об откате на снапшот а на переустановку скриптами всего build environment с нуля. CC>Что как раз и вызывало недоумение "нафига так корячиться".
Потому что это проще, чем откатываться, ваш кэп. Вот серьезно, расскажи как у вас задокументированно какое ПО установленно на виртуальные билд-сервера. Комментарий к образу виртуальной машины?
У нас это КОД в проекте, и если он не соотвествуют тому, что должно быть для сборки, то проект просто не соберется.
Здравствуйте, CreatorCray, Вы писали:
C>>И реальные инженеры (а не 1С-ники), которые работают с системами в сотни миллионов строк кода, это понимают и пытаются ограничить последствия ошибок. CC>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени.
Все ошибки нельзя исправить. Просто из-за того, что при исправлении появятся новые.
Так что инженеры делают так, чтобы одна ошибка не вызывала критичный сбой всей системы.
Здравствуйте, IID, Вы писали:
IID>Это админы деградировали до аникейщиков. На билдсервере к копаются все кому захочется, ставят "софт для решения своих задач".
Так это у вас рано или поздно такая ситуация будет, просто потому, что она не исключена Как у вас задокументированно состояние билд-серверов?
У нас нет физических серверов, а установка ПО, это строчки кода в исходниках проекта, вся история полностью отражена в системе контроля версий.
IID>Права нарезать не могут, ошибку найти не могут.
Права доступа тут проблему не меняют никак. Всегда есть люди которые могут что-то изменить без особых следов.
IID>Могут только переустанавливать.
Могут автоматизировать и документировать процесс на 100%.
Здравствуйте, CreatorCray, Вы писали:
C>>И реальные инженеры (а не 1С-ники), которые работают с системами в сотни миллионов строк кода, это понимают и пытаются ограничить последствия ошибок. CC>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени.
Одно другое не отменяет. В больших системах часть ошибок на момент релиза еще необнаружена. Более того, часть сбоев принципиально неустранима. Например, сеть никогда не бывает надежной на 100%. Что бы у пользователей, в продакшне, во время эксплуатации не сложилось вообще все, необходимо ограничивать последствия сбоев.
В обычном софтостроении до сих пор со смехом смотрят на резервирование(теория надежности). В больших системах это естественное решение.
Здравствуйте, IID, Вы писали:
IID>Ты не ответил на вопрос. КАЖДАЯ сборка ? IID>Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ? ЗАЧЕМ ? (Кажется кто-то заврался.)
Для того, что бы гарантировать отсутствие влияния нескольких билдов. Если цена ошибки высока, то и не такое можно встретить.
Здравствуйте, IID, Вы писали:
S>>>Кажется кто-то не знает как работают взрослые CC>>Ну и как же называется эта "взрослая" компания? IID>Присоединяюсь к вопросу. IID>Компания, в которой "наиболее типичная проблема" это установка КЕМ-ТО софта на билд сервер для решения своих задач
Здравствуйте, Ikemefula, Вы писали:
I>Для того, что бы гарантировать отсутствие влияния нескольких билдов. Если цена ошибки высока, то и не такое можно встретить.
В том числе и чтобы исключить ситуацию "ничего не знаю, у меня все работает" (например в документации по сборке забыли описать зависимость от чего-то либо необходимость какого-то хитрого патча).
У нас есть гарантия, что как документированно — так и собирается, т.к. код, описывающий сборку, и есть документация, и если он устарел, то сборка не пройдет после первого же коммита.
Здравствуйте, Skorodum, Вы писали:
I>>Для того, что бы гарантировать отсутствие влияния нескольких билдов. Если цена ошибки высока, то и не такое можно встретить. S>В том числе и чтобы исключить ситуацию "ничего не знаю, у меня все работает" (например в документации по сборке забыли описать зависимость от чего-то либо необходимость какого-то хитрого патча). S>У нас есть гарантия, что как документированно — так и собирается, т.к. код, описывающий сборку, и есть документация, и если он устарел, то сборка не пройдет после первого же коммита.
А что у вас за проект, если не секрет ? Или хотя бы область деятельности.
Здравствуйте, CreatorCray, Вы писали:
CC>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени.
Ну так вам и описывают самый правильный для этого подход, при котором ошибка сразу же обнаружится.
Здравствуйте, Ikemefula, Вы писали:
I>А что у вас за проект, если не секрет ? Или хотя бы область деятельности.
Наша область дейятельности это радары и обработка сигналов, но это тут никакой специфики не играет: C/С++/Qt/pyhton/git/CMake и Azure для CI. Все компилится для Win/Mac/Linux и embedded.
Azure работает, не надо думать о свох физических серверах, но медленный (особенно при попытке использовать Docker) и "vendor lock" в чистом виде.
До этого у меня были БД и компилятор: там C++/Qt/git/QBS + Docker + локальный Gitlab. По мне так локальный Gitlab — лучше чем Azure для СI в С++ мире: средство заточенное на решение одной задачи, имеется полный контроль и куда быстрее, но надо не бояться админить сервер. У Azure большой плюс это VSTS (универсальное хранилище, удобно бинари туда пихать, например специфичную версию Qt).
·>Любопытно. А откуда у вас софт на билд-серверах появляется?
Очень просто. Ниоткуда не появляется.
Никакого левого софта у нас там нет. И доступа к изменению чего-либо тоже почти ни у кого нет (буквально 2-3 человека).
Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности.
Здравствуйте, Skorodum, Вы писали:
CC>>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени. S>Ну так вам и описывают самый правильный для этого подход, при котором ошибка сразу же обнаружится.
у тебя совсем память не работает ?
выше был пример "замыливания" от Сайберакса , и его справедливая критика.
Обнаружится он при втором прогоне, когда наступят на какашку от первого.
Но второй прогон памперс от первого выбросит и не увидит кровавого поноса.
IID>·>Любопытно. А откуда у вас софт на билд-серверах появляется? IID>Очень просто. Ниоткуда не появляется.
Я не спрашиваю про левый софт. Я спрашиваю как на билд-сервере появляется какой-либо софт?
IID>Никакого левого софта у нас там нет. И доступа к изменению чего-либо тоже почти ни у кого нет (буквально 2-3 человека).
Т.е. у вас происходит именно это: "установка КЕМ-ТО [2-3 человека] софта на билд сервер для решения своих задач [задачи билда]". Верно?
IID>Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности.
А какая должна быть идея о том что там можно запускать и как это контролируется?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
IID>>>установка КЕМ-ТО софта на билд сервер для решения своих задач CC>·>Любопытно. А откуда у вас софт на билд-серверах появляется? CC>Биткоин майнеры "для решения своих задач" на билд серверах не появляются совсем
Поздравляю! Великое достижение! А небиткойн майнеры там появляется телепатически?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IID, Вы писали:
IID>Строчки кода и переустановка при каждом билде это ортогональные вещи.
Нет. Это то, как это реализовано. Код описывает всю инфрастуктуры и все шаги для сборки, и это часть проекта.
S>>Права доступа тут проблему не меняют никак. Всегда есть люди которые могут что-то изменить без особых следов. IID>Какой бардак
Так это у вас так У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще.
IID>Нет, не могут. Могли бы — сделали бы последовательные билды стабильными.
Так у нас все сделано
IID>Без костылей с полной переустановкой.
Дело не в переустановке, а в отношении к инфраструктуре сборки. У вас это отдельная вещь, у нас — неотъемлемая часть проекта с полной историей.
Минусы вашего подхода очевидны, но вы с Креатором упираетесь почему-то.
Здравствуйте, ·, Вы писали:
·>Т.е. у вас происходит именно это: "установка КЕМ-ТО [2-3 человека] софта на билд сервер для решения своих задач [задачи билда]". Верно?
Верно. Только существенную часть ты в скобки поместил.
IID>>Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности. ·>А какая должна быть идея о том что там можно запускать и как это контролируется?
Самое простое и правильное — билсервер никогда и ничего не исполняет из репозитория.
Если очень надо — придётся кропотливо настраивать права. Чтобы исполяемое могло сделать ровно то, что ему разрешено. И то это не панацея, LPE никто не отменял.
А тут вы бессильны, потому как даже пробел в пути диагностировать не можете (из обсуждения выше), предпочитая сносить всё дотла.
Ты просто представь на секунду, что такой бардак случится в каком-нибудь Apple, MS или Google ?
Достаточно устроиться сотрудником, и через заливки в GIT можно атаковать билдсервер, красть сертификаты (или хотя бы подписывать свой код ими), ослаблять шифрование, вносить закладки (невидимые, вносимые в момент компиляции пропатченным в памяти компилятором).
Здравствуйте, Skorodum, Вы писали:
S>Код описывает всю инфрастуктуры и все шаги для сборки, и это часть проекта.
Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Кроме того сборка на билд-сервере может существенно отличаться от сборки на машинах разработчиков.
И твои билдсерверные "инструкции" сгодятся только для подтирки задницы.
Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации.
Эпл, например, даже fingerprint-ит ключевые вещи, чтобы вычислить потенциальную утечку.
S>У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще.
Они не устанавливают на билд-сервер что-попало, в отличе от вас.
S>Минусы вашего подхода очевидны, но вы с Креатором упираетесь почему-то.
Да бог с ним, с нашим подходом. Вы сначала сумейте показать плюсы своего. Пока что заметно только раздутое ЧСВ и упорное нежелание конструктивно отвечать (тот же пример с замыливанием ошибки).
Здравствуйте, IID, Вы писали:
IID>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Это уже детали реализации и зависит от используемой инфраструктуры. При использовании Docker'а можно брать закэшированные образы. С Azure это не работает, там приходится брать готовые образы ВМ и доустанавливать необходимое.
Главное суть — инфраструктура необходимая для сборки описана в проекте.
IID>Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Бред какой-то. Результат работы процесса сборки это продукт. Каждый шаг сборки либо проходит, либо нет, любая ошибка означает провал всей сборки.
IID>Кроме того сборка на билд-сервере может существенно отличаться от сборки на машинах разработчиков.
Может. Это никак не протеворечит факту, что описание для билд-сервера является эталоном и должно воспроизводится где угодно, а как отдельные разработчики извращаюся — абсолютно не важно.
IID>И твои билдсерверные "инструкции" сгодятся только для подтирки задницы.
Ну у кого как
IID>Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации.
И?
IID>Эпл, например, даже fingerprint-ит ключевые вещи, чтобы вычислить потенциальную утечку.
И?
S>>У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще. IID>Они не устанавливают на билд-сервер что-попало, в отличе от вас.
В отчличии от вас у нас любые изменения для "билд-серверов" (которых у нас и физически нет, BTW) отражаются в системе контроля версий.
IID>Да бог с ним, с нашим подходом. Вы сначала сумейте показать плюсы своего.
Да много раз уже показали, но вам религия не позволяет видеть
IID>Пока что заметно только раздутое ЧСВ
Это как раз сторонники МС этим страдают и нежеланием учится и адоптироваться.
IID>и упорное нежелание конструктивно отвечать (тот же пример с замыливанием ошибки).
Ну вообще-то это ты ярлыки навешиваешь и упорно не отвечаешь на вопрос как у вас документирвано состояние билд-серверов.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC. НС>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд?
Минут? Контейнер запускается за секунды. Это же не Винда.
НС>Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах.
Часами у нас даже Буст не строится.
Здравствуйте, Michael7, Вы писали:
M>Просто по определению не выйдет стандартизировать поведение сборщиков других языков. Но на самом деле все еще интереснее. Например, Qt строго формально вообще не на C++ написана. Используются некоторые расширения, которых нет в языке, а компилируется компилятором C++ только после того как специальный препроцессор (qmake) развернет их. И вот как это со стандартом совместить? Не говоря о том, что заставить комитет никого не может, следование стандарту в общем-то добровольное.
Qt как раз таки написана на С++ и использует кодогенерацию. Ничего плохого в этом нет. А кодогенерация есть много где, отличный пример — тот же google protobuf.
Здравствуйте, Skorodum, Вы писали:
НС>>Образ ВМ, снапшоты? Не, не слышал. S>Это решение, но не идеальное
Оно куда идеальнее, чем накатывать на голый образ тулы при каждой сборке.
S>: как документировано состояние ВМ? Нет никакой гарантии, что описанный процесс сборки в каком-нибудь README.md и ВМ полностью соотвествуют друг другу.
Если тебя одолевает паранойя по поводу того, что враги подменят образ внезапно, то всегда можно собирать образ/контейнер при помощи того же CI, но строго только при изменении скриптов подготовки ВМ.
Здравствуйте, Ikemefula, Вы писали:
НС>>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах. I>Одна ошибка раз в год может спокойно перевесить суммарную стоимость всех билдов вместе взятых.
Вопрос не в стоимости, вопрос в трате времени разработчиков. Ну и с такой паранойей надо не С++ использовать точно, ибо шансов наломать дров в коде намного порядков больше, чем в криптах сборки.
Здравствуйте, Cyberax, Вы писали:
C>>>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC. НС>>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? C>Минут? Контейнер запускается за секунды. Это же не Винда.
При чем тут контейнер? Окончательно утерял нить разговора? Речь шла не про контейнер, а про apt get gcc. А контейнер и для vs приготовить несложно.
НС>>Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах. C>Часами у нас даже Буст не строится.
Ну да, облако то свое, можно 100500 процессорные машинки под билд использовать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах. I>>Одна ошибка раз в год может спокойно перевесить суммарную стоимость всех билдов вместе взятых.
НС>Вопрос не в стоимости, вопрос в трате времени разработчиков. Ну и с такой паранойей надо не С++ использовать точно, ибо шансов наломать дров в коде намного порядков больше, чем в криптах сборки.
А ты в курсе, что у разных проектов приоритеты разные ? У одних цена ошибки считается миллионами долларов или даже жизнями, а в других важнее считать время разработчиков, потому что свистелка выйдет на два доллара дороже в пересчете на лицензию
Здравствуйте, Ikemefula, Вы писали:
I>Такое применяется вне зависимости, с++ или нет. Нужны гарантии, что билд, деплой, и тд запустится в чистом окружении.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>При чем тут контейнер? Окончательно утерял нить разговора? Речь шла не про контейнер, а про apt get gcc. А контейнер и для vs приготовить несложно.
Так это ж "мутные файлы" и идиология от "осиляторов"
З.Ы. MS приходит к тому, что есть у "осиляторов" уже 5+ лет. Так и до вас с IID дойдет
Здравствуйте, _NN_, Вы писали:
D>>А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому.
_NN>Обычно прямые слэши проблем не вызывают: _NN>
К слову сказать, не которые консольные команды плохо работают с неправильным слэшем — например, команда dir.
Но меня радует bash под виндой — который поставился с тортилкой гит — вроде и всем хорош, а переводы строк виндовые не понимает. Это бесит даже больше, чем буханочный make, не понимающий пробелы
Здравствуйте, Marty, Вы писали:
M>К слову сказать, не которые консольные команды плохо работают с неправильным слэшем — например, команда dir.
Так там "/" это указание флага.
Если нужен путь то экранируйте:
dir "c:/"
M>Но меня радует bash под виндой — который поставился с тортилкой гит — вроде и всем хорош, а переводы строк виндовые не понимает. Это бесит даже больше, чем буханочный make, не понимающий пробелы
Здравствуйте, Skorodum, Вы писали:
НС>>Это к ТС. Речь про apt зашла совсем в другом контексте. S>Да в этой ветке уже сложно найти хоть какую-то связанную мысль
Мне несложно. Уж по крайней мере отличить разговор про apt и контейнеры.
НС>>Ну да, куда ж без красноглазого хамства. S>Вот честно, лень искать сейчас по топику, но тон тут задал "про-MS" лагерь в лице ТС, "Славы", IID и CreatorCray.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>А ты в курсе, что у разных проектов приоритеты разные ? У одних цена ошибки считается миллионами долларов или даже жизнями
НС>И там С++ не используют
Здравствуйте, Cyberax, Вы писали:
C>Весь код — это глюкодром. ВООБЩЕ весь код, без исключения. Даже в TeX есть баги.
Вот только основной код системы, как правило, на порядки больше и на порядки сложнее. В результате вероятность появления багов в нем на много порядков выше. Но вы жертвуете временем билда чтобы наловить каких то очень редких блох, заметляя фикс в основном коде. Логика.
Здравствуйте, ·, Вы писали:
IID>>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ? ·>Чтобы 100% гарантировать, что текущий билд никак не зависит от предыдущих. Это самый простой и дешевый способ. Очевидно почему?
Для этого нет нужны накатывать все с нуля.
IID>>Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации. ·>Угу. И соответственно отдельные репы с ограниченным доступом.
Тогда теряется весь нам тут расписываемый кайф, когда инфраструктура жестко связана с кодом.
Здравствуйте, Skorodum, Вы писали:
IID>>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ? S>Это уже детали реализации и зависит от используемой инфраструктуры.
Нет, это принципиальный момент в контексте разговора.
S>При использовании Docker'а можно брать закэшированные образы. С Azure это не работает
Все там прекрасно работает. Есть и репы МС, и собственный реестр образов и контейнеров можно завести.
Здравствуйте, Skorodum, Вы писали:
CC>>А тебе твои боги по другому под страхом смерти запрещают что ли? S>Да как угодно, только чтобы это было легко и можно было автоматизировать.
Ссылку на то как это делается я здесь уже давал.
S> Почему МС не хочет сделать это процесс легким —
Потому что кто то по незнанию начинает придумывать удобные факты.
Здравствуйте, Skorodum, Вы писали:
Ops>>но тут рядом отстаивают необходимость этот мусор, и всякий сопутствующий ему цыгвын, обязательно таскать вместе с ним. S>Уже вроде не обязательно. Есть же WSL, а там все родное: apt install git.
А можно и без линуксового стаффа.
S>З.Ы. Никто не мешает ни тебе, ни МС запилить свою версию гита с бледжеком и без зависимостей
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, это принципиальный момент в контексте разговора.
Принципиальный обсуждаемые момент это "мутные файлы" и определение инфраструктуры сборки. ТС хочет иметь в корне только "MySuperProject.sln" и легкую сборку на своей машине, но это уровень начала 2000-х. Определение процесса сборки через travis.yml, azure-pipelines.yml или Dockerfile это уже промышленный стандарт. Какое количество софта при этом переустанавливается — абсолютно не принципиально (да и в реальности не важно, т.к. практическая реализация все это может кэшировать).
НС>Все там прекрасно работает. Есть и репы МС, и собственный реестр образов и контейнеров можно завести.
Можно, но для CI и build pipelines это о-о-о-о-очень медленно (source: пару месяцев назад именно с этим и эксперементировал). docker pull виндового образа занимает 40+ минут (там же вложенная виртуализация получается да и размер виндовых образов 5+ Gb, ЕМНИП).
Здравствуйте, Ночной Смотрящий, Вы писали:
Ops>>>но тут рядом отстаивают необходимость этот мусор, и всякий сопутствующий ему цыгвын, обязательно таскать вместе с ним. S>>Уже вроде не обязательно. Есть же WSL, а там все родное: apt install git. НС>А можно и без линуксового стаффа.
Тут ты нить дискуссии потерял. У Ops притензии к софту который идет с гитом, ему видать хочеться устанавливать только git.exe.
S>>З.Ы. Никто не мешает ни тебе, ни МС запилить свою версию гита с бледжеком и без зависимостей НС>Так уже давно запилено.
Вот прям полностью альтернативная реализация в результате которой устанавливается только git.exe? или ты про LFS расширение?
Здравствуйте, Skorodum, Вы писали:
S>Вот прям полностью альтернативная реализация в результате которой устанавливается только git.exe? или ты про LFS расширение?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я про libgit
Ну так в чем проблема Ops'у использовать минимальную обертку над этой библиотекой и не раздражаться от наличия Git Bash? Подскажи ему.
Ну и что-то мне подсказывает, то за libgit больше "осиляторов", чем сторонников *.sln.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ссылку на то как это делается я здесь уже давал. НС>Потому что кто то по незнанию начинает придумывать удобные факты.
Да, есть прогресс, только несмотря на относительно безграничные ресурсу лет на дцать отстают.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Для этого нет нужны накатывать все с нуля.
Это самый простой и надежный способ. Все остальное гарантий не дает.
НС>Тогда теряется весь нам тут расписываемый кайф, когда инфраструктура жестко связана с кодом.
Нет, связать репы не проблема ни разу.
Здравствуйте, Ночной Смотрящий, Вы писали:
IID>>>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ? НС>·>Чтобы 100% гарантировать, что текущий билд никак не зависит от предыдущих. Это самый простой и дешевый способ. Очевидно почему? НС>Для этого нет нужны накатывать все с нуля.
А какие другие варианты?
Ну, скажем, типичный пример для виндомира — версия .net framework. Может меняться туда-сюда ради экспериментов, ревертов или бисектов.
"Осиляторы", конечно, обычно не пишут такой эпиквин как .net framework, который вгрызается в систему по самые гланды и хрен выковыряешь без переустановки с нуля... но ведь можно банально и ошибиться (а мы говорим о 100% гарантии) и где-то не так наследить.
IID>>>Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации. НС>·>Угу. И соответственно отдельные репы с ограниченным доступом. НС>Тогда теряется весь нам тут расписываемый кайф, когда инфраструктура жестко связана с кодом.
Что значит "жестко"? И как будет "нежестко"?
У вас весь код лежит в одном репо и все всё могут видеть и править?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Вежливость это не ругать то, чего не знаешь. НС>Глупость сейчас сказал.
Ну так называть С++ "языком курильщика" это либо от недостатка опыта, либо от недостатка ума
S>> Если ты занимаешься задачами, где и C# подойдет — прекрасно, у него есть свои достоинства, но не стоит критиковать решения, которые созданы для задач о которых ты не знаешь. НС>А вот очередной переход на личности это точно к вежливости отношения не имеет.
В чем тут переход на личности? Ну сидишь ты в виндовом мире без ограничения на энергию и память — можешь и C# использовать. Только вот задачи бывают и совсем другими и альтернатив С/С++ там нет.
S>>Есть задачи, где С/С++ нет никой альтернативы и не появится в обозримой исторической перспективе. НС>Страдай. Могу тебе только посочувствовать.
Зачетный слив
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Это не столь очевидно. Процесс сборки это склейка/использование нескольких больших и очень сложных систем (система сборки, компиляторы, etc). И сложность там растет совсем не ленейно. Собственно весь топик об этом: если надо сделат HelloWorld под Win, то все просто и в студии, а если надо кроссплатформенный HelloWorld, то все становится намного веселее НС>Ну да, все опять свелось к языку курильщика.
А причём тут язык? Можно лабать вебсайтики на священном c# в родной Студии. Но вот захочется (а в любом сколько-нибудь нетривиальном проекте захотеть придётся) во время билда чего-нибудь необычного, прогонять какие-нибудь selenium-тесты, да ещё и на разных браузерах, разных версий — вот сложность и попёрла.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Skorodum, Вы писали:
НС>>Глупость сейчас сказал. S>Ну так называть С++ "языком курильщика" это либо от недостатка опыта, либо от недостатка ума
Это мое личное мнение, и ничего невежливого в его высказывании нет. А вот ты опять нахамил.
НС>>А вот очередной переход на личности это точно к вежливости отношения не имеет. S>В чем тут переход на личности?
При том что это самое натуральное хамство и есть.
S> Ну сидишь ты в виндовом мире без ограничения на энергию и память — можешь и C# использовать
Не угадал.
S>Только вот задачи бывают и совсем другими и альтернатив С/С++ там нет.
Я тебе уже сказал — сочувствую. Что ты еще от меня хочешь? Чтобы я одобрял этот маразм языкостроения? С какой стати?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну так называть С++ "языком курильщика" это либо от недостатка опыта, либо от недостатка ума НС>Это мое личное мнение, и ничего невежливого в его высказывании нет.
Тут я с ним соглашусь — ты спорол фигню, доколебавшись до языка.
НС>Чтобы я одобрял этот маразм языкостроения?
Что, ниасилил? Бывает.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>А причём тут язык? НС>При том что именно он тут основной источник проблем.
Руки из задницы — основной источник проблем, а не язык.
А так даже на Perl можно писать чистые и внятные программы. Достаточно всего то думать своим межушным ганглием а не следовать моде.
НС>Так что могу только согласиться с IID — сначала разводят фантастический, с наслоениями, бардак, спихнув сборку на самых низкоквалифицированных разработчиков, а потом придумывают чудовищные с инженерной точки зрения костыли.
Читай выше — руки из задницы, как и говорилось.
Ну а поскольку разрабы привыкли лабать в vi (хорошо что хоть не в ed) и писать скрипты на каждый чих то и билд они точно так же "автоматизируют", этими же руками.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
НС>>Это мое личное мнение, и ничего невежливого в его высказывании нет. CC>Тут я с ним соглашусь — ты спорол фигню, доколебавшись до языка.
Фигню или нет, это другой вопрос. Но я на личности не переходил, в отличие от вас.
НС>>Чтобы я одобрял этот маразм языкостроения? CC>Что, ниасилил? Бывает.
Здравствуйте, vsb, Вы писали:
vsb>В современных языках обычно так. В С++ вроде cmake стандарт де-факто, ну autotools это ещё юниксовое наследие. А что, старый добрый ./configure && make не срабатывает?
autotools это неюзабельное нечто. А этот их m4 прямо создан для того, чтобы на нём было невозможно писать.
Здравствуйте, vsb, Вы писали:
vsb>Почему? По-моему хороший препроцессор. Как-то применял, уж не помню точно для чего, но он свою задачу хорошо выполнил. А какой препроцессор лучше m4?
Как по мне, все языки макроподстановок малоюзабельны как класс.
Здравствуйте, Hobbes, Вы писали:
vsb>>Почему? По-моему хороший препроцессор. Как-то применял, уж не помню точно для чего, но он свою задачу хорошо выполнил. А какой препроцессор лучше m4?
H>Как по мне, все языки макроподстановок малоюзабельны как класс.
И что делать, если мне нужно сгенерировать текст по шаблону? Писать программу на Perl? M4 мне отлично подошёл, это же DSL. Если людям лень делать свой язык программирования и они пользуются готовым вроде M4 это не его проблема.
Здравствуйте, CreatorCray, Вы писали:
НС>>·>А причём тут язык? НС>>При том что именно он тут основной источник проблем. CC>Руки из задницы — основной источник проблем, а не язык. CC>А так даже на Perl можно писать чистые и внятные программы. Достаточно всего то думать своим межушным ганглием а не следовать моде.
Если ты один на проекте — то можно. Но как только разработчиков становится больше трёх, на Перле само собой возникает непотребство. Это заложено в язык, конструкции позволяют добиваться прямо противоположными путями, например, всё явно, и все неявно.
Проблема в том, что поддерживать, менять, чистить и тд и тд можно только первый вариант, а второй рано или поздно заходит в тупик.
Но даже с перлом есть проблемы поважнее, например демо-дривен-девелопмент. Это никакого отношения ни к языку, ни к рукам не имеет, это в чистом виде проблема в головах.
НС>>Так что могу только согласиться с IID — сначала разводят фантастический, с наслоениями, бардак, спихнув сборку на самых низкоквалифицированных разработчиков, а потом придумывают чудовищные с инженерной точки зрения костыли. CC>Читай выше — руки из задницы, как и говорилось.
Это не руки, это менеджмент. Например, демо-дривен-девелопмент начинают не разработчики. В таком режиме высококвалифицированые люди пилят фичи, наспех, потому что быстрее их никто не может, а низкоквалифицированые тем временем пилят всё, что не фичи — в т.ч. архитектуру.
CC>Ну а поскольку разрабы привыкли лабать в vi (хорошо что хоть не в ed) и писать скрипты на каждый чих то и билд они точно так же "автоматизируют", этими же руками.
Ага, разрабы во всём виноваты, а менеджмент ни к чему не причастен.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Так что могу только согласиться с IID — сначала разводят фантастический, с наслоениями, бардак, спихнув сборку на самых низкоквалифицированных разработчиков, а потом придумывают чудовищные с инженерной точки зрения костыли.
При чем здесь язык, если ты вот этим предложением описываешь совсем другую проблему ? Каким образом язык вынуждает людей спихивать сложную работу на низкоквалифицированых разработчиков ?
И почему описываемая здесь проблема, когда сложную, важную работу делает низкоквалифицированый работник, встречается практически во всех основных стеках технологий ?
Здравствуйте, Ikemefula, Вы писали:
I>При чем здесь язык, если ты вот этим предложением описываешь совсем другую проблему ? Каким образом язык вынуждает людей спихивать сложную работу на низкоквалифицированых разработчиков ?
Язык здесь при том, что, в силу его особенностей, эта работа сложнее и утомительнее, чем могла бы быть.
I>И почему описываемая здесь проблема, когда сложную, важную работу делает низкоквалифицированый работник, встречается практически во всех основных стеках технологий ?
Потому что частота, с которой она встречается, сильно зависит от этого самого стека.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>При том что именно он тут основной источник проблем. НС>·> Можно лабать вебсайтики на священном c# в родной Студии. Но вот захочется (а в любом сколько-нибудь нетривиальном проекте захотеть придётся) во время билда чего-нибудь необычного, прогонять какие-нибудь selenium-тесты, да ещё и на разных браузерах, разных версий — вот сложность и попёрла.
По твоему, Селениум тесты это проблема в языке ?
НС>Впрочем, у меня все это гоняется, и селениумы и много чего еще (например, один из проектов собирается под 13 платформ, и тесты тоже на всех них гоняются). Но чего то описанных ужасов со сборкой нет — прекрасно работает на куче разных билд-серверов и локально на машинах разработчиков.
Так а язык при чем здесь ?
>Так что могу только согласиться с IID — сначала разводят фантастический, с наслоениями, бардак, спихнув сборку на самых низкоквалифицированных разработчиков, а потом придумывают чудовищные с инженерной точки зрения костыли.
Вот и выяснилось, что проблема не в языке. Ты описал совсем другую проблему. На самом деле это частный случай. Общий — на низкоквалифицированых спихивают всё, что не представляет непостредственной ценности для заказчика. Или для демо. В одном случае получается feature driven development, во втором demo driven development.
Причина проблемы в том, какие обязанности по факту выполняют разработчики. То есть, как организована работа. То есть — менеджмент.
Например, когда процесс пустили на самотёк, девелоперы берут то, что им интереснее, привычнее, легче и тд. Те, у кого влияния больше, берут в первую очередь. Остальные разбирают остатки.
Разумеется, важные вещи далеко не всегда приятные, интересные. Но вот ими в таком случае будут заниматься абы кто.
Непосредственная пробелма в языке и квалификации тех, кто настраиват билды.
Но на самом деле проблема в том, что разработку пустили на самотёк.
Здравствуйте, Ikemefula, Вы писали:
НС>>·> Можно лабать вебсайтики на священном c# в родной Студии. Но вот захочется (а в любом сколько-нибудь нетривиальном проекте захотеть придётся) во время билда чего-нибудь необычного, прогонять какие-нибудь selenium-тесты, да ещё и на разных браузерах, разных версий — вот сложность и попёрла. I>По твоему, Селениум тесты это проблема в языке ?
По моему кто то не умеет цитировать.
И какой смысл задавать одн и и те же вопросы, если я на них уже ответил? Забыл что один раз на это сообщение уже ответил?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>При чем здесь язык, если ты вот этим предложением описываешь совсем другую проблему ? Каким образом язык вынуждает людей спихивать сложную работу на низкоквалифицированых разработчиков ?
НС>Язык здесь при том, что, в силу его особенностей, эта работа сложнее и утомительнее, чем могла бы быть.
Ты пишешь, что язык только усугубляет проблему. Это и ежу ясно. Но что бы язык усугубил проблему, она должна откуда то взяться.
Так каким образом язык вынуждает людей спихивать сложную работу на низкоквалифицированых разработчиков ?
I>>И почему описываемая здесь проблема, когда сложную, важную работу делает низкоквалифицированый работник, встречается практически во всех основных стеках технологий ?
НС>Потому что частота, с которой она встречается, сильно зависит от этого самого стека.
Нисколько не зависит, просто проявляется по разному.
Здравствуйте, Слава, Вы писали:
С>Вы не туда воюете сейчас. Подобный спор следует вести в другом треде, но не в этом точно.
Переживаешь за раскол в стане союзников?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Язык здесь при том, что, в силу его особенностей, эта работа сложнее и утомительнее, чем могла бы быть.
Требуется большая квалификация, чтобы вытянуть из железа все что можно да еще и кроссплатформенно, но ничем другим ты такого не сделаешь.
Да и при нормалном инструментарии, налаженном процессе и прямых руках разработка на плюсах ничуть не медленнее, чем на каких-нибудь C# или Java (особенно в областях где оснавная часть кода это алгоритмы, а не формы).
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Если ты занимаешься задачами, где и C# подойдет — прекрасно, у него есть свои достоинства, но не стоит критиковать решения, которые созданы для задач о которых ты не знаешь.
НС>А вот очередной переход на личности это точно к вежливости отношения не имеет.
Прочитал его сообщение раз десять. Где именно ты видишь переход на личности ?
Даже если ты себя видишь специалистом в радарах и обработке сигналов, то сильно вряд ли ты работаешь со Skorodum, и точно не в курсе задач его проекта. Но вот его решения ты пытаешься критиковать, при чем даже не уточнив, а что за поле деятельности у этого товарища.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это мое личное мнение, и ничего невежливого в его высказывании нет. А вот ты опять нахамил.
Ну так это мое лично мнение о подобных высказываниях
НС>При том что это самое натуральное хамство и есть.
Хамство это навешивание ярлыков на использующих какой-то иснтрумент.
S>>Только вот задачи бывают и совсем другими и альтернатив С/С++ там нет. НС>Я тебе уже сказал — сочувствую.
Хамство.
НС>Что ты еще от меня хочешь? Чтобы я одобрял этот маразм языкостроения? С какой стати?
Чтобы ты рассказал как ты решаешь подобные задачи: кроссплатформенная разработка критичного к ресурсам софта.
Например, у значительная часть софта должен умещаться в 4 мегабайта памяти (но работать и под всеми "стандартными" платформами тоже).
Здравствуйте, Ikemefula, Вы писали:
НС>>Язык здесь при том, что, в силу его особенностей, эта работа сложнее и утомительнее, чем могла бы быть. I>Ты пишешь, что язык только усугубляет проблему. Это и ежу ясно. Но что бы язык усугубил проблему, она должна откуда то взяться.
Иногда количество переходит в качество.
I>Так каким образом язык вынуждает людей спихивать сложную работу на низкоквалифицированых разработчиков ?
Обычным. Чем нуднее и скучнее работа, тем больше соблазна спихнуть его на джуна, который прав не имеет.
Здравствуйте, Skorodum, Вы писали:
НС>>Язык здесь при том, что, в силу его особенностей, эта работа сложнее и утомительнее, чем могла бы быть. S>Требуется большая квалификация, чтобы вытянуть из железа все что можно да еще и кроссплатформенно, но ничем другим ты такого не сделаешь.
И? Ты к чему это сказал?
S>Да и при нормалном инструментарии, налаженном процессе и прямых руках разработка на плюсах ничуть не медленнее, чем на каких-нибудь C# или Java (особенно в областях где оснавная часть кода это алгоритмы, а не формы).
Ну да, только почему то приходится при сборке каждый раз все с нуля накатывать, абы чего не вышло.
Здравствуйте, Skorodum, Вы писали:
НС>>Это мое личное мнение, и ничего невежливого в его высказывании нет. А вот ты опять нахамил. S>Ну так это мое лично мнение о подобных высказываниях
Хамство — оно в любом случае твое личное мнение. Но хамством, ЧСХ, от этого оно быть не перестает.
НС>>При том что это самое натуральное хамство и есть. S>Хамство это навешивание ярлыков на использующих какой-то иснтрумент.
Нет, хамство это переход на личности с навешиванием ярлыков на человека. А нахамить инструменту — это, извини, уже что то из области психиатрии.
S>>>Только вот задачи бывают и совсем другими и альтернатив С/С++ там нет. НС>>Я тебе уже сказал — сочувствую. S>Хамство.
Сочувствие у тебя хамство? Жесть.
НС>>Что ты еще от меня хочешь? Чтобы я одобрял этот маразм языкостроения? С какой стати? S>Чтобы ты рассказал как ты решаешь подобные задачи: кроссплатформенная разработка критичного к ресурсам софта.
Зачем? Ты как то странно понимаешь мои слова. Я не спорю с тем что у тебя есть объективные причины грызть кактус. Вот только от их наличия кактус кактусом быть не перестает. И никакого хамства в том чтобы назвать кактус кактусом нет, даже с огроменной натяжкой.
Здравствуйте, Cyberax, Вы писали:
C> C>CMake позволяет просто указать флаги и подключить библиотеку из файла сборки основного приложения...
Слово просто тут лишнее.
Я тут недавно подключал gRPC к кросс-платформенной библиотеке через CMake. Так вот, эта зараза не собирается под виндой, если явно не установить OpenSSL. Нельзя просто так взять и сделать add_subdirectory или FetchContent_GetProperties. А без полной сборки не создавался файл .targets => не работал find_package. И было требование сделать сборку с автоматическим подтягиванием зависимостей под все платформы. Причём на не нужен был весь gRPC, а лишь либы, необходимые для реализации клиентской части. В результате проект подключался через add_subdirectory(...EXCLUDE_FROM_ALL) и делалась ручная муть типа install(targets, install(directories, install(export и т.п. для того, чтобы наша библиотека могла создать корректный cmake package. Отдельный фокус — это определение версии gRPC при том, что не работает find_package.
В результате вышло под 300 строк кода на CMake просто чтобы скомпилировать пяток .cc файлов и подключить gRPC.
Понятно, что в идеале можно было обойтись инструкцией, типа "соберите и установите gRPC с нужными флагами сами", но решили сделать добро для пользователей, чтобы всё собиралось из коробки.
Здравствуйте, Skorodum, Вы писали:
S>Конечно, но тут высказывают огульные притензии к "осилятором" и "красноглазикам" за то, что они, видители, как-то плохо гит на винду портировали.
Да потому что это даже портированием нельзя назвать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Vain, Вы писали:
IID>>От меня — не хочет. Community Edition бесплатна. V>Не совсем она бесплатная, под конец месяца отключается если, как понимаю, не зарегистрирована.
Пользуюсь годами MSVS Community Edition (да, именно бесплатно) — просто я создал свой MS Account!
При этом у меня линейка студий (Community) на машинке: это 2013, 2015 и 2017 стоят и
между собой они не конфликтуют. Ниже я указал, как ставить, чтобы не конфликтовали.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Прочитал его сообщение раз десять. Где именно ты видишь переход на личности ?
НС>Решил его адвокатом поработать что ли? Ну так прочти всю тему.
Намекаешь, что ты выставил счет в первом попавшемся сообщеннии? Так и запишем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зачем? Ты как то странно понимаешь мои слова. Я не спорю с тем что у тебя есть объективные причины грызть кактус. Вот только от их наличия кактус кактусом быть не перестает. И никакого хамства в том чтобы назвать кактус кактусом нет, даже с огроменной натяжкой.
Похоже, что кактус это все, кроме твоего проекта. Ты это в разной форме говоришь практически всем. Может все ровно наоборот, это твой проект тебе видится кактусом? Соболезную.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>А язык тут при чем? Ты описываешь ситуацию, когда проект пустили на самотек. Виноват в этом почемуто язык. Почему — в ответ только общие слова.
НС>Нет, я ответил вполне конкретно почему. Если тебя мой ответ не устраивает (а тебя, очевидно, устроит только один ответ) — ничем помочь не могу.
Вся твоя конкретика — "Иногда количество переходит в качество."
На самом деле если важная и сложная работа отдается новичкам и неумехам, то это говорит о том, что в команде отсутствует управление, а те кто имеют влияние, просто берут задачи по интересу или вовсе на резюме работают, ну может на демо.
Я это видел и в дотнете, и в джаве, и в бакенде, и во фронтенде, и в фулстеке, и в мобале, и в десктопе, нужное вписать.
Языки, платформы, проекты разные, а проблема одна.
Здравствуйте, Skorodum, Вы писали:
S>>>Вежливость это не ругать то, чего не знаешь. НС>>Глупость сейчас сказал. S>Ну так называть С++ "языком курильщика" это либо от недостатка опыта, либо от недостатка ума
Либо, наоборот, от достаточного количества опыта и понимания, что если начинался C++ ещё нормально, то то, что происходило позже, это типичная ситуация полёта тачанки со взбесившимися конями с обрыва, когда спрыгивать невозможно, и единственное, что остаётся — кричать "Уррраа!!!"
В некоторой степени такая проблема есть у всех, но у C++ она в разы сильнее, чем у аналогов-конкурентов.
S>>>Есть задачи, где С/С++ нет никой альтернативы и не появится в обозримой исторической перспективе.
Ну, да, есть. Только пока что 99% случаев это "уже есть мегатонна кода на C++, мы не можем её переписать", и только 1% на "нет альтернатив". Для C вторая цифра заметно больше — процентов, может, 20.
Но обе ужимаются на глазах — от их областей отгрызают по кусочку и Java/C#, и Rust, Go, Swift, и прочие.
Здравствуйте, netch80, Вы писали:
N>А если надо позже добавить более раннюю? (а это более чем реальный и частый вариант запроса) N>Всё переустанавливать? Ну гениально, чо.
Так вот выше машины для сборки именно таким образом и подготавливают
Здравствуйте, Слава, Вы писали:
N>>А если надо позже добавить более раннюю? (а это более чем реальный и частый вариант запроса) N>>Всё переустанавливать? Ну гениально, чо.
С>Так вот выше машины для сборки именно таким образом и подготавливают
Ничего общего, и тебе это уже подробно разъяснили.
Здравствуйте, Cyberax, Вы писали:
C>VIM нынче умеет автодополнение, навигацию, рефакторинги. GDB с плугинами на Питоне тоже вполне можно использовать. Непривычно после IDE, но вполне себе эффективно.
Я всё же предпочту это всё в удобном виде.
Тут проблема в идеологии что vim что gdb
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>В приличном обществе не принято говорить о подобных извращениях!
Это примерно как заявление Маркиза де Сада о нормах половой жизни
Здравствуйте, Skorodum, Вы писали:
N>>Ну, да, есть. Только пока что 99% случаев это "уже есть мегатонна кода на C++, мы не можем её переписать", и только 1% на "нет альтернатив". Для C вторая цифра заметно больше — процентов, может, 20. S>За исключением деталей утверждение верное для любых других языков в не меньшей степени, но зачем переписывать и использовать другие языки?
"не можем переписать/отрефакторить" это большей частью к С++ относится. Вот это исключительно проблема языка. Сюда же долгий период вхождения. Так же, в с++ сообществе принято винить кривые руки. Практика показывает, что там, где винят кривые руки проблемы как то не решаются.
Если перевести это на человеческий язык, то это высокая стоимость майнтенанса, высокая зависимость от квалифицированых разработчиков, слабые шансы вырастить замену. То есть, головняк для HR, головняк для менеджеров, головняк для владельцев.
В целом, получается совсем не так, как в других языках.
Здравствуйте, Cyberax, Вы писали:
C>VIM нынче умеет автодополнение, навигацию, рефакторинги. GDB с плугинами на Питоне тоже вполне можно использовать. Непривычно после IDE, но вполне себе эффективно.
Я, кстати, обычно gdb использовал с GUI под названием ddd.
Здравствуйте, Dair, Вы писали:
D>Я первым буду?
Да
D>Кроме того, что он сам только под macOS, как инструмент разработки C++ вполне приемлемо. D>Иногда, впрочем, они выпускают какие-то сырые версии (последней такой сырой версией была 9.0), которые часто крэшатся. Но вот сейчас у меня 10.1, она стабильна и вполне всем хороша.
Ок, спасибо за инфу.
Здравствуйте, Ikemefula, Вы писали:
I>"не можем переписать/отрефакторить" это большей частью к С++ относится.
Почему? Проблема же ортогональна языку и определяется в основном размером проекта и качеством его организации.
I>Вот это исключительно проблема языка.
Не согласен.
I>Сюда же долгий период вхождения.
Не сюда же. Это совершенно отдельная особенность, плата за прямой доступ к ресурсам.
I>Так же, в с++ сообществе принято винить кривые руки.
А где это не принято? Вон тут в соседней теме Артем плачется на кривые руки в Java.
I>Практика показывает, что там, где винят кривые руки проблемы как то не решаются.
Ну мы вообще за все хорошее и против всего плохого.
I>Если перевести это на человеческий язык, то это высокая стоимость майнтенанса, высокая зависимость от квалифицированых разработчиков, слабые шансы вырастить замену. То есть, головняк для HR, головняк для менеджеров, головняк для владельцев.
Вот с этим частично согласен. Рынок меньше и это особенность. С другой стороны у разработчиков меньше возможности уйти и ЗП очень часто меньше чем в Java (т.к. рынок меньше).
I>В целом, получается совсем не так, как в других языках.
Да все языки со своей спецификой, особо прямых конкурентов-то и нет (ну разве что C# и Java сильно пересекаются).
Здравствуйте, netch80, Вы писали:
N>А если надо позже добавить более раннюю?
Просто берём и ставим более раннюю, проблем быть не должно.
N>(а это более чем реальный и частый вариант запроса)
Довольно сложно придумать для чего это могло бы понадобиться, особенно учитывая наличие compatibility mode и возможности переключить platform toolset, когда в 2017 cтудии можно собрать с компилятором и либами от MSVS 2008.
Здравствуйте, Skorodum, Вы писали:
I>>"не можем переписать/отрефакторить" это большей частью к С++ относится. S>Почему? Проблема же ортогональна языку и определяется в основном размером проекта и качеством его организации.
А еще сложность языка, наличие и качество инструментов для статического анализа, рефакторинга и тд. Вот, скажем, для Тайпскрипта студент на коленке может налабать препроцессор для определенных нужд. А вот в С++ я такое себе представляю с большим трудом. Или это третье образование у студента, или он сначала работал лет 5, а уже потом поступил на первый курс.
I>>Сюда же долгий период вхождения. S>Не сюда же. Это совершенно отдельная особенность, плата за прямой доступ к ресурсам.
Именно сюда. Долгий вход означает вполне конкретные риски и последствия. Прямой доступ к ресурсам это то, ради чего стоит идти на эти риски и последствия.
I>>Так же, в с++ сообществе принято винить кривые руки. S>А где это не принято? Вон тут в соседней теме Артем плачется на кривые руки в Java.
В С++ это гораздо масштабнее. Новичок в С++ растет очень долго, а указатели очень хрупкие Волей-неволей появляется привычка винить новичков, потому как отсутствует четкая граница "правильно-неправильно".
I>>Если перевести это на человеческий язык, то это высокая стоимость майнтенанса, высокая зависимость от квалифицированых разработчиков, слабые шансы вырастить замену. То есть, головняк для HR, головняк для менеджеров, головняк для владельцев. S>Вот с этим частично согласен. Рынок меньше и это особенность. С другой стороны у разработчиков меньше возможности уйти и ЗП очень часто меньше чем в Java (т.к. рынок меньше).
Это компенсируется тем, что матёрого сиплюсника всегда будут рады видеть в другом стеке
I>>В целом, получается совсем не так, как в других языках. S>Да все языки со своей спецификой, особо прямых конкурентов-то и нет (ну разве что C# и Java сильно пересекаются).
Специфика есть, но вот экономика сильно не в пользу плюсов.
Здравствуйте, Ikemefula, Вы писали:
I>А еще сложность языка, наличие и качество инструментов для статического анализа, рефакторинга и тд. Вот, скажем, для Тайпскрипта студент на коленке может налабать препроцессор для определенных нужд. А вот в С++ я такое себе представляю с большим трудом. Или это третье образование у студента, или он сначала работал лет 5, а уже потом поступил на первый курс.
А зачем студенту делать что-то на C++? С какой целью?
I>Специфика есть, но вот экономика сильно не в пользу плюсов.
На каких проектах (в смысле из какой предметной области)?
Здравствуйте, so5team, Вы писали:
I>>А еще сложность языка, наличие и качество инструментов для статического анализа, рефакторинга и тд. Вот, скажем, для Тайпскрипта студент на коленке может налабать препроцессор для определенных нужд. А вот в С++ я такое себе представляю с большим трудом. Или это третье образование у студента, или он сначала работал лет 5, а уже потом поступил на первый курс.
S>А зачем студенту делать что-то на C++? С какой целью?
Что бы стать С++ разработчиком надо писать на С++. Или у вас там всё иначе устроено, типа "пишу на питоне, хопа, уже С++" ?
I>>Специфика есть, но вот экономика сильно не в пользу плюсов.
S>На каких проектах (в смысле из какой предметной области)?
Здравствуйте, Max Mustermann, Вы писали:
N>>А если надо позже добавить более раннюю?
MM>Просто берём и ставим более раннюю, проблем быть не должно.
А AlexGin утверждает, что чтобы не было проблем, надо ставить начиная с ранних.
Я-то ничего этого не пробовал, я только слушаю, что говорят.
N>>(а это более чем реальный и частый вариант запроса) MM>Довольно сложно придумать для чего это могло бы понадобиться, особенно учитывая наличие compatibility mode и возможности переключить platform toolset, когда в 2017 cтудии можно собрать с компилятором и либами от MSVS 2008.
Вот почему-то вы мне возражаете, а не автору утверждения про возможность проблем и смысл поддержания нескольких версий.
Здравствуйте, Dair, Вы писали:
I>>То есть, в обозримом будущем у XCODE ни единого шанса приблизиться к вижле нет.
D>А что умеет VS, чего не умеет Xcode? Ну, с поправкой что VS под винду, а Xcode под мак.
Да потому что она counterintuitive. Пойдёт после vim/gdb но после вижуалки вызывает недоумение как можно так всё плохо сделать имея примеры как надо делать хорошо.
I>Да потому что она counterintuitive. Пойдёт после vim/gdb но после вижуалки вызывает недоумение как можно так всё плохо сделать имея примеры как надо делать хорошо.
Ну это очень спорное утверждение. "Intuitive" оно меняется со временем. Простой пример где студия из коробки очень counterintuitive: горячие клавиши для закрытия вкладок. Это должно быть "ctrl+w" как в любом браузере, у студии какое-то другое. Или использование xml для проектов. И такого много.
Про догонят тоже спорно, т.к. например QtCreatot перешел на clang для автодополнения кода. Там вложены многие-многие челокеко-года и Студия вряди ли догонит с самописным парсером.
Здравствуйте, Ikemefula, Вы писали:
I>>> Может все ровно наоборот, это твой проект тебе видится кактусом? Соболезную. НС>>При чем тут мой проект? I>Тебя выдаёт твоя телепатия.
Здравствуйте, Ikemefula, Вы писали:
D>>А что умеет VS, чего не умеет Xcode? Ну, с поправкой что VS под винду, а Xcode под мак. I>Да потому что она counterintuitive. Пойдёт после vim/gdb но после вижуалки вызывает недоумение как можно так всё плохо сделать имея примеры как надо делать хорошо.
Это и твоё мнение тоже, или ты передразниваешь CreatorCray'я?
Я знаком (хотя и не так хорошо) с VS (C++, C#), не сказал бы что она как-то сильно удобнее Xcode или наоборот, примерно одинаково.
Здравствуйте, Dair, Вы писали:
D>>>А что умеет VS, чего не умеет Xcode? Ну, с поправкой что VS под винду, а Xcode под мак. I>>Да потому что она counterintuitive. Пойдёт после vim/gdb но после вижуалки вызывает недоумение как можно так всё плохо сделать имея примеры как надо делать хорошо.
D>Это и твоё мнение тоже, или ты передразниваешь CreatorCray'я?
Здравствуйте, CreatorCray, Вы писали:
C>>VIM нынче умеет автодополнение, навигацию, рефакторинги. GDB с плугинами на Питоне тоже вполне можно использовать. Непривычно после IDE, но вполне себе эффективно. CC>Я всё же предпочту это всё в удобном виде.
VIM вполне удобен, просто он отличается от Студии.
CC>Тут проблема в идеологии что vim что gdb
А что с ними не так?
Здравствуйте, CreatorCray, Вы писали:
C>>Ну так на билд-машину не поставили, видимо, нормальный clang. CC> Какая ещё нафиг билд машина к поведению XCode IDE?
Ну так XCode тоже строится (надеюсь?) не на laptop'ах разработчиков. И на билд-машину не поставили новый clang, так что бедные разработчики не могут включить режим разбора без учёта ifdef.
Здравствуйте, Skorodum, Вы писали:
B>>Ну тогда все еще хуже Даже в далеких 199х много раз пробовал самые разные операционки, но так и не пришел к такому — да чего там мучиться набил в виме пару экранов текста и все, что надо получил B>>Меня всегда веселит, когда какой нибудь линуксоид говорит — да в линуксе ставить программы просто и демонстрирует — набрав строчку абаракадабр S>А искходный код для вас тоже абаракадабра и программируете вы кидая формочки с помощью мышки?
Ну я ж не спорю, что все можно выучить, но зачем?
Можно готовить в современной мультиварке, а можно на костре, так зачем себя мучить то?
Можно придумать одно объяснение — заблудился в дремучем лесу и приходится
Какие еще вы можете придумать объяснения для совершения таких подвигов сегодня?
Здравствуйте, bisoft, Вы писали:
B>Можно придумать одно объяснение — заблудился в дремучем лесу и приходится B>Какие еще вы можете придумать объяснения для совершения таких подвигов сегодня?
Командная строка банально удобнее и быстрее мышекликания.
Здравствуйте, bisoft, Вы писали:
B>Ну я ж не спорю, что все можно выучить, но зачем? B>Какие еще вы можете придумать объяснения для совершения таких подвигов сегодня?
Так изучение кнопочек и менюшечек в IDE это именно об этом. GUI глючит, умирает и меняется куда чаще, чем CLI.
B>Можно готовить в современной мультиварке, а можно на костре, так зачем себя мучить то? B>Можно придумать одно объяснение — заблудился в дремучем лесу и приходится
Кривые аналогии как аргумент не засчитываются.
Здравствуйте, netch80, Вы писали:
IID>>Обратные слеши — наследие CP/M (1974), и она тогда была гоооораздо популярнее чем эти ваши юниксы.
N>CP/M не имела иерархии каталогов FS и соответственно никакого разделителя пути.
Обратные слеши в CP/M уже использовались в качестве разделителей параметров.
N>Это дерьмо с \ было введено в MS-DOS 2.0.
Из-за (парам-парам!) CP/M, чтобы не конфликтовать.
Здравствуйте, Skorodum, Вы писали:
CC>>Ещё с прошлого века это Ctrl-F4, как во всей ОС и в любом браузере под эту ОС. S>Из коробки во всех двух браузерах (FF и Chrome) ctrl-w
А еще коробки во всех двух браузерах (FF и Chrome) ctrl-F4(вот прямо сейчас проверил).
Какой из них более "изкоробочный" я х.з.
Здравствуйте, 00011011, Вы писали:
0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
Я часто скачиваю OpenSource программы и собираю, потому что хочу флаги компиляции поменять. Всегда получалось собрать.
0>Скачиваю какой-то проект, с гитхаба например. Хочу собрать. И что я вижу? 0>Вот например. 0>Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы. 0>Это не программирование на С++, а черти что. Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
Autotools'ами собирается множество различных программ, PostgreSQL например, Emacs, SDL2. Проблема у Microsoft, они не захотели сделать поддержку этих Autotools'ов в своей IDE, а вот QtCreator сделали, и там все нормально. Мне вообще они нравятся, как пользователю, у них понятный и удобный ./configure --help.
0>Я наверное что-то делаю не так. Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.). И как правило именно так и получается. Все, никакого мусора. А тут — ну я не знаю что с этим делать.
Ну так разберись, почитай зачем эти файлы, и все сразу станет ясно, ты же начал злиться и говорить ой как все непривычно... По сути там все так и есть как ты хочешь, просто сделано не так как ты бы хотел видеть.
Вообще сейчас OpenSource программки переходят на meson, вот там будет один meson.build, подmeson'ы... Но Visual Studio все равно поддерживать это не будет))
Твой проект кстати настраивать перед сборкой будет трудно, с autotools можно быстренько посмотреть аргументы и написать к примеру "./configure --build-with-gtk --disable-ipv6 CFLAGS='-march=native'", а с твоими visual code проджект файлами нужно IDE открывать тяжелую, искать всякие пунктики по менюшкам...
0>Смотрю там есть файл .pro. Вспоминаю что в Студии есть расширение для Qt, открываю через это расширение — открылось! Расширение сгенерировало solution. Пытаюсь пересборать — ошибка. Даже не компиляции, а какая-то мутная ошибка невозможности выполнить Custom Build для файла который нужно обработать программой moc. Опять фигня, не относящаяся к программированию никаким боком.
А в Visual Studio уже есть библиотеки для Qt? moc?
Здравствуйте, Max Mustermann, Вы писали:
MM>А еще коробки во всех двух браузерах (FF и Chrome) ctrl-F4(вот прямо сейчас проверил). MM>Какой из них более "изкоробочный" я х.з.
И то и то работает
Здравствуйте, Skorodum, Вы писали:
S> CC>Уууу... Опять свой устав принесён в чужой монастырь? S> Опять попытка играть в монополию, там где ее уже давно нет. S> CC>Ещё с прошлого века это Ctrl-F4, как во всей ОС и в любом браузере под эту ОС. S> Из коробки во всех двух браузерах (FF и Chrome) ctrl-w
Вот сейчас в чистом хроме нажал Ctrl-f4 — сработало.
Здравствуйте, Max Mustermann, Вы писали:
CC>>>Ещё с прошлого века это Ctrl-F4, как во всей ОС и в любом браузере под эту ОС. S>>Из коробки во всех двух браузерах (FF и Chrome) ctrl-w
MM>А еще коробки во всех двух браузерах (FF и Chrome) ctrl-F4(вот прямо сейчас проверил).
Ubuntu (18.04), Ctrl+F4 работает и в Firefox, и в Chromium.
Но не вижу повода менять привычку с Ctrl+W
А вот только что заметил, что в форме ответа в RSDN Alt+1 переопределяется на создание <code>...</code> (понимать — квадратные вместо угловых). К чему бы это?
Здравствуйте, Skorodum, Вы писали:
S>>Ctrl-F4 применялась для MDI ещё в Windows 3.1, когда авторы обоих браузеров ещё ходили в колготках. S>1. MDI != tabs.
А вот тут хотелось бы обоснования. Табы браузера это настолько соответствует классическому MDI, что я при всём желании разницы не нахожу.
S>2. Интерфейс развивается и то, что казалось удобным вчера, сегодня может быть сделано куда удобнее.
Ну тут разве что рукой тянуться быстрее (поэтому, пока работает Ctrl+W, я его использую).
S>>Ссылаться на них как на законодателей моды для IDE, это нуу.. ммм... странно. S>Нет, т.к. браузер это одно из основных приложений сегодня (где ты это сообщение читаешь?)
В браузере нет той безумно навороченной функциональности, как в IDE, и обычно нет необходимости в таком количестве шорткатов.
Здравствуйте, IID, Вы писали:
IID>>>Обратные слеши — наследие CP/M (1974), и она тогда была гоооораздо популярнее чем эти ваши юниксы. N>>CP/M не имела иерархии каталогов FS и соответственно никакого разделителя пути. IID>Обратные слеши в CP/M уже использовались в качестве разделителей параметров.
Опций, ты хотел сказать. Параметры как раз отделялись пробелами.
N>>Это дерьмо с \ было введено в MS-DOS 2.0. IID>Из-за (парам-парам!) CP/M, чтобы не конфликтовать. IID>А на юниксы всем было пофиг.
Ну тогда не удивляйся, что юниксам тоже пофиг на извращенцев
Здравствуйте, Skorodum, Вы писали:
ARK>>Это должно поддерживаться на уровне языка. S>Прекрасно, тогда это какой-то императивный язык. И системы сборки такие есть, например QBS.
Здравствуйте, netch80, Вы писали:
S>>Нет, т.к. браузер это одно из основных приложений сегодня (где ты это сообщение читаешь?)
N>В браузере нет той безумно навороченной функциональности, как в IDE, и обычно нет необходимости в таком количестве шорткатов.
Смотря кому, те же веб-дизайнеры используют его чуть ли не так же как разработчики IDE, да и веб разработчики тоже. Да и мало ли продвинутых пользователей?
Здравствуйте, bisoft, Вы писали:
B>Здравствуйте, netch80, Вы писали:
N>>Где вы нашли в командной строке какие-то "подвиги" и "мучения"?
B>Ну давайте проверим — перечислите мне все ключи команды ls не смотря подсказку.
Вот этой книге уже 30 лет в оригинале, и всё, что вы пытаетесь мне доказать этим финтом, в ней разложено по полочкам и деталям. В сети она есть, захотите — найдёте. Пересказывать ради метания бисера — не хочу.
Здравствуйте, CreatorCray, Вы писали:
I>>указатели очень хрупкие CC>Ты с С не путаешь?
Первое, что обычно ломают новички, это какой нибудь код с указателями. Даже со смартпоинтерами достаточно мест, где можно ошибиться.
Кроме того, до сих пор целая куча проектов на С++ по факту С++ & С вперемешку, со всеми вытекающими.
Здравствуйте, CreatorCray, Вы писали:
I>>А что, трудоёмкость учитывать не надо? CC>Пользователю мало того что не видно как устали те, кто это писал, так ещё и не интересно.
Ну да, лозунги выкрикивать гораздо легче. А вот законы природы никто не отменял.
I>>"Сделали хорошо" почти всегда означает — "долго думали и тщательно имплементили" MSVS вот такая потому, что в неё закопаны два десятка лет работы тысяч разработчиков, а до того это были отдельные тулы, в каждый из которых было закопано лет десять-пятнадцать сотен разработчиков. CC>Эта работа уже проделана — смотри на результат и учись.
См выше, про трудоёмкость. Для того, что бы повторить результат VS, надо инвестировать сравнимое количество труда. То есть, тысячи разработчиков помножить на 20-30 лет работы.
I>>То есть, в обозримом будущем у XCODE ни единого шанса приблизиться к вижле нет. CC>Да блин, основы уже больше 10 лет не менялись. Пусть хотя бы сделают так же.
"Так же" потребует сравнимое количество времени-ресурсов, как и у Микрософта. Законы природы никто не отменял.
Здравствуйте, netch80, Вы писали:
S>>2. Интерфейс развивается и то, что казалось удобным вчера, сегодня может быть сделано куда удобнее. N>Ну тут разве что рукой тянуться быстрее (поэтому, пока работает Ctrl+W, я его использую).
Какой вы глупый спор спорите. Давно все уважающие пользователя IDE умеют в key map.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>>2. Интерфейс развивается и то, что казалось удобным вчера, сегодня может быть сделано куда удобнее. N>>Ну тут разве что рукой тянуться быстрее (поэтому, пока работает Ctrl+W, я его использую). ·>Какой вы глупый спор спорите. Давно все уважающие пользователя IDE умеют в key map.
Дядьку, мы именно тут браузеры обсуждаем, а не IDE. А в них переопределять клавиши возможно ой не везде.
(Ну а для IDE это может быть отдельной проблемой — переназначишь 200 клавиш под себя, а в следующей версии логика изменится...)
Здравствуйте, netch80, Вы писали:
N>Дядьку, мы именно тут браузеры обсуждаем, а не IDE. А в них переопределять клавиши возможно ой не везде.
N>(Ну а для IDE это может быть отдельной проблемой — переназначишь 200 клавиш под себя, а в следующей версии логика изменится...)
Логика чего изменится? У меня уже далеко не первый год свой конфиг для R#, правда там далеко не 200 клавиш...
Здравствуйте, ·, Вы писали:
·>Какой вы глупый спор спорите. Давно все уважающие пользователя IDE умеют в key map.
Разговор был про то как оно из коробки.
Здравствуйте, Skorodum, Вы писали:
S>·>Какой вы глупый спор спорите. Давно все уважающие пользователя IDE умеют в key map. S>Разговор был про то как оно из коробки.
Тем более. Всё это дело вкуса, привычки и личных предпочтений.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>А вот про cmake можно было бы уже и подумать.
Уже подумали, VS2017, File / Open / CMake
Местами кривовато, например конфигурации неудобно переключать и build destination зарыт глубоко в дебрях %userprofile%\CMakeBuilds тем не менее обычно работает OK.
Здравствуйте, Cyberax, Вы писали:
B>>В том то и дело, что проще потыкать мышкой, чем читать 17 кб текста только по команде ls C>Мне проще текст прочитать — в нём можно делать поиск. А как мышкой найти нужный пункт? А если это надо в скрипт вставить и запустить на удалённом узле?
Ну нажал F1 и так же можно делать поиск Ну речь как раз о том, что надо использовать то, что более подходящее и проще. Так что если нужно запустить на удаленном узле, да еще и без ГУИ и ты админ, то наверное только скрипт, но если это обычный виндуз с ГУИ, то просто зашел по RDP и все сделал опять же мышкой
Здравствуйте, Skorodum, Вы писали:
S>>>>Ctrl-F4 применялась для MDI ещё в Windows 3.1, когда авторы обоих браузеров ещё ходили в колготках. S>>>1. MDI != tabs. N>>А вот тут хотелось бы обоснования. Табы браузера это настолько соответствует классическому MDI, что я при всём желании разницы не нахожу. S>Ну каноничного определения тут нет, но MDI это свободно плавающие окошки, а TDI это все же одно окно.
Хм, это где такой MDI? Я работал с MFC во времена VS 6, там было, что MDI точно так же, как сейчас табы — в основной области общего окна приложения показывается тот документ, с которым работаеш сейчас, но окно одно.
Вот чего там не было — того, как выглядит полоска табов в firefox/chrome сейчас (или даже в варианте субтабов в диалогах), кому это было нужно — пилил сам. Какие-то штатные реализации появились лет на 5 (навскидку) позже.
Много окон на приложение тоже стали появляться позже и далеко не везде (и сейчас это нетипично).
N>>В браузере нет той безумно навороченной функциональности, как в IDE S>В браузерах все на порядок круче, включая встроенную IDE.
Она сама всё-таки слабее программистских IDE — например, рефакторинг ты там не найдёшь
Отладчик, визуализатор деталей страницы, DOM и т.п.
N>>и обычно нет необходимости в таком количестве шорткатов. S>Просто ты не пользуешься, веб девелоперы пользуются.
Ну ладно, их 20 или 30 будет. В IDE уровня VS на пол-порядка больше.
Здравствуйте, netch80, Вы писали:
S>>>Ctrl-F4 применялась для MDI ещё в Windows 3.1, когда авторы обоих браузеров ещё ходили в колготках. S>>1. MDI != tabs. N>А вот тут хотелось бы обоснования. Табы браузера это настолько соответствует классическому MDI, что я при всём желании разницы не нахожу.
Более того, раньше во многих программах, включая студию, можно было в настройках переключать Dock/MDI
Здравствуйте, Слава, Вы писали:
S>>Нет. ls -al работает для меня последние 16 лет без всяких изменений, а вот настройки сетевой карты в винде поменялись уже много раз. С>В виндах ещё и netsh имеется, неизменный. А вот в альтернативных системах GUI как не было, так и нет.
NetworkManager существует уже как 15 лет. У него есть графический интерфейс, текстовые файлы настройки, CLI-интерфейс и TUI-интерфейс. Я обычно просто правлю конфиги напрямую.
Здравствуйте, Skorodum, Вы писали:
0>>Это не программирование на С++, а черти что. S>Это реальное программирование на С++. Welcome to the real world
Может быть, поэтому в плюсовые конторы требования и собеседования такие странные. Когда я был плюсником, с таким ужасом не сталкивался (давно это было). А ещё на плюсы кто-то пытался написать свой мавен с блекджеком. Может быть, оно и оправдано- содом написания pom-ка компенсируется удобством «нажал кнопку- всё что надо зависимости подтянуло, тесты прогнало и собрало».
Здравствуйте, Max Mustermann, Вы писали:
N>>(а это более чем реальный и частый вариант запроса) MM>Довольно сложно придумать для чего это могло бы понадобиться, особенно учитывая наличие compatibility mode и возможности переключить platform toolset, когда в 2017 cтудии можно собрать с компилятором и либами от MSVS 2008.
Чтобы переключить тулсет, этот тулсет должен быть установлен. Для тулсетов до VS2015 (vc140) нужно ставить полноценную студию той самой версии с которой тулсет связан.
Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
