LINUX.ORG.RU

hpp vs cpp

 ,


0

2

Привет! Вот вброс. какие есть за и против писать все в заголовочных файлах, с шаблонами и без, и писать, использую *.cpp файлы. (ну я хочу поднять эту тему у себя, вот готовлюсь.)

если это тут возможно, изменю это сообщение и добавлю, ответы. пока что так

hpp подход

  • + ускоряет компиляцию
  • + дает возможность компилятору проверять код
  • + не нужна система сборки

cpp подход

  • - замедляет сборку
  • - обязывает иметь систему сборки, если проект не тривиален
  • - пряет определения функций от компилятора, что выключает полезные варнинги и оптимизаии

Ответ на: комментарий от ox55ff

не )) ну cmake тоже писать надо. так просто пишешь g++ main.cpp и все (ну понятно что могут быть внешние либы например, инклюды, которые так просто не найти, так что можно просто скриптик).

zerhud
() автор топика
Ответ на: комментарий от zerhud

Ну и как ты думешь, на чем проще будет написать проект с использованием 4-8 thirdparty библиотек, на твоем скриптике или на cmake? А если ты отложишь проект и вернешься через год, вот удовольствие будет разбираться со скриптом…

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от zerhud

так что можно просто скриптик

Который сразу привяжет проект к ОС, прощай, кроссплатформенность.

В целом, аргумент о ненужности системы сборки работает, если твой проект использует исключительно header-only библиотеки, если нет — вся стройность разваливается.

Плюс замедление сборки.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

исключительно header-only библиотеки

ну я об этом. хотя можно написать -lmy_cool_library и это будет работать в большинстве случаев (то есть это уже трабла окружения, но и с системой сборки все точно также).

привяжет проект к ОС

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

zerhud
() автор топика
Ответ на: комментарий от hobbit

так что можно просто скриптик

Который сразу привяжет проект к ОС, прощай, кроссплатформенность.

Не, не привяжет :) просто добавится шагов «реквайрементс». Более того, модные потуги убить цмейк тащат с собой разнообразный бред типа пыхтона (потому что пионеры из фаангуглов поголовно страдают NIH синдромом и шатания от gyp к scons ехал градле через градле и далее в meson для сборки плюсовых программ и так добавляют разнообразного ненужно).

А башик уже можно везде запустить.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

А башик уже можно везде запустить.

Мда. И в винду тянуть? Отлично. Конечно это лучше cmake.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

Какая тебе разница что тянуть? :) цмейк же тоже не часть винды. А так хоть скрипты писать единообразно без заклинаний на раковине повара и страданий в недошелле cmd.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от zerhud
g++ main.cpp $main_flags -o project

Всё писать в один main.cpp не выйдет.

Получишь: sorry, unsupported: file is too large for Clang to process или просто g++ крашнется…

fsb4000 ★★★★★
()
Ответ на: комментарий от rumgot

Не для всего он подходит (или у тебя шелл на цмейке где-то есть? :)), а если в проекте и так что-то собирается не цмейком (какой-нибудь v8 или буст) — баш это вообще не проблема, одной зависимостью больше, одной меньше. И цмейк никто не мешает пользоваться. Тут нет противоречия.

slackwarrior ★★★★★
()
Ответ на: комментарий от rumgot

Можно. А иногда его собрать надо. Весь. И там цмейка нет :) а есть их бустовый велосипед . Который можно дергать из цмейка... а можно их обоих из баша, который просто клей в пайплайне. Вообще нет «одного правильного способа», есть 15 конкурирующих и большинство чем дальше, тем больше про дрочь вприсядку, когда для простого примера вдруг надо поднимать целый сервер или «сендбокс»... хотя рядом есть старый способ, который никуда не делся, просто работает и не делает мозги, в отличие от одептов любого «самого правильного» способа.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 2)
Ответ на: комментарий от slackwarrior

«самого правильного» способа.

Давай оставим вопрос религии. Объективно писать вручную на скриптах, когда cmake - это те же скрипты, но с обилием всяких помогалок для единообразного вида на разных системах и уменьшением времени разработки по сравнению с ручным описанием сборки на bash с нуля.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

с ручным описанием сборки на bash с нуля

я говорил о том, что при определенном подходе, это будет тривиально.

zerhud
() автор топика
Ответ на: комментарий от rumgot

