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

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

Этих индустриальных стандартов столько, что шанс встретить опенсорс на autotools — как попугая увидать. Т.е. можно, но надо спецом идти в зоопарк.

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

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

Попробуйте собрать OpenSSL. Под Винду. В режиме совместимости с Visual Studio. Через полгода попробуйте снова, на другой машине. После этого придёт осознание что всё — тлен

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

M>Например, Qt строго формально вообще не на C++ написана. Используются некоторые расширения, которых нет в языке, а компилируется компилятором C++ только после того как специальный препроцессор (qmake) развернет их.
MOC (meta-object compiler), qmake это система сборки а-ля CMake.

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

0>Мне нужно именно под студию собрать, чтобы поразбираться в коде, в отладчике походить и т.д.
Так проблема в твоей зависимости от студии и подходе МС "мы такие крутые монополисты будем вводить свои собственные стандарты и решения". Но даже МС уже исправляются и двигаются навстречу прогессу: перешли на гит, вводят поддержку CMake.
Ну и поддержка кроссплатформенной сборки и разработки это почти всегда боль разной степени

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

D>cmake умеет в качестве выхода выдавать студийный проект.
Только у него на входе не CMake, а qmake. Был не прав, не заметел CMakeLists.txt

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

0>Это не программирование на С++, а черти что.
Это реальное программирование на С++. Welcome to the real world

0>Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
Судя по списку файлов в первом случае авторы поддреживают две системы сборки: CMake и qmake. Если обе для вас "самопальные утилиты", то это значит, что вы работали в очень тепличных условиях

0>Я наверное что-то делаю не так.
Ну да, вы делаете что-то не так. Все эти файлы уже более-менее стандарт для проектов.

0>Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.).
Для "HelloWorld" и студенческой курсовой пойдет

0>И как правило именно так и получается.
Это просто говорит чем и в каких условиях вы занимаетесь. Ингода этого достаточно, но в большинстве случаев — нет.

0>Ну хорошо, я терпеть это не могу, но я знаю про cmake. Программисты любят костыли и придумывают новые для обхода старых.
0>....
0>Зачем мне с этим разбираться?
CMake ужасен, но это уже почти стандарт

0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом.
JSONCompilationDatabase

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

0>Почему? Это вообще не затрагивает сам язык. Это просто обяжет всех разработчиков компиляторов и сред разработки следовать единой объектной модели проекта.
0>А то ведь кто во что горазд, в той же студии от версии к версии формат меняется!

Кого ты там обязывать собрался? И чем? Многие компиляторы вообще — консольные утилиты, которому ты просто указываешь имя файла с исходником, а он тебе объектный файл выдаёт. Вот так просто, и ничего больше.
Все эти проекты — навороты IDE. Куча народа только make файлами пользуются.

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

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

AB>Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make.

Нет. Не собираются.

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

0>>Это не программирование на С++, а черти что.
S>Это реальное программирование на С++. Welcome to the real world
Потому C++ под никсами всегда был болью.
Особенно после полноценной VS.

S>Судя по списку файлов в первом случае авторы поддреживают две системы сборки: CMake и qmake. Если обе для вас "самопальные утилиты", то это значит, что вы работали в очень тепличных условиях
Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке.
Вот только непонятно почему маршрутчики считают что это нормально и все должны страдать как они?

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

CC>Потому C++ под никсами всегда был болью.
Боль — это поддерживать сложную сборку под несколько ОС, компиляторов и IDE, но это задача реального мира и за нее хорошо платят
Чисто разработка не особо отличатся между платформами. За небольшими отличиями все более-менее одинаково. (В Студии отладчик хороший, но редактор и автодополнение — похуже, чем, например, в Креаторе, но это все не особо принципиально.)

CC>Особенно после полноценной VS.
В реальном мире МС переходит на линуховые тулзы, а не наоборот (CMake, git)

