Иногда возникает ситуация, когда надо что‑то посчитать согласно сложному алгоритму прямо на LapTop/NetTop/DeskTop PC. При этом этот алгоритм написан на Си. Это может быть цифровой фильтр, дискретное преобразование Фурье, генератор QR кода, кусок линейной алгебры с векторами, какое‑то тригонометрическое вычисление, программный модулятор, статистическая обработка случайной величины. Да всё, что угодно! То есть Вы хотите использовать язык Си как гибкий и быстрый калькулятор в Windows. Тут надо написать программу на Си.
Компьютер — это универсальный вычислитель
Или, например, Вы программируете микроконтроллеры на Си и хотите сделать симулятор прошивки в виде консольного приложения. Надо вам, например, прогнать модульные тесты платформа‑независимого кода на «большом компьютере». Потом Вам 80% вероятность, что понадобится конфигуратор прошивки по UART. Потом Вам понадобится консольное приложение Loader для загрузки по UART самой прошивки через BootLoader.
Потом понадобится крохотная PC‑утилита синхронизации для часов реального времени с PC.
Почему именно Си?
Эту LapTop утилиту стоит писать на том же языке, что и прошивку хотя бы по той причине, что можно пере использовать кодовую базу из микроконтроллеров для программирования на DeskTop(е).
Дело в том что язык программирования Си — это самый простой язык программирования из тех, что всё еще более или менее используется в промышленной разработке. По факту в Си только функции и переменные. Тут нет никаких виртуальных функций, шаблонов, делегатов и прочих концепций. В Си всё предельно просто и конкретно.
Разработка под PC это не сross компиляция, как в случае со сборкой артефактов для микроконтроллера, и тут в PC всё в какой‑то степени проще. При сборке Си приложения не надо думать о файле конфигурации компоновщика, как мы это привыкли делать для cross компиляции артефактов для микроконтроллеров (файлы *.ld).
Сперва определимся для какого Target(а) надо собрать бинарь. Надо узнать какой у нас на материнской плате установлен микропроцессор. Такую информацию может показать утилита CPUZ.
В данном случае у меня на одном компьютере Intel Celeron J4125 2Ghz, 4x cores, L1 32kByte, L2 4MByte, 10W. На другом компьютере установлен 64 разрядный микропроцессор AMD Ryzen 5 PRO 3400GE 3.30 GHz.
Но это даже не так важно. Важно какой у нас Instruction Set. В данном случае — x86–64. Это значит, что у нас 64-битный процессор. Получается, что у нас есть выбор: либо ставить 64-битный компилятор Си, либо накатывать 32-битный компилятор Си.
Как правило, нам приходится работать на разных процессорах, однако мы в OS Windows этого даже не замечаем.
Units: |
text |
bit |
N |
N |
kByte |
kByte |
MByte |
№ |
Процессор |
bitness |
cores |
Threads |
L1 |
L2 |
L3 |
1 |
AMD Ryzen 5 PRO 3400GE |
64 |
4 |
8 |
32 |
512 |
4 |
2 |
Intel Celeron J4125 |
4 |
4 |
32 |
|||
3 |
Intel Core i7 8550U |
64 |
4 |
8 |
32 |
256 |
8 |
Одновременно с этим наш имитатор прошивки должен собираться и запускаться на всех окружениях настольных компьютеров: на работе, дома, в гараже.
Как и в любом деле сначала надо определится с терминологией.
Терминология
Компилятор — программа, переводящая написанный на языке программирования читаемый понятный человеком текст, в набор машинных кодов (человеко‑нечитаемый бинарный код). Программисты это люди, которые как никто приближены к абстракциям. Любой язык программирования, в частности Си — это уровень на коротком можно не думать о наборе команд данного микропроцессора. У процессора нет никаких переменных и функций. Переменные существуют только в сознании программиста. Поэтому нам нужен компилятор Си. Компилятор для каждого Cи файлика производит *.o файлик с родным для данного процессора машинным кодом.
Компоновщик (Linker)— утилита, которая склеивает бинарные файлы *.o в один монолитный исполняемый бинарный файл программы. В нашем случае это *.exe.
Артефакт — результат работы ToolChain(а). В нашем случае это *.exe файл с бинарным файлом программы.
Что надо из софтвера?
Текстовый редактор (Text Editor)
Прежде всего нужен какой‑то текстовый редактор, чтобы написать этот самый исходный текст программы на Си. Тут вариантов масса. NotePad++, Eclipse, MS VS Code.
Сборщик (Build Tools)
В компьютерах ничего само собой не происходит. Компьютеры - это самые ленивые и безынициативные сущности. Им всё надо объяснять максимально подробно и понятно. Поэтому надо явно указать из каких *.с файлов мы хотим собирать программу. Эти файлы надо как-то перечислить проиндексировать. Для этого была создана специальная утилита называемая make. Идея проста. Создается текстовый файл (Makefile) и в нем прописывается правильная последовательность вызова консольных утилит, которая приведет к тому, что на жестком диске появится исполняемый файл с программой.
Препроцессор (Preprocessor)
Это такая консольная утилита (cpp.exe), которая вставляет и заменяет куски текста. Нужна чисто ради удобства написание текста. Препроцессор позволяет полностью исключить такое нехорошее явление как дублирование программного кода. При этом препроцессору абсолютно всё равно с каким языком программирования работать (Cи, C++, DeviceTree, Graphviz, скрипты компоновки и т. п.). Для препроцессора любой язык программирования - это просто текст.
Теперь рассмотрим практические аспекты.
Какой выбрать компилятор Си кода?
Тут есть несколько бесплатных вариантов на выбор.
№ |
Компилятор |
разрядность генерируемого кода |
1 |
СygWin |
64 |
2 |
MinGW |
32 |
3 |
Mingw-w64 |
64 |
4 |
clang |
64 |
5 |
Tiny C Compiler |
32/64 |
Для программистов микроконтроллеров я настоятельно рекомендую выбрать именно MinGW. Дело в том, что MinGW генерирует 32-битный код. Это как раз соответствует тому, что большинство микроконтроллеров (например ARM Cortex Mx) как раз 32-битные. И Вы так достигните большей совместимости между кодом прошивки микроконтроллера и консольным приложением в Windows.
Вторая причина по которой надо использовать компилятор C:\MinGW\bin\gcc.exe заключается в том, что в окружении MinGW есть заголовочный файл conio.h, который определяет функцию kbhit(). Это нам понадобится для имитации на PC текстового терминала UART-CLI консоли в stdout/stdin.
>C:\MinGW\bin\gcc.exe --version
gcc.exe (MinGW.org GCC-6.3.0-1) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Набор утилит MinGW преспокойно скачивается и устанавливается как любая другая программа под OS Windows.
Компоновщик (Linker)
Компоновкой занимается утилита ld, которая вызывает collect2. Именно утилита collect2.exe будет выдавать ошибки, если Вы будите вызывать функции без определения их тела.
Что вообще надо из софтвера?
Вот минимальный джентельменский набор для того чтобы собрать программу на Си.
№ |
Назначение утилиты |
Название утилиты |
1 |
Текстовый редактор |
NotePad++.exe |
2 |
Препроцессор |
cpp.exe |
3 |
Компилятор |
gcc.exe |
4 |
Консольная утилита для удаления файлов или папок |
rm |
5 |
Компоновщик |
ld.exe |
6 |
Утилита управления ToolChain(ом). Она решает что и в какой последовательности собирать, чтобы получить артефакты |
make.exe |
7 |
Утилита анализа получившегося бинаря. Аналог readelf.exe из мира программирования микроконтроллеров |
PE explore.exe |
Традиционно программы на Си собирают из make скриптов. Вот минималистический makefile для сборки много файлового Си‑проекта на Windows
MK_PATH:=$(dir $(realpath $(lastword $(MAKEFILE_LIST))))
#@echo $(error MK_PATH=$(MK_PATH))
INCDIR += -I$(MK_PATH)
WORKSPACE_LOC:= $(MK_PATH)../../
$(info WORKSPACE_LOC= $(WORKSPACE_LOC))
INCDIR += -I$(WORKSPACE_LOC)
BUILDDIR := $(MK_PATH)/Build
SRC_PATH := $(dir $(abspath $(dir $$PWD) ))
#@echo $(error SRC_PATH=$(SRC_PATH))
OBJDIR := $(SRC_PATH)obj
# the compiler to use
OPT += -DHAS_GCC
CC = C:\MinGW\bin\gcc.exe
# compiler flags:
# -g adds debugging information to the executable file
# -Wall turns on most, but not all, compiler warnings
CFLAGS += -g
#Generate code for 32-bit ABI
CFLAGS += -m32
CFLAGS += -std=c11 -fshort-enums
#CFLAGS += -Og
CFLAGS += -O0
#CFLAGS += -Wall
#CFLAGS +=-pedantic
#CFLAGS += -ftime-report
#files to link:
LFLAGS += -static
#LFLAGS += -lm
EXECUTABLE=firmware_simulator_x86_m
include $(MK_PATH)config.mk
ifeq ($(CLI),Y)
include $(MK_PATH)cli_config.mk
endif
ifeq ($(UNIT_TEST),Y)
include $(MK_PATH)test_config.mk
endif
ifeq ($(UNIT_TEST),Y)
include $(MK_PATH)diag_config.mk
endif
include $(WORKSPACE_LOC)code_base.mk
#@echo $(error SOURCES_C= $(SOURCES_C))
INCDIR := $(subst /cygdrive/c/,C:/, $(INCDIR))
#@echo $(error INCDIR= $(INCDIR))
OBJ := $(patsubst %.c, %.o, $(SOURCES_C))
OBJ := $(subst /cygdrive/c/,C:/, $(OBJ))
#@echo $(error OBJ= $(OBJ))
.PHONY:all
all:$(OBJ) $(EXECUTABLE)
$(EXECUTABLE): $(OBJ)
$(CC) $(CFLAGS) $(OBJ) $(LFLAGS) -o $(EXECUTABLE).exe
%.o: %.c
$(CC) $(CFLAGS) $(INCDIR) $(OPT) -c $< -o $@
clean:
rm -r $(EXECUTABLE) $(OBJ)
Тут файлы config.mk, cli_config.mk, test_config.mk и diag_config.mk это просто файлы с перечислением набора переменных окружения для выборочной сборки конкретных исходников из общей кодовой базы. Вот корневой makefile для подключения разных программных компонентов code_base.mk
ifneq ($(CODE_BASE_MK),Y)
CODE_BASE_MK=Y
$(info CodeBase Config)
#@echo $(error WORKSPACE_LOC=$(WORKSPACE_LOC))
INCDIR += -I$(WORKSPACE_LOC)
ifeq ($(THIRD_PARTY),Y)
include $(WORKSPACE_LOC)/third_party/third_party.mk
endif
ifeq ($(APPLICATIONS),Y)
include $(WORKSPACE_LOC)/applications/applications.mk
endif
ifeq ($(CONNECTIVITY),Y)
include $(WORKSPACE_LOC)/connectivity/connectivity.mk
endif
ifeq ($(CONTROL),Y)
include $(WORKSPACE_LOC)/control/control.mk
endif
ifeq ($(COMPUTING),Y)
#@echo $(error COMPUTING=$(COMPUTING))
include $(WORKSPACE_LOC)/computing/computing.mk
endif
ifeq ($(SENSITIVITY),Y)
#@echo $(error SENSITIVITY=$(SENSITIVITY))
include $(WORKSPACE_LOC)/sensitivity/sensitivity.mk
endif
ifeq ($(STORAGE),Y)
#@echo $(error STORAGE=$(STORAGE))
include $(WORKSPACE_LOC)/storage/storage.mk
endif
ifeq ($(UNIT_TEST),Y)
include $(WORKSPACE_LOC)/unit_tests/unit_test.mk
endif
endif
Конечный make файл может выглядеть например так. Вот тут и индексируют конечные *.c файлы и определяют ключевые слова для препроцессора (начинаются на HAS_XXXXX).
$(info SCHMITT_TRIGGER_MK_INC=$(SCHMITT_TRIGGER_MK_INC))
ifneq ($(SCHMITT_TRIGGER_MK_INC),Y)
SCHMITT_TRIGGER_MK_INC=Y
mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
$(info Build $(mkfile_path) )
SCHMITT_TRIGGER_DIR = $(COMPUTING_DIR)/schmitt_trigger
INCDIR += -I$(SCHMITT_TRIGGER_DIR)
SOURCES_C += $(SCHMITT_TRIGGER_DIR)/schmitt_trigger.c
SCHMITT_TRIGGER=Y
OPT += -DHAS_SCHMITT_TRIGGER
ifeq ($(DIAG),Y)
OPT += -DHAS_SCHMITT_TRIGGER_DIAG
SOURCES_C += $(SCHMITT_TRIGGER_DIR)/schmitt_trigger_diag.c
endif
ifeq ($(CLI),Y)
ifeq ($(SCHMITT_TRIGGER_COMMANDS),Y)
OPT += -DHAS_SCHMITT_TRIGGER_COMMANDS
SOURCES_C += $(SCHMITT_TRIGGER_DIR)/schmitt_trigger_commands.c
endif
endif
endif
Если говорить метафорично, то Make - это как механическая коробка передач, только для сборки программ. C Make Вы можете буквально контролировать каждую опцию компилятора.
При первой сборке проекта скорее всего выскочит вот эта ошибка. Это значит, что надо переустановить MinGW.
C:\Users\username\AppData\Local\Temp\ccT9XWou.s:54: Error: invalid instruction suffix for `push'
C:\Users\username\AppData\Local\Temp\ccfvWBon.s:19: Error: invalid instruction suffix for `pop'
Надо чтобы команда gcc.exe -dumpmachine после установки показывала mingw32
>C:\MinGW\bin\gcc.exe -dumpmachine
mingw32
Содержимое того Makefile можно представить в виде вот этой простенькой блок схемы ToolChain(а). Тут можно визуально проследить какой путь проходит *.с файл с момента написания до исполнения в Windows.
В остальном сборка на PC не отличается от сборки для микроконтроллера. В этом и достоинство сборки из Make. При работе с make cборка под любые процессоры выглядит плюс/минус одинаково. Просто по другому определенные переменные окружения: CC LD и т. п. Все те же *.mk файлы подтянутся что и в кодовой базе для прошивок.
Про то как происходит сборка прошивок из-под скриптов можно почитать в этом тексте:
Настройка ToolChain(а) для Win10+GCC+С+Makefile+ARM Cortex-Mx+GDB.
Когда собралась вся кодовая база бинарь получился всего 1,9MByte
Отладка имитатора прошивки
Артефактом сборки является файл *.exe. Его можно запустить вызвав его из командной строки cmd.
Тут происходит имитация UART-CLI терминала только вместо UART выступают файлы stdin (аналог UART-RX)/stdout (аналог UART-TX).
Можно заметить, что скорость исполнения приложения просто бешеная. За одну секунду супер-цикл успевает прокрутиться аж 11 240 590 раз! В микроконтроллерах это значение обычно было порядка 7588 раз.
Получается, что на PC приложение исполняется быстрее в 1481 раз. На три порядка быстрее!
Вывод
Сборка кода на Cи для DeskTop это весьма полезный навык при отладке микроконтроллерных прошивок. Можно отладить огромные куски платформа независимого кода: CRC, обработку строчек, триггер Шмитта, бинарные протоколы, и т.п.
Также можно собрать проект разными компиляторами: GCC, Clang. И тем самым найти и устранить больше ошибок в кодовой базе.
Как видите, в сборке Си программ на PC, ровным счетом, нет ничего сложного. Надеюсь этот текст поможет большему количеству программистов-микроконтроллеров отлаживать свои приложения на DeskTop PC и создавать, тем самым, отличные программные продукты.
Links
Компилятор GCC. Первая программа на Windows
EclipseIDE.Установка, настройка, программирование на С/Installation, configuration, programming in C
Eclipse и MinGW: как указать IDE путь к makefile и файлам проекта; разделение mingw32-make и ключей
MinGW - Minimalist GNU for Windows
Генерация зависимостей внутри программы
Сборка firmware для CC2652 из Makefile
Почему Важно Собирать Код из Скриптов
Настройка ToolChain(а) для Win10+GCC+С+Makefile+ARM Cortex-Mx+GDB
Tiny C Compiler - Summary https://savannah.nongnu.org/projects/tinycc
The LLVM Compiler Infrastructure https://llvm.org/
Вопросы
Какой путь проходит с файл с момента написания до момента исполнения?
Что происходит между нажатием на Enter при запуске консольной утилиты в cmd и запуском функции main()?
Комментарии (49)
codecity
11.12.2023 21:58А почему не использовать CMake?
aabzel Автор
11.12.2023 21:58Make как-то ближе к физике процесса.
После микроконтроллеров осталась привычка к Low Level.Sazonov
11.12.2023 21:58Что вы подразумеваете под low level в системах сборки? Low level код это понятно.
aabzel Автор
11.12.2023 21:58CMake при определенной настройке генерит make скрипты.
CMake это по сути надстройка над make.
Вот и получается что make - low level; CMake - hi level.Sazonov
11.12.2023 21:58Вы фантазируете. Cmake это не надстройка на make. Make это лишь из один возможных форматов выхлопа. Make не используется самим Cmake, это опция. Это как сказать что велосипед это бэкэнд велозавода.
awoland
11.12.2023 21:58cmake на основе собственных описаний (CmakeList.txt) генерирует целевой проектный файл. Может по заказу сгенерировать GNU Makefile или Microsoft NMake Makefile. Может Visual Studio Solution или Apple Xcode projects... Далее полученый проект обрабатывается соостветствующим билдером. В случае GNU Makefile будет нужен GNU make. Make не используется самим cmake, но для дальнейшей сборки с использованием Makefile он необходим. Получается в пайплайне сборки cmake является конвейерной надстройкой над make.
Sazonov
11.12.2023 21:58Ну как бы логично что если вы хотите использовать make, то вам нужен Makefile. Только как это относится к CMake?
aabzel Автор
11.12.2023 21:58Make дает больший контроль над ситуацией.
Make - это как механическая коробка передач, a CMake - автомат.
Wolf4D
11.12.2023 21:58Не очень понял смысл статьи. Это литературный эксперимент?
Ведь обучение Си обычно и начинается с того, что начинающий программист сначала пишет свои первые программы в простой "песочнице" PC, где ни о каких ограничениях платформы можно не думать. И когда он наберёт опыта работы с МК - он тем более будет знать простые вещи типа "как скомпилировать свой код". В итоге статья читается как высоконаучное описание "как ковырять в носу для чайников, на примере поз из йоги, базовая теория и основные подходы" :)
В статье звучал и другой мотив - перенос кода с МК на ПК. Вот про это я бы почитал с удовольствием. Ведь там так много проблем - имитация неидеальности поступления данных от периферии, ERRATA контроллера, отличающиеся типы данных, точность и скорость операций...
Знаю случай, когда на МК и на ПК на том же коде отличались некоторые результаты операций деления. С имитацией этого народ знатно помучился.
kipar
11.12.2023 21:58Забавно, я на Си первые программы как раз для микроконтроллеров писал, потому что на работе решили МК заняться. Для програмирования на компе у меня дельфи был.
Счас мне правда статья уже бесполезна, т.к. mingw-w64 уже себе настроил.
Rusrst
11.12.2023 21:58Ну это прям максимально странно, если честно. Потому что изучать си на МК, это то ещё занятие...
aabzel Автор
11.12.2023 21:58Ничего странного.
Cи как язык программирования кроме микроконтроллеров больше никому, по большому счету, и не нужен!
Более того всё чаще и чаще для программирования MCUшек применяют уже С++ .Rusrst
11.12.2023 21:58Безотносительно нужности его на ПК (о чем тоже можно поспорить на самом деле) программирование под МК имеет кучу особенностей. И чтобы собрать хоть как-то рабочий код (который не будет черным ящиком как Ардуино, а действительно обучающим примером) надо неплохо так поразбираться во внутрянке (один header файл регистров будет тем ещё приключением). Это банально не самый удобный инструмент просто. Поэтому и учить на МК странно.
kipar
11.12.2023 21:58Надо было запилить проект на МК. Опытный советчик сказал - ну вам год надо архитектуру арм сначала изучать, но мы его не послушали. На чем его можно программировать - на ассемблере и на си. Ассемблер изучать долго, а нам надо проект делать. Значит си. Я про него что-то слышал в детстве, о вот и книжка Кернигана нашлась, почитал и погнали. Больше всего проблем было с тем чтобы Ethernet поднять (на отладочной плате и соответственно работающем примере был один чип phy, а на той что мы запилили - другой), а си - ну язык как язык, что-то похуже чем в дельфи что-то получше.
aabzel Автор
11.12.2023 21:58Для запуска TCP IP на микроконтроллере надо подключить код, который называется LwIP.
kipar
11.12.2023 21:58это да. Правда в тот раз я uIP использовал (более легковесная версия от того же автора). Проблема была с более низким уровнем - инициализацией PHY. Там надо подключиться к чипу и установить mac адрес для фильтрации пакетов, ну и у этих чипов слегка различался протокол.
aabzel Автор
11.12.2023 21:58Проблема была с более низким уровнем - инициализацией PHY.
Написать драйвер для MDIO чипа это хорошо формализованная задача.
Вот даже методичка есть.
https://habr.com/ru/articles/683762/kipar
11.12.2023 21:58я на си то второй раз в жизни писал, какие еще драйвера. Был рабочий пример, причем казалось что он и на этом чипе работал (просто задание мак адреса втихую не работало и он оставался дефолтный). Проблемы начинались когда два девайса в одну сеть подключали. Решилось парой дефайнов (PHY_ADDRESS и что-то там еще, дело было лет 15 назад).
kovserg
11.12.2023 21:58Иногда возникает ситуация, когда надо что-то посчитать согласно сложному алгоритму прямо на LapTop/NetTop/DeskTop PC
Есть же простой вариант:
C: tcc + st
VHDL: ghdl + gtkwave + make + stps: для дифов meld и beyond compare
aabzel Автор
11.12.2023 21:58
1--Tiny C Compiler не может собрать эту функцию2--TCC не видит #include <complex.h>
3--TCC ругается на определение типа внутри for
for(uint8_t bit = 0U; bit <= 7U; bit++) { }
4-- TCC не знает макроса
__TIMESTAMP__
5-- tcc: undefined symbol 'strlen' 'snprintf' 'fprintf' 'strdup' 'memcpy' 'free' 'calloc' 'write' 'memset' 'malloc' '__imp__iob' 'exit' 'tolower' 'strchr' '__mb_cur_max' '_pctype' '_isctype' 'srand' 'rand' 'qsort' 'strcpy' 'printf' 'strcasecmp' 'fabs' 'strncpy' 'sprintf' 'kbhit' '_getch' 'strcmp' 'fopen' 'fclose' 'abs' 'system' '_GetStdHandle@4' '_GetConsoleMode@8' '_SetConsoleMode@8' 'time' 'pow' 'sin' 'cos' 'sqrt' 'atan2' 'fmodf' 'fmod' 'acos' 'atan' 'strstr' '__fpclassifyf' 'memmove' 'strspn' 'strcspn' 'toupper' 'fgets' 'localtime' 'mktime' 'difftime' 'ftime' 'asctime' 'clock' 'gmtime' 'getc' 'fseek' 'ftell' 'fread' 'strncmp' 'memcmp' 'sscanf' '__imp__HUGE' 'putchar' 'puts' 'fabsf' 'fmaxf' 'fmax' '_controlfp' '__set_app_type' '__getmainargs'
aabzel Автор
11.12.2023 21:58Что-то компилятор TCC не может собрать даже math.h
C:/tcc/include/math.h:217: error: unknown constraint 't'kovserg
11.12.2023 21:58не используйте static при определение параметров: static void s20_rowround(int y[16]);
да complex.h у него нет. но это не мешает проводить любые вычисления.
у меня не ругается
да такого макроса у него нет. (вам никто не мешает его определить в параметрах при компиляции)
такое тоже не воспоизводится
-
да там хедеры от gcc. Если вы будете испольтовать fabs то всё работает. Но если всё же хочется fabsf, fabsl и т.п. поменяйте в хедере "=t" на "=r" и оно заработает.
gdt
11.12.2023 21:58По-моему Visual Studio имеет community edition и в ней можно писать в том числе и на C.
kovserg
11.12.2023 21:58Конечно умеет. Но на флешке таскать visual studio как-то не очень. Да и проще нажать ctrl+b и сразу увидить результат, чем колупаться с настройками проекта в gui.
Wolf4D
11.12.2023 21:58На флешке можно таскать портабельную сборку Qt Creator с MinGW, GDB, CMake и Qt 5. Я так и делаю, воткнулся, скопировался - и за 5 минут у тебя готова среда для разработки несложных приложений.
Polarisru
11.12.2023 21:58А почему нельзя взять Codeblocks, где все это работает из коробки, причем под Linux выглядит точно так же?
aabzel Автор
11.12.2023 21:58Хороший вопрос!
Codeblocks - это IDE.
Отсюда все проблемы связанные с IDE.
Прежде всего это бесконечное дублирование конфигов для разных сборок в IDEшной xml.
Подробнее про это тут
https://habr.com/ru/articles/723054/
GBR-613
11.12.2023 21:58Нормальный IDE это возможность нормального дебаггирования. Неужели ради этого не стоит сконфигурировать GUI?
aabzel Автор
11.12.2023 21:58Пошаговую отладку кода можно и из консоли делать.
Вот методичка для микроконтроллерных прошивок https://habr.com/ru/articles/694708/
Для PC консольный GDB еще проще.
Pitkin_zadov
11.12.2023 21:58По моему у автора "заскок" на Make. У него все статьи этому посвящены.
Автор, да все кто в теме, знают как, когда и чем лучше. Ваше навязывание "мейка" кажется уж слишком назойливым.
Открываешь вроде интересную статью (по названию), а там опять "мейк".
IlyaDatsiuk
Проще установить unix подобную систему и писать программы на С под неё. (Моё мнение))
aabzel Автор
В Linux я не находил нормальной утилиты для сравнения текстовых файлов, которая по удобству хотя бы близко могла приблизится к WinMerge.exe.
lorc
meld?
Gumanoid
vimdiff
?aabzel Автор
vimdiff - самый худший diff tool, который я когда-либо видел
Gumanoid
Вроде всё наглядно и удобно. Только цветовую тему я бы сменил на менее кислотную, типа:
SpiderEkb
В Linux у вас уже будет "нативный" gcc.
Вы можете поставить любую IDE - хоть VSCode, хоть CodeBlocks, хоть CodeLite (тут, кстати, вам не придется писать make файлы - оно само это будет за вас делать - просто создаете и конфигурируете проект - достаточно компактная и удобная среда для небольших проектов, под винду, кстати, тоже есть).
И аналог WinMerge тут, как правильно заметили, есть - Meld.
В качестве файлового менеджера - привычный по винде DoubleCommander.
ncpuma
kdiff3?