Ну религия так религия, пиши каждый раз на цмейк, если нужны «помогалки» чтоб простой скриптик написать для того с чем тыщу лет назад прекрасно справлялся grep, глобальная замена sedом и еще пара фильтров в пайпе :) Велосипедостроители все сводят к религии, не замечая своего NIH синдрома. Какая там тебе ручая сборка всего на баш приснилась — знает только боженька :) Иногда просто нужна рутинная автоматизация («билдсистема» еще не все, а комбайн «помогалок» ради простых вещей заведомо не нужен), скрипты для которой на цмейк просто не выглядят «простыми», а девопсы без «помогалок», вебморд и т.д. уже порой и шагу ступить не могут: фильтр по логам гита на цмейке конечно можно написать... но зачем.

slackwarrior ★★★★★
()
Ответ на: комментарий от zerhud

Одептов «бестпрактисов» просто нельзя просить написать простой пример :) там часто будет ехал оверкилл через оверкилл.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

Ну религия так религия, пиши каждый раз на цмейк, если нужны «помогалки» чтоб простой скриптик написать для того с чем тыщу лет назад прекрасно справлялся grep, глобальная замена sedом и еще пара фильтров в пайпе :)

А еще раньше на assembler писали.

Какая там тебе ручая сборка всего на баш приснилась — знает только боженька

Почитай ветку.

Иногда просто нужна рутинная автоматизация («билдсистема» еще не все, а комбайн «помогалок» ради простых вещей заведомо не нужен

Что такое эти «простые вещи»? Hello world. Мы обсуждаем, что в реальности используется или, что можно дома велосипедить на один раз?

скрипты для которой на цмейк просто не выглядят «простыми»

По сравнению с bash скорее всего выглядят.

а девопсы без «помогалок», вебморд и т.д. уже порой и шагу ступить не могут: фильтр по логам гита на цмейке конечно можно написать… но зачем.

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

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от rumgot

Зачастую щас «проект» это тоже просто пирамидка из бустов, кутей и т.д., т.к. архитекторы не хотят чтоб девелоперы писали килотонны велосипедов, а стало быть это просто куча зависимостей от чужого бойлерплейта. Совершенно неважно скока там чужих файлов, которые еще и не все цмейком собираются (например, v8 или буст :) Можешь склеить их цмейком. Но это совсем не обязательно.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

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

rumgot ★★★★★
()
Ответ на: комментарий от slackwarrior

которые еще и не все цмейком собираются

Процесс сборки своего проекта и процесс сборки окружения в виде буста - это разные процессы. Не важно, как собирется буст, важно, что его можно использовать через cmake.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

А еще щас некоторые без «репозитория сиплюсплюса» шагу ступить не могут :) И? :)

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

Ну он либо знает инструменты и простые способы. Или не знает, что гиту не нужна вебморда чтоб работать. А еще что зависимости не надо каждый раз скачивать и пересобирать знают не все (более того, кукарекают про «апдейты всегда хорошо»... до первой поломки билда из-за свежей регрессии и тонны хейта в рабочем чятике от толпы раздосадованных разработчиков :)

slackwarrior ★★★★★
()
Ответ на: комментарий от rumgot

процесс сборки окружения в виде буста - это разные процессы

важно, что его можно использовать через cmake

Можно. Не всегда нужно :) а порой таки важно как собирается буст, т.к. есть варианты как с ним линковаться и «дефолт» не нужен. Т.к. есть N клиентов каждый со своими тараканами.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от rumgot

Удобство — это вообще субъективно. Ман «синдром утенка». А бестпрактисы каждые полгода новые :) и их новорожденные одепты тоже вылупляются регулярно. Например, свой опыт считают универсальным :) Но в других среднекрупных проектах делают по-другому, потому что... им так удобнее :)

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

А башик уже можно везде запустить

И сидеть изобретать на нем мейк (например, сравнивать даты файлов у объектников и исходников)

pihter ★★★★★
()
Ответ на: комментарий от pihter

Не надо ничо изобретать :) ИТТ всем мерещится какой-то версус батл. Можно пользоваться и тем и тем. Другое дело что некоторым на любой чих комбаен «помогалок» подавай.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

Говоря про веб морду я имел ввиду какой нибудь jenkins.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

Да так-то скрипты на баше нормально для сборки окружения применять. Только положить их надо в гит где-то около Dockerfile.

Например, собираешь под дебиан и тебе apt настроить надо

COPY scripts/apt.sh /tmp/apt.sh
RUN /tmp/apt.sh
fluorite ★★★★★
()
Последнее исправление: fluorite (всего исправлений: 1)
Ответ на: комментарий от fluorite

