Как добавить файл в проект codeblocks, чтобы компилировался?

man

#include «somefile.hpp»

Во-первых, в development. Во-вторых, покажи содержимое этих файлов, чувствую, там ад и угар

Советую перейти на CLion как можно скорее, сейчас IDE использую нормальные системы сборки, а не файлы проектов. Заодно узнаешь о вкуснейшем CMake. Кстати, обнаружен баг в программах JB, если удалять конфиг, то триал будет бесконечный.

По твоему вопросу, все должно быть просто. Удали проект который ты создал, оставь файлы исходного кода. Создай новый проект, добавь туда файлы со своим исходным кодом, это делается правым кликом по проекту в левой панели, там будет add files, потом нажимай вверху шестеренку, и все должно собраться идеально.

Удали файл main, созданный по дефолту для нового проекта (свой не удаляй), сохрани проект и попробуй снова собрать.

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

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

Ты опоздал года на три. Последние уже давно по аккаунту проверяют триалку и лицензию.

У меня все работает, на Mail.ru есть сервис временных почт.

Советую перейти на CLion как можно скорее

Нафиг эту проприетарщину. QtCreator отличная штука. Мне в последнее время даже больше чем вендовый VS2022 заходит.

Тут все топят за свою идееху но в пзду их всех, идееха не даст понимания как работает сборка больших проектов

Лучше всего в данном случае:

1. Для обучения взять любой блокнот и научится писать примитивные сначала makefile, за тем cmakelist. Что нужно поймёшь потом, я на vscode полностью ушёл.
2. Если нужно здесь и сейчас накатать на C/C++ примитивный быдлопроект взять любой инструмент который будет работать и будет понятен именно тебе без опыта. codebloks судя по всему не твой вариант

Есди ты только начал изучать кодинг, то забудь пока об IDE. Возьми обычный Kate с прикрученным через LSP анализатором кода, и Konsole. Тут посоветовали для сборки использовать сначала голые Makefile, но по мне так это пустая трата времени, лучше сразу начать с CMake.

Kate + Konsole + CMake. Потом со временем можно будет перейти на IDE, если захочется вообще.

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

УМВР

Попробовал создать проекты в codeblocks - сначала Console application, затем еще проверил на Empty project - проблем не встретил. Проекты собираются и исполняются успешно.

При создании нового файла (File->New->Empty file) показывается окно с предложением добавить файл в проект. Также можно нажать ПКМ на имя проекта в Projects, выбрать Find files и добавить существующие файлы. Предварительно я эти файлы закинул в директорию с проектом (main.cpp, hello.cpp, hello.hpp)

Debian 12, версия Codeblocks - svn 13046.

CLion намного лучше, к сожалению OpenSource альтернативы нету.

IDE намного удобнее чем блокнот, и повышает комфорт. Зачем блокнот? Почему блокнот а не ed? Нормальная IDE ничего не скрывает и не ограничивает. Наоборот, ускоряет процесс обучения, и помогает.

Возьми обычный Kate с прикрученным через LSP анализатором кода

Ничего более глупого не слышал, это сочетание мантры «ide нинужна», плюс автодополнение потому что его завезли в ваши блокноты. В чем суть то теперь, раньше вы рассказывали что автодополнение вредно, и каждый должен наизусть знать все функции и их расположение, а теперь?

Скорее всего кто то не осилил IDE, и теперь топит за блокноты.

У него хоткеи и меню слишком нестандартные. Но на вкус и цвет. Мне, для проекта с 20 .cpp и 20 .h файлами, QtCreator зашел лучше, хотя тут можно понять, проект на кутях. Но был и другой проект, с промышленной автоматизацией на плюсах(тоже файлов 40 в сумме), где вообще без гуя, консольный демон, тоже удобнее оказалось на QtCreator.

Так то по работе в VS2022 работаю, но всё чаще замечаю, что «а вот это в QtCreator удобнее было бы».

В том-то и дело, что все максимально просто: обычный hello world. Тут проблема в том, что проект не хочет читать другие файлы.

Да я бы рад, только codeforces единственное что у меня скомпилировалось вообще…

Пытался сесть на QtCreator, там вообще темный лес для меня, вообще не могу ничего запустить. В codeblocks хот бы один файл компилявится, плюс имею хотя бы опыт проганья в этой среде…

