Комментарии 22
вообще еще можно пойти другим путём, написать наверно плагин для какого-то компилятора(наверно кланг), скармливать ему только main - file(построение Tree проекта), суть концепции в том, что от мейн файла плагин(или интегрированная новая концепция сборки от 1 файла при помощи возможностей LLVM-clang базы) должен собрать сам екзешник) и точно так же с библиотеками, соответственно приходим к ужатию количества файлов, которые идут на вход компилятора
Проблематика - не все программисты хотят этим заниматься - типо итак кодить, а тут еще компилятор писать
Позволю себе позанудствовать по поводу двух моментов.
Во-первых, очень похоже, что таки системой сборки у вас является make, а не ваш LightForge. LightForge генерирует Makefiles, а уже сам make занимается проверкой того, что нужно собрать, запуском компилятора/линкера и т.д. Так что и LightForge, и CMake более правильно было бы относить не к системам сборки (так как никто из вас собирать, собственно, и не умеет), а к системам генерации описаний для систем сборки.
Понятно, что здесь речь о терминах, но все таки было бы правильно отделять make/nmake/ninja и им подобное от паразитирующих над ними надстроек по типу CMake.
Во-вторых, то, что вы декларируете как достоинство, а именно "Не требует изучать отдельный язык, как CMake", для чего-то более более серьезного, чем HelloWorld, превращается в недостаток. Потому что даже для небольшого кросс-платформенного проекта в описании проекта очень быстро появляются if-ы для проверки разных условий (типа версия компилятора такая-то, версия сторонней библиотеки такая-то, дополнительные ключики для компиляции, которые нужны на время дополнительных проверок, такие-то и т.д., и т.п.). И тут уж какое-то подобие языка программирования неизбежно. Говорю вам как человек, который сам сделал несколько версий системы сборки для C++, и который в итоге пришел к выводу, что в мире C и C++, описывать проект таки нужно на каком-то ЯП. Хотелось бы не на таком ущербном, как в CMake, но все-таки.
А вообще по самой статье хочется сказать: написано много, какие-то скриншоты даже приведены, но нормального понимания того что же из себя представляет ваш велосипед и как им пользоваться, увы, не складывается :(
PS. И да, здесь очень уместна была бы ссылка на комикс про 15 конкурирующих стандартов.
1) LightForge -- система сборки, make -- её составная часть. Для сравнения, то что make использует bash для запуска команд не делает make паразитом над bash.
2) LightForge не паразитирует, он решает проблемы сборки и позволяет работать с комфортом.
3) LightForge позволяет собирать сложные проекты, гораздо сложнее, чем HelloWord. При этом приходится прилагать минимальные усилия. Так что свою миссию LightForge выполняет.
CMake нечитаемый и тяжело поддерживаемый. Bazel вообще мало кто знает, дикая экзотика, встречал пару раз буквально. Make - тоже нечитаем, но хотя бы не приносит абстракций и прост как палка, его можно генерить условным питоновым скриптом, если размеры перерстают за одну-две экранные страницы не считая шаблонного кода.
А так, универсального простого пакетного менеджера и сборщика для С/С++ не думаю что дождемся, всё очень завязано на разные дистрибутивы, раные ОС, архитектуры... Либо выйдет огромный тентаклевый монстр, от которого все бегать будут.
Cmake нечитаемый? Тогда и с++ нечитаемый уж точно
Cmake нечитаемый?
Местами чуть более чем нечитаемый:
set(prop "$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>")
add_custom_target(run_some_tool
COMMAND some_tool "$<$<BOOL:${prop}>:-I$<JOIN:${prop},;-I>>"
COMMAND_EXPAND_LISTS
VERBATIM
)
target_compile_definitions(myapp
PRIVATE $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:AppleClang,Clang>>:COMPILING_CXX_WITH_CLANG>
$<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:Intel>>:COMPILING_CXX_WITH_INTEL>
$<$<AND:$<COMPILE_LANGUAGE:C>,$<C_COMPILER_ID:Clang>>:COMPILING_C_WITH_CLANG>
)
Примеры из официальной документации если что.
Тогда и с++ нечитаемый уж точно
Пока что C++ еще более читаемый, чем CMake. Но вот скоро в него рефлексию привезут с рептилоидным синтаксисом...
условно на С++ сейчас ант, а надо просто запилить мавен, и какую парсилку в пом, суть не в том, что скопировать нужно, суть в том, что мы перечисляем в сборке то, что можно построить в дерево, и да я думаю с деревом проекта указать какая система или где библиотека не составит труда, еще раз, на нулевом уровне мы просто компилятору скармливаем файлики, которые можно было пропарсить в иерархию и красиво сделать через файл точки входа
если вы наблюдали за стажией компиляции, там на какой-то стадии одна портянка 1 файлового кода, вот это оно самое нам и нужно, и это можно получить зная файл точки входа поидее, это сердце компилятора поидее
файлик test.my_lang
---------------------
lib testLIB.my_lang //<include или тут сразу включаем
int main(){ //< main
int i=1;//<1
int a=0;//<2
int b=1;//<3
int c=2;//<4
testL=init();//<оп включаем
while(i<10000000){
//print(i);
i++;
}
//print(i);
print(4);
return 0;
}
А так, универсального простого пакетного менеджера и сборщика для С/С++ не думаю что дождемся,
А ведь был qbs....
Вот! надкусанному яблоку нужно было куда-то впереть свой продукт...
...недальновидно изучать еще одни язык для конвертации в маке-файлы
Непопулярное мнение, но выскажусь... Autotools - единственно стоящая вещь! при минимальных временных затратах можно "войти в тему", а, имея определенных запас скриптового программирования, можно "наворотить" много чего просто и читабельно...
$(OBJ_PATH)/CmdInput.o :../../../../../C++/CCore-5-xx/Target/../Applied/CCore/src/CmdInput.cpp CC-opt.txt $(CC) $(CCOPT) @CC-opt.txt $< -o $@
Вы хотя бы сократите путь к исходному файлу и все будет выглядет ясно и понятно:
$(OBJ_PATH)/CmdInput.o : $(SRC_PATH)/CmdInput.cpp CC-opt.txt
$(CC) $(CCOPT) @CC-opt.txt $< -o $@Цель (файл) CmdInput.o зависит от двух файлов: CmdInput.cpp и CC-opt.txt. Чтобы достичь цели, т.е. получить обьектный файл CmdInput.o, необходимо исполнить команду из переменной $(CC), в которой содержится путь к компилятору, с параметрами в переменной $(CCOPT) и плюс дополнительных параметров формируемых из автоматических переменных $< и $@. Переменная $< содержит первый файл из зависимости, а $@ - файл-цель. Это вобщем-то все, что требуется знать про утилиту Make. А, нет, не всё. Нужно еще знать, что команды сборки начинаются с символа TAB (\t) - см. вторую строку. Но последнее не обязательно для BSD make. :-)
Настоящие make-файлы, особенно в реальных проектах, достигают сотен и тысяч строк.
Это совершенно не так! Хороший Makefile весьма лаконичен и содержит всего пару десяток строк, при этом может собирать проекты из сотни тысяч файлов с вызовом препроцессоров, лексических анализаторов и прочего. То, что Вы имеете в виду под Makefile-ом это скорее всего результа работы надстройки - какого нибудь CMake или AutoGen (./configure), который на выходе и создает такие гигантские Makefile-ы не пригодные для прочтения человеком. Make - отличная система сборки проверенная десятками лет. А эти ваши CMake, Bazel, Ninja и прочее - настоящая дрянь усложняющая жизнь разработчику.
NOB - No Build system. Эта система сборки содержит один единственный заголовочный файл nob.h, в нем содежится ряд примитивов из которых разработчик складывает себе систему сборки которая собирает весь проект. Очень рекомендую для небольших проектов.
С++ необходимо ввести мораторий на создание новых "систем сборки".
Вы же в курсе, что CC в нормальной ситуации это компилятор С, а не С++, который обычно CXX обозначают.
Ну и судя по куче переходов по папкам через .. кто-то опредённо не умеет пользоваться системами сборки.
В качестве бенчмарка/челленжа предложил бы вам собрать какой-нибудь grpc или google test при помощи этой штуки.
Есть ли какая-то интеграция с IDE? Допустим я в работе использую IDE Qt, и чтобы открыть проект, который использует cmake, я открываю CMakeLists.txt и у меня загружается проект (иногда надо еще какие-то переменные указать, чтобы он сконфигурировался). Тут также сработает? Если нет, то как предлагается писать код?
Ааааа, mcedit! Я думал нас уже не осталось.
Предлашаю ознакомится с meson. Возможности сопоставимые с cmake, но с более приятным синтаксисом и дебагом. Изобретение своего аналога autotools считаю немотивированным. Удачи в поддержке С++20 modules
Вот! про смаке.... надкусанному яблоку нужно было куда-то впереть свой продукт...
...недальновидно изучать еще одни язык для конвертации в маке-файлы
Непопулярное мнение, но выскажусь... Autotools - единственно стоящая вещь! при минимальных временных затратах можно "войти в тему", а, имея определенных запас скриптового программирования, можно "наворотить" много чего просто и читабельно...
Как упростить сборку на С++: мой open source-проект LightForge