Не окружения, а в качестве альтернативы использованию cmake.

rumgot ★★★★★
()
Ответ на: комментарий от slackwarrior

Можно пользоваться и тем и тем. Другое дело что некоторым на любой чих комбаен «помогалок» подавай.

Да я так и делаю: почти все собираю мейком, а в редких случаях, когда не хватает, немного подсобляю башем: на кой пес людям нужно что-то еще для сборки – для меня все еще загадка

pihter ★★★★★
()
Ответ на: комментарий от fluorite

Ну ты уж все-таки поясни, ато этой фразой что угодно прикрыть можно.

Чем мейк мешает в проекте на 50 разработчиков? И как помогают ваши бестпрактисы в этом? (спасибо Слаквариору за слово)

Что вообще за смесь мух с котлетами? Как связана система сборки и количество разработчиков? Вы там все впятидесятером одновременно что-ли один и тот же мейкфайл бросаетесь редактировать? А кто всем этим руководит? Аджайл ваш проклятый? )

pihter ★★★★★
()
Ответ на: комментарий от pihter

Вы там все впятидесятером одновременно что-ли один и тот же мейкфайл бросаетесь редактировать? А кто всем этим руководит? Аджайл ваш проклятый? )

Вспоминается прямо как старик Хоттабыч первый раз пришёл на футбол и удивлялся что толпа взрослых мужиков бегает за одним мячиком:-)

AntonI ★★★★★
()
Ответ на: комментарий от slackwarrior

И там цмейка нет :)

Есть. И я даже тебе больше скажу - он даже им успешно собирается. Во всяком случае большая часть модулей точно, прям все-все не проверял.

KivApple ★★★★★
()
Ответ на: комментарий от slackwarrior

каждые полгода

CMake является самой популярной системой сборки уже много лет. Если ты захочешь притащить в свой проект либу, вероятность что она содержит CMakeLists.txt (даже если её можно собрать чем-то ещё) значительно выше, чем какой-либо другой системы сборки. По моим наблюдениям среди +- популярных либ доля поддержки CMake две трети или выше. А там где этого нет, это зачастую следствие legacy, если проект большой и серьёзный. Кстати, от него постепенно уходят. Даже Boost уже можно собрать CMake (я проверял, работает).

Все популярные IDE поддерживают CMake, чего не скажешь о других системах сборки. Проект на CMake я могу с одинаковым успехом открыть хоть в Clion, хоть в Visual Studio, хоть в Qt creator. Это из «готовых» IDE. Для IDE-конструкторов типа VSCode тоже есть плагины. Никакая другая система сборки не может похвастаться столь широкой поддержкой. Ты либо обречён писать в блокноте, либо превращать в конструктор любую IDE и не факт, что получится.

Даже для проекта из одного файла CMake неплох, потому что там CMakeLists.txt будет из трех строчек, зато из коробки уметь сборку под разные ОС и компиляторы.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 5)
Ответ на: комментарий от KivApple

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

hbee ★★★★
()
Ответ на: комментарий от KivApple

Давай, расскажи про сборку буста цмейком :) а то многим «не важно как он собирается», а потом оказывается важно :)

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

Я взял свой пет-проект игрового движка (моя цель - статическая линовка, если что, это обуславливает решения) и сделал git add submodule, а затем add_subdirectory. И смог успешно подключить regex из компилируемых модулей и несколько header only.

При этом оно успешно собирается GCC, Clang и MSVC.

Я не исключаю, что некоторые модули могут не работать, но те что мне нужны - работают.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от hbee

Куда усложнился?

Проект уровня Hello world по-прежнему состоит из двух строчек (директивы project и add_executable). Сложный проект с большим количеством библиотек и конфигураций сборки будет сложным с любой системой сборки.

KivApple ★★★★★
()
Ответ на: комментарий от hbee

И они существуют

поделитесь пожалуйста :)

zerhud
() автор топика
Ответ на: комментарий от slackwarrior

Да, но B2 используется только бустом, а CMake кучей других библиотек. То есть CMake я могу собрать условные две трети популярных библиотек, включая Boost. А B2 могу собрать только Boost. Не видишь тенденцию?

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

Сложный проект с большим количеством библиотек и конфигураций сборки будет сложным с любой системой сборки.

А простой - простой везде. Типа хелоу ворлд на мейке или баше не в две строчки собирается

