Здравствуйте, CreatorCray, Вы писали:

CC>ДА!

CC>ДА!!!
Now kiss!!!!

Здравствуйте, Skorodum, Вы писали:

S>Now kiss!!!!

Здравствуйте, jamesq, Вы писали:

J>Формат меняется, потому что MS хочет от тебя бабла.

От меня — не хочет. Community Edition бесплатна.

И от мелких контор не хочет (до 5 пользователей).
И от пишущих опенсорс не хочет.


J>Когда, если ты собираешься внедрить новую студию в конторе, ты обязан купить её всю сразу на все компьютеры программистов, что у тебя есть.

Что, правда ? Даже если программист не использует студию ?

Ну и если для большой конторы 500 баксов на программиста это ппц какие деньги — сомневаюсь что условия работы будут хорошими.

J>Иначе вы там конфликты будете получать.

Те, кто остался без студии, пойдут бить остальных ?

Здравствуйте, 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 на тот момент был редкостью и кажущимся излишеством.

Здравствуйте, vsb, Вы писали:

vsb>Ну это уже вопросы к студии, почему она не поддерживает индустриальный стандарт autotools.

Какой еще нафиг стандарт? Древние артефакты да замшелое легаси. Стандарт — это когда в новых проектах использует заметное количество людей.

Здравствуйте, 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"?

Здравствуйте, Igore, Вы писали:

I>Согласен, но чтобы использовать Qt проекты нужно хотябы в базе знать как работает Qt сборка

Ты так говоришь, как будто это что-то хорошее. Все эти Qt-шные препроцессоры — это ж говно полное, и обман людей рассказами про плюсы. Только сумрачный красноглазый гений мог такое родить.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Не-а
MD>Например, если удосужишься поставить себе другой Perl к тому времени (что со всякими Go/Chocolatier — раз плюнуть, даже не заметишь, пекетный менеджер сделает всё за тебя). Потому что надо строго ActivePerl, иначе велкам в исходники патчить один хитрый regexp, который интерпретируется по-разному, и ломает билд неожиданным переводом строки.

Открой для себя choco pin

Здравствуйте, Ops, Вы писали:

Ops>Стандарт — это когда в новых проектах использует заметное количество людей.

По своему желанию использует, хочу заметить.

А не так как в буханке, где горчица под хвостом у кощки считается за "добровольно и с песней".

Здравствуйте, Ops, Вы писали:

Ops> BFE>> AB>Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make.
Ops> BFE>> Нет. Не собираются.
Ops> AB>Скорее всего, ты просто чего-то не умеешь / не знаешь.
Ops> Чего надо знать при "стандартных configure && make"?

Обычно ничего, но вот у ТС-а какие-то проблемы с этим и я почти уверен, что там тривиальная мелочь.

Здравствуйте, Ops, Вы писали:

Ops>Открой для себя choco pin

А что это даст? Тот "правильный перл" уже поставлен, причём БЕЗ помощи choco. Соответственно, тот про него не в курсе.

Здравствуйте, Dair, Вы писали:

D>А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому.

Обычно прямые слэши проблем не вызывают:

C:\Users\Home>cd c:/windows/system32/drivers/etc/

c:\Windows\System32\drivers\etc>cd ../../

c:\Windows\System32>

Здравствуйте, 00011011, Вы писали:

0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.



0>Скачиваю какой-то проект, с гитхаба например. Хочу собрать. И что я вижу?
0>Вот например.
0>Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.
новую библиотеку в каталог с библиотеками.

0>Что я хочу сказать?
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.

Ну вообще-то не стандарт де-юре, но более менее аналог,
который используется большинством есть,
и современному программисту C++ волей неволей приходится с ним разбираться.
Вы его собственно и увидели. Раньше cmake использовали для генерации проекта для IDE.
Теперь большинство современных IDE умеют работать с CMakeLists.txt напрямую,
например

