Чем лучше всего собирать Pure C проекты?

Много модулей уже устарели, да. SDL2 в официальной поставке недавно появился.

В этом плане их хотя бы нагуглить несложно. А если и нужно особо, быстро накидать обёртку над pkg-config.

А если и нужно особо, быстро накидать обёртку над pkg-config.

Там есть уже: find_package(PkgConfig REQUIRED).

mk и 9c уже называли? plan9port есть практически везде, почему бы не воспользоваться хорошими инструментами?

Но мне надо просто собрать проект, а не чистить какие-то кэши и не читатьсотни килобайт доков по cmake

Где-то достаточно. Но когда в проекте много модулей, один бинарник, другой shared либа, третий static, этого явно не хватает.

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

Зачем тебе glList? Тебе же надо

все делается в 2 строчки

Если приемлешь больше 2 линий, проблем с освоением VAO возникнуть не должно. Вот тут найдёшь инфу по основам современного ogl: http://www.gamedev.ru/code/forum/?id=138435

Если захочу возьму math_3d.h

Так возьми. Но ты взял glRotate. Ведь это именно то, чем должен заниматься драйвер видеокарты — вертеть пространство. На cpu.

Make и autotools приведёт к необходимости держать отдельный проект для visual studio

Ну меня тут вообще уверяли, что если поставить cygwin, то и в винде с автотулзами всё будет прекрасно. Но сам не проверял.

А по теме - cmake. У него ужасные синтаксис и верифицируемость (по сути дела, это скриптовый движок, на котором можно писать В ТОМ ЧИСЛЕ сборочные скрипты), но при этом мощнее и универсальнее его ничего нет. Так что учи cmake.

По идее, здесь должен появиться новый Линус Торвальдс, которые посмотрит на существующие системы сборки, скажет «да вы тут все охренели» и за выходные напишет свою, удобную и вменяемую. Но пока такого не произошло, и попытки сделать вместо 14 несовместимых систем сборки одну хорошую приводят только к появлению 15 несовместимых систем сборки, как в том комиксе. Так что учи cmake.

Например. Я в университете могу запустить visual studio и собрать проект, а поставить cygwin не могу, ему какие-то админские права нужны.
Проблема autotools в том что на windows для него нужно городить posix окружение.
Я правда придумал простое решение: можно для windows написать статическую конфигурацию и батник, который будет нужные файлы вилдкардами выбирать и запускать cl.exe. Если разработка идёт не на windows, а студия используется только для сборки релизов и ci, такой вариант подойдёт.

Например. Я в университете могу запустить visual studio и собрать проект, а поставить cygwin не могу, ему какие-то админские права нужны.

Согласись, что это проблема организационная, а не техническая. В конце концов, Visual Studio в состав Windows тоже не входит, и если руководство вменяемое, можно предложить опенсорсную альтернативу.

Если же всё совсем плохо, тогда да, лучше смотреть не на автотулзы, а на cmake - он умеет работать с вижуалстудией.

P.S. У меня вообще есть мечта идиота - для вендосборок использовать виртуалку с ReactOS. К сожалению, у неё пока стабильность хромает.

В комментариях везде пишут make это ужас,учи cmake,scons,etc.

Кстати, идиотские комментарии, из серии «сравним стартер и ДВС». make - это ассемблер мира сборочных систем. Её задача - это по полученному конфигу разрулить зависимости и вызвать нужные компиляторы. И с этой задачей она справляется на отлично. А то, что конфиг у неё не для человеков, а для роботов - это вопрос отдельный. И для его генерации из чего-то более высокоуровневого есть cmake или, скажем, кутешный qmake.

уже появилась. meson build system называется.

уже появилась. meson build system называется.

Финский разработчик Jussi Pakkanen был удручен состоянием существующих систем сборки программного обеспечения, вынуждающих использовать глупые синтаксические конструкции в файлах конфигурации и зачастую ведущих себя непредсказуемо. По этой причине он потратил рождественские праздники 2012 года на разработку собственной системы сборки программного обеспечения...

Хм, начало действительно интригующее :) надо будет затестить.

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

уже появилась. meson build system называется.

Проблема с 15-м стандартом состоит в том, что он хорошо работает для ограниченного числа юз-кейсов, для которых создавался. Если в какой-то момент разработчик не скажет твёрдое: «нет, это в моей системе сборки сделать в принципе нельзя. Если вам это нужно — вам нужна другая система сборки. Я буду держать своё детище простым и понятным», а будет добавлять новые и новые фичи, эта система превращается в такого же монстра, как и уже существующие. Тогда появляется новая система сборки, и всё начинается сначала.

Да нет, не организационная. Поблема скорее в зависимости autotools от sh и отсуствтвия в нём генераторов под другие системы.