CC>Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке.
Студийные XML-солюшены это что угодно, но не "комфортная машина". Банально изменения в файле проекта не удобно смотреть.

CC>Вот только непонятно почему маршрутчики считают что это нормально и все должны страдать как они?
А не надо путать в кучу личные привычки и универсальное удобство
Если вам нужна разработка только под МС — так сидите на студийных солюшенах приковынные цепью к одной IDE
За возможность сборки на разных платформах/компиляторах/IDE приходиться платить.

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

CC>>Особенно после полноценной VS.
S>В реальном мире МС переходит на линуховые тулзы, а не наоборот (CMake, git)
Хипстерство страшное дело. Гит вылез на поддержке веток, но юзабилити у него кошмарный.

CC>>Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке.
S>Студийные XML-солюшены это что угодно, но не "комфортная машина". Банально изменения в файле проекта не удобно смотреть.
Да как то не возникало каких либо проблем посмотреть на diff со старыми vcproj
Есессно diff был типа BC или Araxis, а не консольное угробище

S>А не надо путать в кучу личные привычки и универсальное удобство
Универсальным может быть только неудобство.
И к этому универсальному говну всё постепенно сползает.

S>За возможность сборки на разных платформах/компиляторах/IDE приходиться платить.
...кровью

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

MD>Попробуйте собрать OpenSSL. Под Винду. В режиме совместимости с Visual Studio.

Ну я собирал.
Активно используются макросы для построения имён, в итоге по имени из ошибки ничего не находится. Т.к. это имя — составное.
Самая жесть — сплошь и рядом куски исходников (не хидеров!) инклудятся в другие исходники.
Причём один и тот же включается по нескольку раз. С переопределением макросов между инклудами, меняющих включаемое содержимое.
Такая себе кодогенерация.

MD>Через полгода попробуйте снова, на другой машине. После этого придёт осознание что всё — тлен

Один раз пройдя по щедро разложенным граблям уже перестанешь удивляться, и легко справишься.

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

F>это стандартный софт. и тебе стоило бы о нём знать.
F>дык заплати — будет тебе сборщик.

Это говно, а не софт. Поделие от гоблинов для морлоков.
За это не платить надо, а палкой бить за изобретуцию с порнотехноложеством. Деньги тут не помогут.

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

IID>Активно используются макросы для построения имён, в итоге по имени из ошибки ничего не находится. Т.к. это имя — составное.

Это да — тоже долго искал один кусок где он объявлен. Оказалось — макрос-based

IID>Один раз пройдя по щедро разложенным граблям уже перестанешь удивляться, и легко справишься.

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

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

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

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

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

F>>это стандартный софт. и тебе стоило бы о нём знать.
F>>дык заплати — будет тебе сборщик.
С>Это говно, а не софт. Поделие от гоблинов для морлоков.
С>За это не платить надо, а палкой бить за изобретуцию с порнотехноложеством. Деньги тут не помогут.

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

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

ARK>Считаю, что выделенный файл проекта вообще не нужен. Вся сборка должна описываться на самом языке программирования.
Так?

gcc build_the_project.cpp && ./a.out

Императивные языки для этого не особо подходят.

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

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

ARK>>Считаю, что выделенный файл проекта вообще не нужен. Вся сборка должна описываться на самом языке программирования.
S>Так?
S>

S>gcc build_the_project.cpp && ./a.out
S>

Я бы сказал даже так:

gcc build_the_project.cpp

S>Императивные языки для этого не особо подходят.

Почему?

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

ARK>Я бы сказал даже так:
ARK>

ARK>gcc build_the_project.cpp
ARK>

Так не получиться: нужна какая-то опция компилятору, говорящая, что этот файл особый и нужно запустить бинарь после сборки.

S>>Императивные языки для этого не особо подходят.
ARK>Почему?
Например потому что придется ручками разрешать порядок сборки на основе зависимостей между проектами. Куда проще писать "A needs B needs C" и оставить на откуп системы сборки разрешение порядка.