g++ 1.cpp 2.cpp

1.cpp - файл с функциями

2.cpp - делает #include 1.h

1.h список функций из 1.cpp

Перепиши на rust и все твои проблемы сами решатся.

P.S. добавляй плиз тег c++ чтобы тред попал под мой игнор-лист тегов.

запиши Makefile для сборки

команда #include добавляет ведь, только библиотеки??

Нет. Эта директива препроцессора добавляет заголовочные файлы бибилиотек (в основном), где содержатся объявления нужных функций или классов.

Но никто тебе не запрещает использовать эту директиву препроцессора и для вставки одних исходных файлов (а так же всяких ресурсов, результатов MOC и UIC-генерации и т. д.) в другие исходные файлы.

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

Лушче уж cmake. Он конечно та ещё наркомания, но лучше в мире C++ ничего нету.

Есть Meson, который продвигает Red Hat.

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

Перепиши на rust и все твои проблемы сами решатся

Ну давай расскажи мне…

Директива #include оперирует понятием «файл», т.е. подставляет содержимое файла в место директивы. См. первый комментарий и гуглить препроцессинг.

А вот почему должен взлететь Meson, о котором я узнал только из этого треда, я не знаю.

Потому что на него сделал ставку Red Hat и множество проектов которыми ты сегодня пользуешься в Linux-дистрибутивах собираются именно им: systemd, X.Org, Wayland, GTK+, MESA, весь GNOME etc.

Забавно выглядит таблица сравнения Meson / CMake / Make на странице Meson в википедии (https://en.wikipedia.org/wiki/Meson_(software))

Т.е. рассмотрим три преимущества над CMake:

• Datatypes - а они точно нужны? А есть кейсы в CMake которые нельзя сделать без этого? Хз. Просто вот они есть и все.

• List datatype - т.е. предыдущий пункт не включает этот, ага конечно, нужно ведь натянуть до трех преимуществ. Опять же в CMake все является строкой. Но есть отдельные команды для обработки строк/списков. Приведите же кейсы, для которых отсутствие в CMake типов не позволяет что-то сделать. Так хер.

• Dictionary datatype - да блин. Опять те же яйца. В пункт 1 это не входит почему-то. И далее по списку: приведите кейс, в котором требуется наличие данного типа и который не может быть решен без него с помощью CMake.

Потому что на него сделал ставку Red Hat и множество проектов которыми ты сегодня пользуешься в Linux-дистрибутивах собираются именно им

Да. И хер знает сколько проектов, которыми мы пользуемся в Linux и в разработке собираются через CMake.

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

команда #include добавляет ведь, только библиотеки??

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

Я бы не сказал, что гном это успешный проект. Как и та библиотека, на которой он основан.

Но C++ - не Linux. Ладно сишка, могу понять. А C++ это игроделы в первую очередь.

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

cmake дефакто стандарт

Только какой то неустоявшийся. Я один раз работал в проекте который собирался cmake:

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

2. при смене версий cmake выяснялось что то что то куда то перестало пробрасываться местами

3. любая хоть сколько то нестандартная операция требовала каких то гнусных извращений.

А так да, типо кроссплатформенный - и на *nix и на win собирается, кучу каких то настроек можно вводить… Но для небольших проектов (да еще и не отягощенных кроссплатформенностью) он КМК сильно избыточен.

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

организационная проблема=>бить тимлида по рукам за то что он не смог организовать чтобы все работали в одних и тех же версиях софта

при смене версий cmake выяснялось что то что то куда то перестало пробрасываться местами

Подробнее надо смотреть

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

Плата за C++

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

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

Плата за C++

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

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

1) скомпилировать файлы .cpp по отдельности

g++ -c 1.cpp
g++ -c 2.cpp

2) слинковать полученные на предыдущем шаге объектные файлы в одну программу

g++ -o myprogram 1.o 2.o

Но вручную это обычно никто не делает, профессиональные разработчики для этого используют autotools

профессиональные разработчики для этого используют autotools

Ну ты трололо конечно. Ради 2 файлов никто autotools запрягать не будет.

Read and about compiler and linker steps

Or short example https://stackoverflow.com/questions/8513342/how-do-i-compile-a-project-with-multiple-source-files/8513376#8513376

Файлы .cpp не надо добавлять один в другой.

Тебе нужна система сборки. К сожалению, стандарта на систему сборки для C++ нет.