pihter ★★★★★
()
Ответ на: комментарий от pihter

Типа хелоу ворлд на мейке или баше не в две строчки собирается

В две. Только две строчки на cmake дают:

- Инкрементальную сборку с учётом инклюдов (пригодится как только в хеллоуворлд станет больше одного файла)

- Поддержку GCC, Clang, MSVC

- Поддержку выбора режима дебаг/релиз без необходимости помнить опции конкретного компилятора

Это базовые потребности любого проекта с прицелом на кроссплатформенность. И при попытке добавить эти фичи в Makefile или Bash они мгновенно распухнут за пределы этих двух строчек. А это мы только прожиточный минимум организовали и даже не начали подключать библиотеки (подключать, кстати, хотелось бы с адекватными сообщениями об ошибках и, опционально, fallback, так что просто воткнуть `pkg-config --cflags --libs foo` не вариант).

KivApple ★★★★★
()
Ответ на: комментарий от pihter

А что пояснить? 50+ разрабов генерируют овердохера кода и ещё больше тащат зависимостями. Нужно покрытие тестами, сборка в релиз, сборка в дебаг, сборка с санитайзером, сборка с профилированием, юнит-тестирование, функциональное тестирование, нагрузочное тестирование, упаковка в деб, рпм, в инсталятор, поставка в виде образов виртуальных машин. Сбор метрик с работающей системы, интеграция с графаной-прометеем, дашбордики для менеджеров. Мейкфайла ему хватает :)

fluorite ★★★★★
()
Ответ на: комментарий от KivApple
  • Инкрементальную сборку с учётом инклюдов (пригодится как только в хеллоуворлд станет больше одного файла)
  • Поддержку GCC, Clang, MSVC
  • Поддержку выбора режима дебаг/релиз без необходимости помнить опции конкретного компилятора

это все то, зачем мейк и нужен. и точно так же элементарно реализуется на баше, если сие по вкусу. Честное слово, не понимаю из-за чего сыр-бор. Ну не в две строчки, ну в 5-10, что это меняет? Тем более что это же все реализовано в симейке не в этих двух строчках, а в заранее подготовленных подпрограммах, а тут только вызываются, что мешает на мейке или баше (или вообще любом ЯП) реализовать это в подпрограммах и потом вызывать в две строчки?

Я ниче против симейк не имею, я просто искренне не понимаю зачем он нужен, когда мейк уже есть. Чтоб инкрементальную сборку делать в две строчки вместо 5? Чтоб можно было собирать под разные платформы? Так мейк это умеет опять же из коробки. Разными компиляторами – пожалуйста. Да и ладно бы это сложно и неудобно делалось, так ведь надо осилить концепцию переменной и условия. Куда уж проще?

С библиотеками тоже не вижу проблемы: ты волен сделать это любым из удобных тебе способов, хошь с сообщениями, хошь с проверками, хошь со скачиваниями и сборкой вообще все что хочешь: этож набор консольных команд выстроенный в иерархию зависимостей, а уж как эту иерархию строить, какие зависимости учитывать – все в твоих руках, делай что надо. Чего вам тут может не хватать? Для меня загадка (да и чего не хватает – бери да реализуй как подзадачу, да уже реализовали до тебя, не сомневайся)

pihter ★★★★★
()
Ответ на: комментарий от fluorite

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

release_build: build build_deb_package build_mustdie_installer

debug_build: build make_tests send_report_for_managers

build:
  $(CXX) $(FLAGS) .... $(target)

Учу использовать: пишешь make debug_build в каталоге где лежит мейкфайл.

Прости за сарказм, но что из перечисленного не реализуется как набор команд в цели? Я В УПОР НЕ ПОНИМАЮ чем написать набор команд для сборки деб пакета в любой другой системе сборки лучше, набора команд для сборки деб пакета в правиле мейкфайла. Его ж в любом случае писать: или в бестпрактисных системах сборки ты ставишь галочку «хочу виндовый инсталлятор» и оно делает? Нигде описывть не надо, вот прям волшебно само иконку инсталлятору назначает, само триклятое лицензионное соглашение сочиняет?

Мейкфайла ему хватает :)

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

pihter ★★★★★
()
Ответ на: комментарий от pihter

сборки деб пакета в любой другой системе сборки лучше, набора команд для сборки деб пакета в правиле мейкфайла. Его ж в любом случае писать: или в бестпрактисных системах сборки ты ставишь галочку «хочу виндовый инсталлятор» и оно делает?

