Это типичный бред который может придти только в больной мозг виндузятников. Ну да, ведь это невероятно увлекательно помнить что и куда ты распаковал что бы потом не забыть это нечто обновлять, а уж коли захочешь удалить то лизаить по машине и смореть что там и где валяется
Здравствуйте, kaa.python, Вы писали:
KP>Это типичный бред который может придти только в больной мозг виндузятников. Ну да, ведь это невероятно увлекательно помнить что и куда ты распаковал что бы потом не забыть это нечто обновлять, а уж коли захочешь удалить то лизаить по машине и смореть что там и где валяется
Здравствуйте, Artem Korneev, Вы писали:
AK>Ну так наверное потому и присылают, что:
Не поэтому. Я резюме лет 5 не обновлял, у рекрутеров резюме совсем без экзотики.
Здравствуйте, CreatorCray, Вы писали:
CC>У меня либо вижуалка либо xcode, так что всё там
Т.е. у тебя проект можно собрать только с одной кошерной IDE?
Здравствуйте, kaa.python, Вы писали:
KP>Ну а вообще если человек знает что такое CMake и Conan, то настройка проекта с практически любым набором библиотек делается за 3-5 минут.
Проблема в том, что CMake толком не знает практически никто, т.к. это такие знания, которые нужны раз в полгода, а убогий синтаксис CMake и нелогичность крайне способствуют тому, что мозг старается выкинуть остатки знаний как можно скорее. В итоге в большистве случаев когда возникает задача типа "как же мне наследовать параметры компиляции" используется первое найденое на SO решение, которое обычно устаревшее и кривое.
CMake лучше чем ничего и задачу любую решить может, но это боль и уродство. Я бы променял все фичи С++14/17/21 на нормальную стандартную систему сборки.
Здравствуйте, Skorodum, Вы писали:
S>Т.е. у тебя проект можно собрать только с одной кошерной IDE?
Часто можно и без IDE, достаточно компилятора с утилитами и SDK с библиотеками.
Ну и никто не запрещает IDE экспортировать проект в тот же CMake-овский файл, или что там сейчас модно
Или еще проще — а что ему (или мне) помешает и далее пользоваться той кошерной IDE
Здравствуйте, Skorodum, Вы писали:
S>CMake лучше чем ничего и задачу любую решить может, но это боль и уродство. Я бы променял все фичи С++14/17/21 на нормальную стандартную систему сборки.
Да я как бы на 100% согласен что CMake — это кривое говно. Только проблема в том, что это кривое говно лучшее что есть в мире C++ для сборки на сегодня
Здравствуйте, kaa.python, Вы писали:
KP>Да я как бы на 100% согласен что CMake — это кривое говно. Только проблема в том, что это кривое говно лучшее что есть в мире C++ для сборки на сегодня
qbs лучше, но не взлетел. build2 говорят не плохой, но тоже вряд ли уже взлетит.
Здравствуйте, Skorodum, Вы писали:
S>qbs лучше, но не взлетел. build2 говорят не плохой, но тоже вряд ли уже взлетит.
Еще есть https://bazel.build. Сам пока с ним не работал, но восторги слышал. Правда что build2, что qbs, что bazel не поддерживаются нормально IDE... и сразу "Привет Vim!". Не то что бы я не люблю Vim, но современный CLion всё же удобнее.
Здравствуйте, pagid, Вы писали:
P>Часто можно и без IDE, достаточно компилятора с утилитами и SDK с библиотеками.
Можно. Следующий шаг использовать кросслатформенные (почти стандартные) утилиты а-ля CMake. Ч. и Т.Д.
P>Ну и никто не запрещает IDE экспортировать проект в тот же CMake-овский файл, или что там сейчас модно
Религия мешает:
1. Это нарушение DRY
2. Ненужный шаг: сборка получается 3-х ступенчатой, соответсвенно вероятность и сложность проблем растет.
3. Любой проект на CMake выглядит ужасно, экспортированный будет ужас-ужас-ужас.
P>Или еще проще — а что ему (или мне) помешает и далее пользоваться той кошерной IDE
Ничего. Только это не гибко и не стандартно со всеми вытекающими последствиями.
В случае Студийных солюшенов еще добавляется неудобоство просмотра изменений. Даже самый плохой CMakelists.txt лучше сгенеренного машиной XML.
Что там XCode к счастью не знаю.
Здравствуйте, Skorodum, Вы писали:
S>Можно. Следующий шаг использовать кросслатформенные (почти стандартные) утилиты а-ля CMake. Ч. и Т.Д.
Цель этого шага?
S>2. Ненужный шаг: сборка получается 3-х ступенчатой, соответсвенно вероятность и сложность проблем растет. S>3. Любой проект на CMake выглядит ужасно, экспортированный будет ужас-ужас-ужас.
Так он обычно и ненужный, но если уж очень хочется...
S>Ничего. Только это не гибко и не стандартно со всеми вытекающими последствиями.
Гибкость она нужна только когда нужна, иначе это не гибкость, а избыточное усложнение. А насчет стандарта, то наверно стоит название этого стандарта узнать и организацию его принявшую, затем можно пообсуждать пользу от его использования.
Здравствуйте, kaa.python, Вы писали:
KP>Еще есть https://bazel.build. Сам пока с ним не работал, но восторги слышал. Правда что build2, что qbs, что bazel не поддерживаются нормально IDE... и сразу "Привет Vim!".
QtCreator поддерживает qbs
KP>Не то что бы я не люблю Vim, но современный CLion всё же удобнее.
Вроде сейчас все системы сборки и IDE движутся в сторону [url=https://www.jetbrains.com/help/clion/compilation-database.html], так что скоро наступит светлое совместимое будущее.
Здравствуйте, pagid, Вы писали:
P>Цель этого шага?
Поддержка разработки на любой платформе
P>Так он обычно и ненужный, но если уж очень хочется...
"Обычно" это если мир ограничен разработкой на одной платформе, под одну платформу и одним компилятором. В таком мире можно и С++ не пользоваться очень часто.
P>Гибкость она нужна только когда нужна, иначе это не гибкость, а избыточное усложнение.
А я соглсен. Только вот в С++ мире эта гибкость чаще нужна, чем не нужна.
P>А насчет стандарта, то наверно стоит название этого стандарта узнать и организацию его принявшую, затем можно пообсуждать пользу от его использования.
Тут разговор про то, что более стандартно (распространенно). CMake более стандартент чем солюшены.
Здравствуйте, Skorodum, Вы писали:
CC>>У меня либо вижуалка либо xcode, так что всё там S>Т.е. у тебя проект можно собрать только с одной кошерной IDE?
Собрать то можно чем угодно, а вот разработка в IDE на порядки удобнее.
Тот же xcodebuild коммандлайновый но проект понимает ничуть не хуже.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
S>Следующий шаг использовать кросслатформенные (почти стандартные) утилиты а-ля CMake. Ч. и Т.Д.
Нафига?
P>>Или еще проще — а что ему (или мне) помешает и далее пользоваться той кошерной IDE S>Ничего. Только это не гибко и не стандартно со всеми вытекающими последствиями.
А нахрена все эти навороты в зоопарке? KISS никто не отменял.
S>В случае Студийных солюшенов еще добавляется неудобоство просмотра изменений.
В новой студии стало хуже, в старой прекрасно было видно что поменялось, просто потому что XML там был человекочитаемый.
S>Что там XCode к счастью не знаю.
Там всё совсем плохо в плане понять чтож оно поменяло то.
Да и в принципе даже старая вижуалка с ассистом кроет новый хэкод как бык овцу практически во всём касательно продуманности и удобства.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Skorodum, Вы писали:
P>>Цель этого шага? S>Поддержка разработки на любой платформе
А нахрена?
S>"Обычно" это если мир ограничен разработкой на одной платформе
Что в большинстве случаев так.
S> под одну платформу и одним компилятором. В таком мире можно и С++ не пользоваться очень часто.
В таком мире как раз С++ приносит одно удовольствие
P>>Гибкость она нужна только когда нужна, иначе это не гибкость, а избыточное усложнение. S>А я соглсен. Только вот в С++ мире эта гибкость чаще нужна, чем не нужна.
Да вот как то нет.
Пишется продукт, у продукта есть требования, в том числе по платформе. Просто так на многоплатформу писать — пустая трата Вилли стоя в гамаке на лыжах.
S>Тут разговор про то, что более стандартно (распространенно).
Unknown definition
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Поддержка разработки на любой платформе CC>А нахрена?
Чтобы не делать несколько конфигураций. Кажется, что затачиваться под одну платформу чуть ли не сложнее, чем под несколько. Даже когда у меня была разработка windows only, я с радостью перешёл на CMake. А потом стало ещё проще: внезапно кто-то говорит: "А давай запустим проект на nvidia jetson!" И требуется минимум работы, чтобы CMake адаптировать под это дело.
Здравствуйте, varenikAA, Вы писали:
AA>Вчера в докладе на дотнексте промелькнула ссылка https://www.blazorfluentui.net/ ФМ от микрософта на их же технологии! AA>Жуть просто. AA>И все упирается в язык которой может прекрасен, но реализация прибита к VM NET и похоже лучше не будет с производительностью.