Самый универсальный и низкоуровневый (но не самый простой) вариант - утилита make (можешь погуглить, «как писать Makefile»). Поэтому люди используют cmake, qmake, meson и др. Иногда упомянутый выше autotools, но те, кто использует autotools, точно знают, для чего он им понадобился, в общем, это не твой случай.

Поэтому для обучения сделай проект на пару-тройку файлов с помощью make, чтобы понять, как это работает, а потом прыгай на cmake или meson.

А вот почему должен взлететь Meson

Он уже взлетел, у тебя треть системы им собрано.

4.2, игродел в треде

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

У нас симейк во все поля, в том яисле под сонсоли, да

На тебе повеселее таблицу

https://xon.sh/contents.html

вижуал студия со своей, встроенной, билд системой

не. вижуал студия норм. Но там везде CMake + Ninja. Даже в Microsoft. Все перешли на Ninja. Ninja просто собирает быстрее чем msbuild или gnu make…

У нас, помнится, был какой-то инкредибилд. Но это дцать лет назад было.

Да, все верно.

есть файл 1.cpp, в нем делаем, инклуд: #include 2.h и просто в этот 2.h добавляем еще функции c++ на c++ языке.

И компилируем его командой: g++ test.cpp или если с gtk4, то: g++ -o test test.cpp $(pkg-config –cflags –libs gtk4)

А C++ это игроделы в первую очередь.

Ага. И мы тут тоже в бирюльки играемся. Да-да-да.

А вообще, я смотрю, автор хоть и наивно, но движется в правильном направлении. Сначала спрашивал, как ему опакечивать ненаписанную игру, потом воевал с vscode (я б ему, конечно, Geany порекомендовал, ну да ладно), а теперь решил таки добраться до понимания того, как оно работает.

[troll-mode]Следующий и самый страшный вопрос, видимо, будет — ПОЧЕМУ оно работает, учитывая, какой кошмарной изолентой это всё скручивается.[/troll-mode]

Одобряю!

Перепиши на rust и все твои проблемы сами решатся.

Все проблемы не решатся. Но какая-то часть, да.

Может ты ещё предложишь суицид?

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

Типы данных придумывают не потому что без них нельзя что-то написать.

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

Офигенный аргумент. Обажаю аналогии. Ну напиши аналог Ведьмак 3 на ассемблере. Докажи правоту.

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

Типы данных придумывают не потому что без них нельзя что-то написать.

В системе сборки точно есть от этого ощутимая польза? И далее, что за «что-то»? Вот что именно?

Вместо того что бэ взять лишп, как все серьезные дяди…:-)

Докажи правоту.

Зачем мне доказывать твою правоту? Весь твой пост был о том, что если нету кейсов когда нельзя обойтись без чего-то, значит не нужно. Таким образом можно доказать ненужность c++.

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

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

ПОЧЕМУ оно работает

Такими вопросами большинство задастся, если откроют листинги, написанные ими год назад и раньше ;)

Зачем мне доказывать твою правоту?

Зачем вообще что-то утверждать?

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

Ты не понял. Мой пост был о том, что само по себе наличие данной фичи - не преимущество. Преимущество - это например ощутимое сокращение кода для описания сборки или возможность выполнить какое-то новое действие или еще что-нибудь. Так вот никаких сравнений таких кейсов meson/cmake приведено не было. Вот просто есть и есть, значит профит!!!

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

Так и что ты хочешь мне доказать?

Дело не в количестве кода.

Количество кода - это я привел пример той выгоды, которую может нести (а может не нести) некоторая функциональность продукта, которой нет у конкурента. Я привел это для того, чтобы понимать, что нужно обсуждать не только функциональность, но и те преимущества, которые эта функциональность дает.

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

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

Мы говорим про язык системы сборки. Не нужно мешать сюда C++ и другие языки для разработки непосредственно приложений. Ты можешь привести кейс, где в CMake не хватает типов переменных?

Может в нужно в языки систем сборки еще классы завести? И тоже потом сказать: «для чего-то нужно».

самый популярны обычно не значит самый лучший.

есть b2, например, там меньше все писать. cmake удобен в оснонвом поддержкой разных ide, qtcreator умеет открывать проект по cmakelists.txt. плюс описаны find файлы для кучи библиотек. остальное так себе.

Cmake — программист с++ просто обязан знать. Изучать Meson без необходимости — лишняя трата времени.

Когда начнешь работать со сторонними библиотеками, большинство вопросов пропадет само собой. С cmake намного проще. + появились пакетные менеджеры для C++.