Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило 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-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Здравствуйте, 00011011, Вы писали:
0>Что я хочу сказать? 0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом.
Было бы хорошо, но это будет не C++.
0> Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Что делать, если для одного проекта используется несколько языков?
Но вообще самого дико раздражает, что куча проектов собирается только в какой-то вымудренной конфигурации на компе авторов и в произвольном случае надо еще пердолиться, настраивая систему под них.
Здравствуйте, Michael7, Вы писали:
M>Было бы хорошо, но это будет не C++.
Почему? Это вообще не затрагивает сам язык. Это просто обяжет всех разработчиков компиляторов и сред разработки следовать единой объектной модели проекта.
А то ведь кто во что горазд, в той же студии от версии к версии формат меняется!
M>Что делать, если для одного проекта используется несколько языков?
Это как? Результатом является или исполняемый модуль, или библиотека. Если проект использует библиотеку, написанную на другом языке — то значит там внутри должна быть секция "зависимости", в ней "проекты, собираемые другими инструментами" и внутри массив этих внешних проектов (или массив пар ключ-значение: проект — инструмент).
Здравствуйте, Amygdala, Вы писали:
A>Платные проекты, что я покуппал с исходниками, так вот идеально как ты пишешь и выглядят. Нажал на одну кнопкуи все скомпилилось.
Бесплатные такие тоже есть. Я видел платные очень энтерпрайзные проекты такие, что это вообще кошмар сборщика. Например, часть файлов надо собрать в одной версии Delphi, часть в другой, потом кое-что из результата пропатчить в 16-ричном редакторе и продолжить сборку в еще одной версии Delphi. И все эти манипуляции толком не описаны, являются чуть ли не сакральным знанием.
Здравствуйте, 00011011, Вы писали:
0>Почему? Это вообще не затрагивает сам язык. Это просто обяжет всех разработчиков компиляторов и сред разработки следовать единой объектной модели проекта.
Дело в том, что еще с языка Си нет никакой модели проекта вообще, вернее модель одна, она сводится к компиляции одного большого файла, который получается после всех препроцессоров. Только недавно стали пытаться добавить на уровне языка модули. Линковщик так выходит, что за рамками стандарта (не считая некоторых директив). Это с одной стороны дает очень большую гибкость, с другой приводит к таким вот неприятностям.
M>>Что делать, если для одного проекта используется несколько языков?
0>Это как? Результатом является или исполняемый модуль, или библиотека. Если проект использует библиотеку, написанную на другом языке — то значит там внутри должна быть секция "зависимости", в ней "проекты, собираемые другими инструментами" и внутри массив этих внешних проектов (или массив пар ключ-значение: проект — инструмент).
Просто по определению не выйдет стандартизировать поведение сборщиков других языков. Но на самом деле все еще интереснее. Например, Qt строго формально вообще не на C++ написана. Используются некоторые расширения, которых нет в языке, а компилируется компилятором C++ только после того как специальный препроцессор (qmake) развернет их. И вот как это со стандартом совместить? Не говоря о том, что заставить комитет никого не может, следование стандарту в общем-то добровольное.
Здравствуйте, 00011011, Вы писали:
0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
Да нет, просто у тебя вместо языка здорового человека язык курильщика, велосипедостроение возведенное в сотую степень.
Здравствуйте, 00011011, Вы писали:
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да нет, просто у тебя вместо языка здорового человека язык курильщика, велосипедостроение возведенное в сотую степень.
Плохому девелоперу язык мешает?
Здравствуйте, CreatorCray, Вы писали:
НС>>Да нет, просто у тебя вместо языка здорового человека язык курильщика, велосипедостроение возведенное в сотую степень. CC>Плохому девелоперу язык мешает?
Читай README.rst, там все написано 0>Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты
Да, читать документацию — это сложно.
Как много веселых ребят, и все делают велосипед...
В современных языках обычно так. В С++ вроде cmake стандарт де-факто, ну autotools это ещё юниксовое наследие. А что, старый добрый ./configure && make не срабатывает?
Здравствуйте, vsb, Вы писали:
vsb>В современных языках обычно так. В С++ вроде cmake стандарт де-факто, ну autotools это ещё юниксовое наследие. А что, старый добрый ./configure && make не срабатывает?
Мне нужно именно под студию собрать, чтобы поразбираться в коде, в отладчике походить и т.д.
Просто ради сборки я бы и заморачиваться не стал бы, скачал бы готовый бинарник и пользовался бы
M>>Что делать, если для одного проекта используется несколько языков? 0>Это как? Результатом является или исполняемый модуль, или библиотека.
Результатом является приложение, с конфигами, всеми файлами, вощем все что требуется для инсталляции. "исполняемый модуль, или библиотека" это лишь два вырожденных случая.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 00011011, Вы писали:
vsb>>В современных языках обычно так. В С++ вроде cmake стандарт де-факто, ну autotools это ещё юниксовое наследие. А что, старый добрый ./configure && make не срабатывает?
0>Мне нужно именно под студию собрать, чтобы поразбираться в коде, в отладчике походить и т.д. 0>Просто ради сборки я бы и заморачиваться не стал бы, скачал бы готовый бинарник и пользовался бы
Ну это уже вопросы к студии, почему она не поддерживает индустриальный стандарт autotools. Если человек писал проект в линуксе используя vim, как от него можно требовать поддержки студии.
А что, в студии нельзя прицепиться к работающей программе? Т.е. просто создать новый проект, накидать туда все эти файлы исходников, чтобы студия про них знала, собрать бинарник извне с отладочной информацией и подцепиться.
Здравствуйте, 00011011, Вы писали:
0>Это не программирование на С++, а черти что. Нужно знать кучу каких-то самопальных утилит, которые были применены авторами для каких-то целей.
это стандартный софт. и тебе стоило бы о нём знать.
0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Здравствуйте, 00011011, Вы писали:
0> Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make.
Здравствуйте, 00011011, Вы писали:
0>Зачем мне с этим разбираться?
Чтобы использовать эту библиотеку?
0>Смотрю там есть файл .pro. Вспоминаю что в Студии есть расширение для Qt, открываю через это расширение — открылось! Расширение сгенерировало solution. Пытаюсь пересборать — ошибка. Даже не компиляции, а какая-то мутная ошибка невозможности выполнить Custom Build для файла который нужно обработать программой moc. Опять фигня, не относящаяся к программированию никаким боком.
Согласен, но чтобы использовать Qt проекты нужно хотябы в базе знать как работает Qt сборка
0>В итоге я плюну на все это, и как делал уже не раз — заведу пустой проект в Студии, добавлю туда чистые исходники из скачанного проекта и получу нужный результат. Возможно не сразу, но получу. Для простых проектов обычно сразу получается, для больших и сложных — через несколько итераций.
Qt проект не соберется 0>Потому что чистые исходники на С/С++, написанные нормальным образом, как правило компилируются. Иногда приходится подправить какие-то мелочи, добавлять библиотеки которых у меня нет — но по крайней мере это все понятно, компилятор ругнется например на "нет такого-то инклуда" и я полезу его искать, найду и в итоге добавлю новую библиотеку в каталог с библиотеками.
0>Что я хочу сказать? 0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом. Он должен быть единый и достаточный для того, чтобы загрузить проект в любую среду разработки и собрать любым компилятором путем выполнения одной единственной команды. И все вопросы внешних зависимостей должны также решаться компилятором и быть учтены в этом формате.
Возможно с появлением модулем мы будем двигаться в этом направлении, да и сейчас уже студия cmake понимает, так же из cmake можно сгенерировать проект для студии, с абсолютными путями, но доработав напильником можно жить.
Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.