Да я также делал, но у меня он не хочет компилироваться, codeblocks вообще его не воспринимает как код :(

Не помогло, он просто отказывается видеть другой файл…

Спасибо на Clion попробую, хотя мне и правда не нужен особо навороченная среда лишь бы код компилировался, что-то вроде DevC++ но для линукса…

Спасибо за ответ, Cmake вроде как предустановлен. Остальное поставить не вопрос. Такой вопрос: там не нужно дополнительно что-то шаманить или можно втупую все три проги установить и они будут норм работать сообща?

У него хоткеи и меню слишком нестандартные.

Там любые можно поставить, они на разной ОС по умолчанию разные.

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

g++ -Wall -Wextra -std=c++20 *.cpp -o НАЗВАНИЕ_ВЫХОДНОГО_ФАЙЛА

Я тут подумал, если компьютер у тебя слабый, то возможно стоит действительно рассмотреть QtCreator, он быстрый, и легко заводится. Поддержка CMake там есть, к Qt он несмотря на название не привязан.

правой кнопокй по проджекту, add files , что сложного

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

Учти что CodeBlocks не поддерживает русские буквы в путях на Linux, может в этом дело.

Пытался сесть на QtCreator, там вообще темный лес для меня, вообще не могу ничего запустить. В codeblocks хот бы один файл компилявится, плюс имею хотя бы опыт проганья в этой среде…

Делай проект CMake, а там по образу и подобию. Там для начала синтаксис простой у CMake, если в дебри не лезть.

Установи нормальную IDE для начала. Если деньги есть, то CLion, если нет, то QtCreator.

Тебе нужен инструментарий для сборки проекта. Бери cmake, он самый распространённый. И CLion и QtCreator его поддерживают.

Если сюда придут и начнут предлагать рукописный makefile, то не слушай этих луддитов.

Соответственно все файлы проекта будешь указывать в cmake файле.

Писать код ты можешь в чём угодно, но вот собирать по началу лучше всё руками, прописывая команды прям

g++ main.cpp -o main.o
g++ util.cpp -o util.o
g++ main.o util.o myapp
./myapp
Hello World

потом когда надоест, но будешь понимать как это делать, перенести команды в скрипт

./build.sh
./myapp
Hello World

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

make release strip BUILDDIR=/tmp 
./myapp
Hello World

и только потом уже использовать средства IDE так как у тебя уже будет понимание того что в целом может пойти не так.

Да и начинать с простого, гораздо проще.

поддержу традиции LOR, на вопрос «как в СodeBlocks сделать что-то», отвечать «возьми CLion, Eclipse, командная строку рулит, пиши на Rust» :-)

вместо CodeBlocks тогда лучше уж его ближний родственник СodeLite - его хотя-бы активно пилят. CodeBlocks скорее мёртв и заброшен чем наоборот.

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

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

Другой файл не отображается в списке файлов проекта после сохранения проекта? В «другом файле» есть функция main?

Что пишет хоть?

clion, qtcreator

Зачем их использовать, если авторы этих продуктов не хотят, чтобы их использовали?

Есть qtcreator, который вполне может работать и с проектами на cmake

Может, но по возможностям не дотягивает.

Если сюда придут и начнут предлагать рукописный makefile, то не слушай этих луддитов.

1. А на сервере ты каким образом собирать исходники будешь? Закидываешь мэйкфайл, файлы исходников и собираешь под серверный процессор прямо на нем. Это удобно тем, что не требует установки различных зависимостей туда, где они излишни.

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

Тут тебе все CMake советуют, подумай 20 раз перед его заюзыванием. Шмэйк - это малоадекватный набор кривых костылей с чудовищной документацией. Лучше взять Meson, будет сильно приятней.

Meson проекты умеют поддерживать всякие IDE, ну там vscode, qtcreator, …, уровень поддержки - хз

cmake генерирует ninja файлы, ну или makefile для луддитов. Это штатный маршрут сборки. Не вижу проблем.

уровень поддержки - хз

Ключевой момент.

У meson могут быть проблемы переносимости, связанные с тем, что фичи новых версий, которые все так любят запихивать, не будут работать на системах 5летней давности.

На любителя всё, по мне так IDE - лишь на первое время, пока не осилится связка - условный vim + LSP. Некоторое время можно потерпеть какие-то шероховатости. Гораздо хуже взять cmake и страдать с ним. Я с ужасом вспоминаю, когда для проекта я генерил cmake модули для find_package(), казалось бы - тривиальная операция, но cmake умудрился сделать это максимально костыльно-через_зад, нелогичная и неинтуитивная цепь необходимых действий. Старые/новые стили, функции с миллионом параметров, документация к каждой из которых - бездарная портянка …