Все зависит от сложности проекта и от количества в нем платформенно-специфичных наигрышей

Всегда собирал с помощью своего build.sh

Тогда make тебе за глаза хватит. И больше не возникнет желания возвращаться к build.sh, никогда

Зачем тебе glList? Тебе же надо в 2 строчки

Это добавляет glGenList,glNewList,glEndList,glCallList 4 строчки,можно потерпеть. На счет вращения на cpu,glList вращает на gpu как я понял.

проблем с освоением VAO возникнуть не должно

Проблемы у меня возникали только с glRotatef,gluPerspective.Теперь вот нашел math_3d.h

Но вообще я посматриваю сейчас на новый OpenGL,да.Но в расте хрен поймешь как матрицу передать в glium/gl-rs.

На счет вращения на cpu,glList вращает на gpu как я понял

Матрицу поворота он будет строить на CPU. Умножать вершины на неё — на GPU. На самом деле, в том, чтобы строить матрицу на CPU нет ничего плохого — вероятно, гораздо дороже обойдётся переброс и хранение на GPU данных, необходимых для построения. Я говорю о том, что построением матрицы не должен заниматься драйвер (а именно этим его заставляет заниматься старый стандарт OpenGL).

Но вообще я посматриваю сейчас на новый OpenGL,да

Вот это правильно! Можно сказать на сторону добра переходишь :)

autotools, как ни удивительно. Простой синтаксис, если имеешь дело с самописным проектом, лучше и не найти.

Да ладно, а как же параметр --target= у скрипта configure?

А потом: у меня на ReactOS работает, идите в задницу со своей виндой?

красноглазик детектед. деды юзали и нам велели.

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

Интересно, как отнесётся к этому CMake если ему отдать в качестве компилятора MSVC под Wine?

В случае Pure C проектов усложнять незачем.

В случае Pure C проектов усложнять незачем.

счас бы считать autotools простым

Для распахивания поля - несомненно.

А как ещё скрипты писать надо?

Хотя что-то такое припоминаю что эти файлики типа IDE генерировать должен. Но я такие вещи этим IDE-поделиям не доверяю да и собираю код в командной строке.

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

Я подумаю над этой идеей. :) Но вообще комплекс армейского «деда» мне не свойственен. Да и скорее ситуация будет обратная: если программа завелась в ReactOS, на винде и подавно заведётся.

На счёт IDE, то зря, лучше попробуйте qtcreator, там из коробки CMake для pure C, так что очень рекомендую.

А не путает ли топикстартер make и autotools?

Раньше в нем писал,но у него свое форматирование с которым я не согласен)Да и неудобно как то файлы в проект добавлять и все такое

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

Да и неудобно как то файлы в проект добавлять и все такое

Ну для Pure C просто прописывается в CMakeLists.txt новый файл и он автоматически добавляется в проект, по мне оч. удобно, но дело вкуса

Make не так уж и ужасен. Это система сборки. У нее свои цели. А вот CMake — генератор для различных систем сборки. Он может сделать и Makefile, и Ninja, и для той же Visual Studio проект. У CMake свои цели. Просто не стоит путать эти самые цели. В целом, CMake — достаточно универсальная штуковина. Но проблема в том, что не везде ее универсальность нужна. Так, например, драйвер ты им затрахаешься собирать, для этого Make лучше. Напротив, для чего-то завязанного на Qt лучше подходит QMake. Короче, мой совет: под свои задачи — своя система сборки. Низкоуровневое — make. Qt + * — qmake. Прочее — cmake.

** Ну, каждому свое удобнее может в этом вопросе казаться **

если зависимостей много, то cmake, в противном случае — make.

Спасибо,я что то упустил эти моменты

Но в расте хрен поймешь как матрицу передать в glium/gl-rs.

В gl-rs через gl::UniformMatrix4fv

Так я ее делаю в glm-rs каком нибудь,а потом надо передать ее в glium.Glium принимает чистую матрицу (массив),а хрен поймешь как ее получить из glm-rs

Сейчас, фактически, стандарт кроссплатформенных проектов cmake.

Поддерживаю... Помниться, собирал и проекты, связанные с LLVM, и чего только не выворачивал с CMake. А главное — работает везде, лишь бы зависимости были установлены.

> Финский разработчик Jussi Pakkanen был удручен состоянием существующих систем сборки программного обеспечения

Возможно, надо просто посмотреть более реальные примеры...

Теперь удручён этим детищем я. Там принцип как в винде: системе сборки виднее. Хочешь свои CFLAGS, а не те, что по-умолчанию для debug/release - пожалуйста, но meson всё равно и свои тоже вставит. Красотище получается.