Использует ли cmake соглашение вместо конфигурации?

#c #maven #cmake #convention-over-configur

#c #maven #cmake #соглашение вместо конфигурации

Вопрос:

Говорят, что Maven использует форму соглашения по конфигурации.

Я не хочу проводить какие-либо неправильные сравнения, но, насколько я понимаю, cmake может заполнить аналогичный рулон для проекта C , как maven может для проекта Java.

Итак, есть ли у cmake какие-то соглашения по конфигурации, или каждый проект настроен уникально? (Макет Wrt. file, макет теста, выходные данные сборки и т.д.)

Комментарии:

1. Я действительно ответил на ваш вопрос с точки зрения человека, который знает Maven.

Ответ №1:

После того, как я оценил элегантность Maven 3, я также искал соглашение о настройке системы в стиле C maven. …

Я также проверил CMAKE, после создания скелета выделилось несколько вещей.

  1. CMAKE иногда является декларативным, иногда процедурным, и вы всегда будете в конечном итоге с уродливым сочетанием. ИНАЧЕ говоря, это ANT для C без скобок.

  2. CMAKE сам по себе переносим, увы, вашему проекту потребуется обработать особенности платформы, и вам лучше знать их заранее. Модули CMAKE существуют, чтобы предположительно помочь с этим, к сожалению, их повторное использование больше похоже на обещание ролей Ansible… Теоретически возможно, но на практике они оказываются для вас достойным способом организовать всю необходимую сложность.

Другими словами, CMAKE не имеет формы, подобной Maven. Это больше похоже на ANT более низкого уровня, который позволяет вам использовать «кроссплатформенный» DSL для генерации make-файлов, специфичных для конкретной платформы.

Ответ №2:

Единственное соглашение, которое мы настоятельно рекомендуем, — это делать сборки «из исходного кода», когда каталог сборки содержит ВСЕ продукты сборки и полностью отделен от дерева исходных текстов, обычно исходный код и сборка являются родными братьями:

 projects
  proj1-build-x86
  proj1-build-x64
  proj1-src
  

Две основные причины, по которым мы всегда рекомендуем эту стратегию: (1) чтобы сохранить дерево исходных текстов чистым от продуктов сборки, чтобы было легко определить, что изменилось с момента вашего последнего обновления в вашей системе контроля версий, и (2) чтобы у вас могло быть несколько деревьев сборки для любого данного дерева исходных текстов и не беспокоиться о том, что продукты сборки и / или настройки одного из них мешают другому.

Недавно я заметил, что проект, над которым я работал, непреднамеренно сгенерировал некоторые файлы python в дереве исходных текстов. Однако я заметил это только тогда, когда попытался собрать сборки x86 и x64 одновременно в разных деревьях сборки… и внезапно в сгенерированных файлах python были дублированы и перемешаны некоторые строки. Изменил его, чтобы сгенерировать в дереве сборки, и все было хорошо.

Однако все это лишь часть передовой практики CMake, которая не подкрепляется ничем иным, кроме здравого смысла и дисциплины умных людей, управляющих этими проектами…

Комментарии:

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