Вообще-то да.

В Help написан пример:

cmake_minimum_required(VERSION 3.20)
project(CoolStuff)
add_executable(coolstuff coolstuff.cpp)
install(TARGETS coolstuff RUNTIME DESTINATION bin)
include(CPack)

и вот у тебя есть deb пакет, rpm пакет, инсталлятор CoolStuff-0.1.1-win32.exe и Mac OS X bundle заодно.

Покажи свой Makefile делающий тоже самое, если у тебя есть один файл coolstuff.cpp с твоей программой.

И сравни с этими 5 строчками.

Потом подумай почему использует готовое,а не изобретают велосипеды.

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от pihter

Разными компиляторами – пожалуйста

У GCC/Clang и MSVC несовместимые опции компиляции от слова вообще. Даже имя выходного файла задать или уровень оптимизации/наличие отладочной информации.

Вопрос не в том, что это нельзя реализовать на make. Вопрос в том, что там 5 строчек, тут 10, потом ещё что-то добавили. И вот уже на экран не влезает. А мы только начали.

Cmake перестанет влезать на экран позднее. На простых проектах он будет ощутимо проще Makefile, при этом предоставлять прожиточный минимум функционала типа кроссплатформенности и инкрементальной сборки по принципу «просто работает».

Вы не понимаете, почему использовать чужие популярные и отлаженные подпрограммы с кучей документации и примеров вместо своих велосипедов - лучше и для вас, и для гипотетического читателя вашего кода?

Тогда и библиотеки можно не подключать, в целом. Многие алгоритмы реализуются самостоятельно в несколько десятков/сотен строчек. Или это другое?

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от pihter

точно так же элементарно реализуется на баше, если сие по вкусу

Нет. Тебе нужно парсить файлы, чтобы достать инклюды и также отслеживать в них изменения. Иначе никакой инкрементальной сборки у тебя нет.

ox55ff ★★★★★
()
Ответ на: комментарий от fsb4000

или в бестпрактисных системах сборки ты ставишь галочку «хочу виндовый инсталлятор» и оно делает?

Вообще-то да.

И как это работает? Лицензионное соглашение в инсталлятор оно само сочиняет? Иконку? Или это где-то описано в каком-то когнфиге, где-то есть код, который этим занимается и твое «ставишь галочку и оно само делает» на самом деле – вызов подпрограммы? Вопрос риторический. И че, ты думаешь мейк не умеет подпрограммы вызывать? Вопрос тоже риторический. А вот не риторический – разница-то в чем? В том что для симейка уже есть набор готовых подпрограмм? Это что-ли? А что мешает такой для мейка создать?

Покажи свой Makefile делающий тоже самое, если у тебя есть один файл coolstuff.cpp с твоей программой.

Пфф: $(shell build_all_installers_you_want.sh) – умеет даже больше твоего. Ваще все что ни придумаешь – умеет. Вот какой всемогущий мейк, умеющий вызывать внешний код

pihter ★★★★★
()
Ответ на: комментарий от KivApple

Вопрос не в том, что это нельзя реализовать на make. Вопрос в том, что там 5 строчек, тут 10, потом ещё что-то добавили. И вот уже на экран не влезает. А мы только начали.

Да что там, что там – есть возможность разбивать задачу на подзадачи. В мейке есть возможность подзадачу добавить зависимостью к какой-то текущей. То есть в конечном счете, это даже не строчка, а просто уникальный идентификатор: короче – некуда. Набор готовых реализаций под все популярные задачи никто не запрещает сделать, никто не запрещает сделать и свою под тонко-настроенную/уникальную задачу. Уверен что в симейке да и любой другой системе сборки – все то же самое. Я просто представить себе не могу как даже теоретически это можно сделать проще, чем

задача1: зависимость1 подзадача1
  действие
  действие

зависимоость1:
  действие
  действие

то есть, по сути, это всего лишь расписывание иерархии зависимостей для выполнения задач, причем настолько простым способом, что проще не придумаешь. А реализация в любом случае – набор команд в конечном счете. И в симейке тоже инсталлятор не по волшебству строится: где-то лежит код с последовательностью действий, не обманывайте что по волшебству, я уверен – код есть

pihter ★★★★★
()
Ответ на: комментарий от KivApple

Вы не понимаете, почему использовать чужие популярные и отлаженные подпрограммы с кучей документации и примеров вместо своих велосипедов - лучше и для вас, и для гипотетического читателя вашего кода?