https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio/

Здравствуйте, Слава, Вы писали:

С>Кстати, расскажите мне, если вы знаете, каким образом собирается ms exchange
С помощью аццкой системы постройки, которая состоит из кучи серверов, магических расшареных папок и требует соединения с MSSQL во время строительства.

CMake сложно собирать? ХАхахахахха.

Здравствуйте, 00011011, Вы писали:

0>Это не программирование на С++, а черти что. Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
Как видим, тут достаточно знать CMake. Остальные системы сборки можно игнорировать.

0>Я наверное что-то делаю не так. Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.). И как правило именно так и получается. Все, никакого мусора. А тут — ну я не знаю что с этим делать.
Это подходит только для простеньких проектов — ну там курсовых работ, CD-ejector'ов и т.п.

В реальности мир сложнее. Например, если мы посмотрим на qBittorrent, то там поддерживаются три опции времени компиляции: COUNTRIES_RESOLUTION, STACKTRACE и WEBUI (см.: https://github.com/qbittorrent/qBittorrent/blob/master/CMakeLists.txt ).

В MSVS поддержка всех комбинаций потребует 16 вариантов сборки (Debug/Release * 8 комбинаций). И это только в одной библиотеке!

Следующий вопрос — это зависимости. В MSVS обычно просто фигачат всё в подкаталог, часто в виде бинарных файлов. Надо объяснять чем это плохо?

Здравствуйте, Skorodum, Вы писали:

S>Почему имено мир, породивший оный гит оказался столь успешен
А где можно посмотреть на этот успех?

Здравствуйте, Dair, Вы писали:

D>У виндовз-программистов какое-то извращённое Микрософтом представление о мире. Да, Микрософт сделал довольно неплохую VS под себя. Но подходить к ней надо как к инструменту Микрософт для Микрософт, вещь в себе.
Ну почему? Я например писал в студии код для BSD kernel — удобство было на голову выше чем у коллег, которые мудохались вприсядку кто с чем.

D>на момент создания VS (1997) уже были GNU Make (1976) и даже autotools (1996).
Ну так студия продолжила развитие а это говно мамонта так и осталось на уровне 78го и 96го.

D>Это ты приучен к левой дюймовой резьбе, поэтому правая метрическая тебя вгоняет в тоску.
Я привык к отсутствию геморроя и необходимости превозмогать на пустом месте.

Здравствуйте, Dair, Вы писали:

D>>>уже были GNU Make (1976)
IID>>говно мамонта, которое за >40 лет так и не научилось поддерживать пробелы в makefile
D>Ну, это, конечно, серьёзная проблема
Это отличная демонстрация подхода "а нам насрать что криво, как то шевелится и хрен с ним"

D>Но тезис коллеги CreatorCray'а был в том что "C++ под Unix плохо после полноценной VS". Я указал на то, что C++ под Unix был до, а иногда и задолго до MSVS.
Да насрать что там когда было. Вон, похожие идеи в телефонах были и до iPhone, но сделали всё удобно именно в Apple.
Так и с С++ — вижуалка сделала программирование удобным, а в nix продолжают пользоваться палками-копалками.

Здравствуйте, CreatorCray, Вы писали:

CC>Я привык к отсутствию геморроя и необходимости превозмогать на пустом месте.

Это что сейчас было? Это такой толстый троллинг что-ли?


Как мне добиться отсутствия геморроя при практически любом мерже .sln и .vcxproj файлов? Как мне без нереального превозмогания понять по change'у в несколько сотен ( а часто и тысяч ) строк что вообще изменилось в системе сборки проектов? Почему порой даже небольшие изменения в проектах выливаются в гигантские change'и? Уже даже одно это — просто showstopper, что уж там говорить о массе других не менее серьезных проблем.


Да, как IDE студия была и сейчас остается вне конкуренции, но MSBuild как система сборки годиться только для проектов уровня laba2