А ещё ужасно то, что cmake в самом начале начал «подмахивать» не юниксподобным FHS, пытаясь искать и устанавливать что-то в условный «Program Files». Нужно было признавать лишь юникс лайк layout (etc, lib, bin, …). Когда львиная доля софта на винде ставилась бы данные директории, то мелкомягким пришлось бы признать реальность и перестать велосипедить. Это как сделано в std::filesystem, это же калька с юниксовых прав доступа и тп, не нужно подстраиваться под всякий шлак. А имеем в сухом остатке - переусложненная система сборки с вагоном абстракций, и всё это из-за желания подмахивать мелкомягкой поделке

vim + LSP

Не дотягивает до CLion по фичам. А те что есть от сообщества, что часто приводит к низкому качеству. LSP постоянно отваливается.

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

Всё так. Но это стандарт. Нужно один раз на проект написать скелет, а потом только файлы исходников дописывать.

Ide тут не в почёте, используй вим + gcc + gdb + сам пиши make файл. Только так ты познаешь истину и станешь настоящим Программистом.

cmake генерирует ninja файлы, ну или makefile для луддитов. Это штатный маршрут сборки. Не вижу проблем.

Приходишь ты такой к своему подрядчику/смежнику/заказчику со своим поделием на внедрение. И тут выясняяется, что у людей на их вычислительных устройствах «Симейк», «Мезон», «Нинджа» не установлены. Будешь говорить: «Друзья, давайте установим ещё пятьсот мегабайт всякого хлама моей версии на ваши вычислительные устройства!». Пока ты будешь это делать, я уже получу свои денежки и прослушаю хвалебные песни о чудесной работе.

LSP постоянно отваливается.

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

Недавно решил опробовать вновь связку nvim + clangd, это стало вполне годным, ничего не падает, теперь меня всё устраивает, похоже, что детские болячки остались в прошлом

Не дотягивает до CLion по фичам

Например, что такого важного умеет Clion, чего нет в виме с лсп?

Тогда перейди в каталог с проектом и выложи выхлоп ls -lh. Будем плясать от этого

Тоже решение придумали через javaagent/ja-netfilter…

К слову, я этим микроскопом так научился пользоваться, что и микробов смотрю и гвозди забиваю)

Ну а если серьёзно: пока под все сценарии получалось его же средствами адаптировать разработку, а там и деплоймент и развёртывание кода, причём сильно удалённое: я Xilinx отлаживаю и гружу на другом континенте.

Но при этом хватает и косяков: не всегда видит символы. Причём если открыть все файлы, то, внезапно, начинает видеть. Иногда начинает ощутимо лагать на некоторых файлах, причём трудно временами воспроизвести минимальный пример, что бы репорт завести - это вот прям тоска и пичаль.

Но я и сижу на master ветке, сам раз-два в месяцок пересобираю из исходников. А там, если что и поправить что-то оперативно можно (на текущий момент 23 контрибута как автора и 21 как ревьювера /а вот репортов - полторы калеки/). И вот тут кроется как раз мякотка: исходники. В Clion хрен что ты сам сделаешь, даже при наличии желания и времени, а тут - можно.

Из прикольного, что раньше CLion они затащили редактирование переменных в кеше CMake (к слову… а JB затащили вообще? вроде даже VS сделали). Очень удобно, когда что-то нужно включить или выключить в конфиге сборки и сравнить поведение кода. На тот момент это умел только штатный cmake-gui.

В общем, теперь всё остальное тупо неудобное)

Подрядчику/смежнику/заказчику ты выдашь дистрибутив/appimage/shar-архив с интегированным скриптом развёртывания и инструкцию, как это устанавливать. А исходники будут бонусом, если договором это оговаривается и исходники пойдут тем, кто это будет сопровождать и править баги. Если же задача под конкретную платформу, то сделай deb/rpm/etc, что бы админы тебя матом потом не крыли.

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

В общем, если ко мне придёт чел, который вообще предложит что-то собирать на целевой машине, буду гнать ссаными тряпками. Мне нужны:

1. исходники с нормальной системой сборки, что бы на разных системах не лезть ручками и править пути к библиотеками. Makefile тут или будет сильно развесистым или костыльным. CMake как бы промстандарт по факту уже. Плюс теневая сборка из коробки (адепты чистого Makefile об этом забывают чуть менее, чем всегда)
2. инструкция, как строить код, возможно, используя кросс-сборку
3. инструкция, как собирать дистрибутив, возможно, используя возможности виртуализации/контейнеризации. Как вариант, сборка deb/rpm/etc - как где почему
4. инструкция, как развёртывать, как настраивать + файлы дистрибутива

1-3 - разработчикам/сопровождающим - опционально, если оговорено договором. 4 - интеграторам/админам