Понимаю. Я не понимаю какая разница между чужими популярными и отлаженными программами на симейке и ЧПОП на мейке? Все те преимущества, которые вы мне описываете родным образом реализуются на мейке, зачем для этого надстройка – в упор не вижу. Если вы мне скажете что так исторически сложилось, что вот такой вот набор ЧПОП образовался на симейке, а так вообще-то никто не мешал сделать то же самое на мейке – то я пойму, в реальзной жизни так постоянно бывает. Но вы же говорите о каких-то преимуществах и начинаете выдавать возможность запуска готовой отлаженной подпрограммы на симейке за преимущество перед мейком. Нет. Нет такого преимущества – все то же самое, мейк тоже так умеет. И даже баш. Просто бери, да реализуй подход

pihter ★★★★★
()
Ответ на: комментарий от fluorite

Ну и где дашбордики в графану-то?

Начну с того что дашбордики – суть ерунда, ИМХО. В данном случае. Графана я не знаю что, ну по контексту понятно.

Уверен, что сборшик подготавливает для дашборда данные и дергает за крючок, тогда:

build: ... process_dashboard ...
  ...

process_dashboard: prepare_data pull_grafana_hook

prepare_data:
  $(shell build_xml_for_grafana.sh)

pull_grafana_hook:
  curl $(GRAFANA_HOOK_URL)

ну и тд. в чем проблема-то? Мейк всего лишь описывает иерархию зависимостей для действий. Сами действия если сложнее пары команд и предполагается повторное использование – ну оформи в подпрограмму в том или ином виде. Уверен, у всех остальных сделано так же. ТАк в чем разница и где и для каких случаев мне не хватит мейка?

pihter ★★★★★
()
Ответ на: комментарий от ox55ff

Тебе нужно парсить файлы, чтобы достать инклюды и также отслеживать в них изменения

Не вижу проблемы. Симейк сам это умеет или где-то есть код, который, скажем для плюсов это умеет. А для другого языка? А для моего собственного? Если есть подобный модуль для симейка – почему нельзя сдалать его для мейка? Навскидку, добавить правило чтоб бпроходилось по файлу и рекурсивно touch-ило все инклюды, тогда мейк тригернется.

А чем плохо по времени последнего изменения смотреть? Ведь ести инклюд никто не изменял с последнего раза – значит и пересобирать не надо, разве нет? Это – родная функциональность мейка

pihter ★★★★★
()
Ответ на: комментарий от pihter

В том что для симейка уже есть набор готовых подпрограмм? Это что-ли? А что мешает такой для мейка создать?

Да. Опять же менеджер пакетов для C++ есть только для CMake. И много всего есть только для CMake, как поддержка IDE.

В теории могли бы делать и для gmake, но за десятки лет никто не сделал. И всё что есть для CMake реализовать для gmake потребует сотни человеко-лет.

fsb4000 ★★★★★
()
Ответ на: комментарий от pihter

Не уверен что отвечаю на правильное сообщение (оно на момент набора моего тупо оказалось последним).

В чём я уверен though - Вы движетесь в неправильном направлении. Ну, или «за деревьями леса не видите».

CMake vs (GNU) make - погоды не делает. В контексте оригинального вопроса ТС речь нужно вести исключительно о числе «единиц трансляции», и об идиоматическом подходе - «мы режем мелко или крупно». Я сторонник идеи «резать мелко», и жизнеспособность такого подхода подтверждается десятилетиями практического опыта разработки в коллективе из ~1000 сотрудников активно коммитящим в HEAD. И, на самом деле, всё сводится к правильной / оптимальной декомпозиции…

ПыСы. Там кто-то заявлял что готов за вечер «make» реализовать. Смело. Я бы не взялся. И я даже готов ткнуть носом где будут проблемы, и какие фундаментальные задачи придётся решать. Но, это не то что бы мне хотелось обсуждать сегодня…

ПыПыСы. И таки удачи Вам с Вашими проектами: чую одним местом - она Вам пригодится…

bugfixer ★★★★★
()
Ответ на: комментарий от pihter

Да никаких проблем. Курятник с помощью гвоздей сколотил - и небоскрёб сдюжишь. Сварка - она же лишь скрепляет детали в том или ином виде. Уверен, во всех небоскрёбах используют гвозди.

Попробуй что ли реально написать мейкфайл для сборки какого-нибудь хромиума что ли. Потому что воображаемая работа - она всегда легкая.

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

мейкфайл для сборки какого-нибудь хромиума

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

ya-betmen ★★★★★
()
Ответ на: комментарий от fsb4000

В теории могли бы делать и для gmake, но за десятки лет никто не сделал. И всё что есть для CMake реализовать для gmake потребует сотни человеко-лет.

Ну вот на это я согласный

pihter ★★★★★
()
Ответ на: комментарий от bugfixer

Там кто-то заявлял что готов за вечер «make» реализовать. Смело

Да не на 100 процентов совместимый, а реализующий саму идею с набором таргетов и зависимостей, которые раскручиваются. Про «за вечер» я, конечно, загнул, но не сильно.

Я сторонник идеи «резать мелко»,

Я тоже, но наш-то спор давно отвалился от материнского топика

И таки удачи Вам с Вашими проектами: чую одним местом - она Вам пригодится…

Спасибо за снисходительность :)

ПыСы: меня можно «на ты»: я – парень простой

pihter ★★★★★
()
Ответ на: комментарий от fluorite

Да никаких проблем. Курятник с помощью гвоздей сколотил - и небоскрёб сдюжишь. Сварка - она же лишь скрепляет детали в том или ином виде. Уверен, во всех небоскрёбах используют гвозди.

Ерничай-ерничай. Не по делу ж говорить. Я показал что мейк может вызывать подпрограммы. И все твои космические сложности, которые ты пророчил, точно так же решаются в две строчки – вызовом подрограмм. На это что ответишь, кроме «вы не понимаете, это – другое» и «ты пацан просто жизни еще не знаешь» ?

Попробуй что ли реально написать мейкфайл

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

pihter ★★★★★
()
Ответ на: комментарий от ya-betmen

Вообще не проблема, pihter умеет вызывать подпрограммы. Впрочем, ему достаточно сказать «ничего сложного не вижу», и вуаля - оппонент повержен, весь код всех проектов мира перенесён на мейк и баш, везде радость и счастье.

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

Ну скатись еще в обсирание в третьем лице в присутствии обсираемого.

Я так и не услышал от тебя в чем проблема-то? Складывается впечатление что ты не понимаешь, а делаешь умный вид.

pihter ★★★★★
()
Ответ на: комментарий от pihter

Да нет никаких проблем. Устраивает тебя мейк - пользуйся этой смоляной ямой. Прости, но опыт использования не передаётся буковками.

Вот тебе преимущества cmake над make+bash

  • стандарт
  • размер кода
  • наличие готовых рецептов
  • скорость внесения изменений
  • поддержка IDE
fluorite ★★★★★
()
Ответ на: комментарий от fluorite

Вот мне просто интересно, вас с народом выше, не смущает, то вы сравниваете генераторы сценариев для «сборщика» и собственно «сборщик»? Ладно бы ещё с make с ninja воевали или cmake/meson с autotools.

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 1)
Ответ на: комментарий от pihter

Как оно может конкурировать, если без второго в принципе жить не может?

Писать Makefile для какого-нибудь условный GIMP я бы не согласился даже за много денег. Про какой-нибудь Chrome/Firefox/Blender я в принципе не говорю.

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

Как оно может конкурировать, если без второго в принципе жить не может?

в 2023 CMake почти никто не использует совместно с gmake, так как есть Ninja который тупо быстрее.

fsb4000 ★★★★★
()
Ответ на: комментарий от SkyMaverick

Как оно может конкурировать, если без второго в принципе жить не может?

Это легаси. Исторически сложилось. Некоторые сборочные системы могут и сами напрямую вызывать компилятор. Закопанный qbs, например.

ox55ff ★★★★★
()
Ответ на: комментарий от ya-betmen

Ну справедливости ради я бы не отказался от мекфайла для хромиума. Там треш а не билд.

Я как-то пытался собрать, там специальная инструкция для тупых: скриптик, который якобы все сдалает за меня. Сутки тянулось, сутки собиралось – не осилило по памяти на 16 гигах. Вот это как так? Там че, реально все в один файл слепляют перед компиляцией? Как так можно? Тьфу!

pihter ★★★★★
()
Ответ на: комментарий от SkyMaverick

в треде про нинзю и не вспоминали

Было же, причем на прошлой странице

pihter ★★★★★
()
Ответ на: комментарий от SkyMaverick

Весь тред сводится к : высокоуровневые системы сборки vs. «деды собирали»

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

pihter ★★★★★
()
Ответ на: комментарий от pihter

Makefile писать руками для чего-то больше какого-нибудь мелкого драйвера шибко много/долго/дорого (да и и ещё эта ё*ая табуляция). Автоматизации хочется. Ну вот тулзы/cmake/etc. и есть эта самая автоматизация. Плюсом gmake ещё и довольно торомозной - отсюда родилась ninja.

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 1)
Ответ на: комментарий от SkyMaverick

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

pihter ★★★★★
()
Ответ на: комментарий от pihter

Я как-то пытался собрать, там специальная инструкция для тупых: скриптик, который якобы все сдалает за меня. Сутки тянулось, сутки собиралось – не осилило по памяти на 16 гигах. Вот это как так? Там че, реально все в один файл слепляют перед компиляцией? Как так можно? Тьфу!

Хз про конкретно хромимум, но LTO люто до памяти жадно бывает.

madcore ★★★★★
()
Ответ на: комментарий от ox55ff

Нет. Тебе нужно парсить файлы, чтобы достать инклюды

По-моему, GCC с этим сам справляется.

и также отслеживать в них изменения

А с этим — make.

utf8nowhere ★★★
()
Ответ на: комментарий от fluorite

Прости, но опыт использования не передаётся буковками.

Я тоже самое могу сказать про смаке. Шаг влево, шаг вправо - дикий головняк, надо найти спеца который знает какую свистелку дёрнуть что бы нужная опция всплыла в нужных местах. А потом так ой - версия смаке слишком старая, там эти свистелки совсем по другому свистят.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

надо найти спеца

доку надо прочитать, а не спеца искать

версия смаке слишком старая

для контроля окружения есть решения навроде докера

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

Ога-ога, все в докер завернуть и неделями доки штурмовать.

А потом удивляются что хеллоуворлд пишется месяц и занимает дцать гб.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Да-да, вы правы. Докер - это сложна-а и вообще хипсторы придумали. А читать - не барское дело. Так, интернетик полистать, руга-ають. Гигабайты на хуловорд! Сварочники эти едрить-мандрить, спеца пойди найди, чтоб ток выставил. Ну его, вот гвозди - это вещь! Дед курятник сколотил, до сих пор стоит!

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

Зачем делать сложно когда можно сделать просто?

Для каждой задачи хорош свой инструмент. Это религиозное что то, пихать докер-смаке во все дырки? Сюда же можно отнести хмл/жсон/sql/иксель - кто на что учился…

Если для Ваших задач докер-смаке хорош, с чего Вы взяли что везде так? Если Вы других задач не встречали, то это говорит только о Вашем кругозоре а не о докере. Простите что приходится разжевывать Вам такие элементарные вещи.

Вы ещё на стиралки с микроволновками докер ставить предложите…

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Давайте перефразируем на git.

Если для Ваших задач контроль версий хорош, с чего Вы взяли что везде так? Если Вы других задач не встречали, то это говорит только о Вашем кругозоре а не о контроле версий

И уже несколько бредово звучит. Теперь поменяйте контроль версий на контроль окружения. Это примерно одно и то же, только одно применимо к процессу разработки, а второе - к процессу сборки.

Вы ещё на стиралки с микроволновками докер ставить предложите…

А вы, простите, прямо на стиралках свои плюсовые проекты собираете? Вот в сборке для стиралки докер бы помог…

fluorite ★★★★★
()
Последнее исправление: fluorite (всего исправлений: 2)
Ответ на: комментарий от fluorite

Вы и правда не видите разницы между гитом и докером/смаке? Аналогия (с гитом в тч) не является аргументом или доказательством, но может являться дидактическим приемом.

Я Вам страшную тайну открою, есть люди которые даже без шелла обходятся. Хотя уж шелл то куда востребованней чем гит. Мир большой и разный, и далеко не везде нужен контроль окружения. У нас скажем как правило не нужен. И смаке у нас избыточен. За 20+ лет при мне юзали его ровно два раза, один раз потому что кроссплатформенность и вот это все (и намучались страшно), второй раз просто молодежь баловалась. В остальных случаях обычный gnu make.

А вы, простите, прямо на стиралках свои плюсовые проекты собираете?

По разному, обычно на десктопах/кластерах. Там же где запускаем. И ой, докеров там нету. В облаках правда что то такое есть, но для нас это скорее экзотика (в РФ это сейчас банально дорого).

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.