Здравствуйте, SaZ, Вы писали:

SaZ>Я понимаю, что вы привыкли, когда IDE за вас генерирует правила сборки, но в больших проектах на С++ такое очень редко встречается.
Правила сборки пишу я, IDE просто удобный инструмент для этого.
У нас были проекты под пятьдесят подпроектов с союшене MSVS (C++/MFC) и все правила сборки, линковки, зависимостей — мы прописывали
в удобной среде студии. Периодически переходя от одной версии студии к другой.

AG>Теперь, что касается самой CMake: утилита неплохая.
SaZ>Это система сборки. Вернее даже генератор систем сборки.
Хорошо, назовём это "генератор систем сборки", но в большинстве случаев эта сущность играет роль дополнения (костылика). Так?
Когда из коробки система что-то не_может/не_умеет вот тут нам и удобна CMake.
Ты же сам чуть выше сообщал — типа "дополнительных утилит не нужно!"...
А чем тот же CMake отличается от чего-то другого?

SaZ>Так, чисто для развлечения, попробуйте собрать solution, чтобы встроить компиляцию OpenSSL в свой проект.
Я работал с OpenCV (и тоже использовал, эпизодически, CMake). Я в курсе, что CMake — инструмент для открытых кроссплатформенных проектов.
Вопрос в другом — почему мы должны применять этот инструмент, имея отличный штатный инструментарий в Qt?
Ну доведут разработчики Qt свою новую версию, и всё будет отлично! В чём же вопрос?

SaZ>Лично у меня для своих проектов есть шаблоны CMake файлов (написанные за пару дней), к которым, в большинстве случаев, достаточно просто подложить исходники и всё будет работать с любой IDE (MSVS, XCode, QtCreator).
Молодец!
Только вот вопрос — зачем тратить пару дней, когда (ИМХО) всё это должно было бы работать из-коробки?
Здесь, конечно, есть поле для творчества: можно сделать свои скрипты (на том же Python, например), можно сделать свои утилиты (с GUI или командной строки), на том же Qt, если тебе эта технология знакомее и ближе, только вот зачем?
Просто для того, чтобы чем-то компенсировать издержки инструментария...

SaZ>Для вас это бубен, для нормальных проектов — ...
Тот же бубен, пусть даже мощный. Просто такая вот терминология.

SaZ>... инструмент, который позволяет сделать удобной разработку для различных команд под целый зоопарк платформ.
СТОП! А для чего же тогда Qt?
Разве не кроссплатформенность преподносится, как основная фишка данного продукта?

SaZ>Если для разработки используется более чем одна IDE, то либо начинаются пляски с бубном, либо берётся CMake.
Я бы сказал точнее: начинаются пляски с бубном под названием CMake.

SaZ>В своё время мы поддерживали сборку отдельно через make...
Молодцы, проявили смекалку, смогли выйти из сложной ситуации!

SaZ>Девелопер должен обладать рядом навыков и знаний. Нужно понимать, как осуществляется компиляция и линковка.
Прекрасно, но ещё надо знать синтаксис управляющих команд для файла CMake. А надо ли этим засорять свой мозг?

Так, например, владение языковым базисом C/C++ мне представляется, как конвертируемый навык.
Перечислю системы, с котрыми я работал, используя данный базис:
1) AVOCET — это ANSI C compiler для встроенных микропроцессорных систем;
2) Borland (в двух вариантах) Borland C++ builder и древний Borland 3.1;
3) Microsoft Visual Studio (начиная от 4-ки) и до 2015-й. Правда до новой 2017-й — пока не дошли руки. Не скрываю, это Лидер среди IDE;
4) QtCreator — удобная тулза, нередко пользуюсь этой IDE, особенно в Linux (Debian);
5) Watcom C — было и такое, ещё во времена DOS-а.
То есть — это навыки и знания, востребованные каждый день.
Hint — в отличие от синтаксиса CMake, который потребуется максимум один раз в год...

Здравствуйте, SaZ, Вы писали:

SaZ>Я понимаю, что вы привыкли, когда IDE за вас генерирует правила сборки, но в больших проектах на С++ такое очень редко встречается.
Правила сборки пишу я, IDE просто удобный инструмент для этого.
У нас были проекты под пятьдесят подпроектов с союшене MSVS (C++/MFC) и все правила сборки, линковки, зависимостей — мы прописывали
в удобной среде студии. Периодически переходя от одной версии студии к другой.

AG>Теперь, что касается самой CMake: утилита неплохая.
SaZ>Это система сборки. Вернее даже генератор систем сборки.
Хорошо, назовём это "генератор систем сборки", но в большинстве случаев эта сущность играет роль дополнения (костылика). Так?
Когда из коробки система что-то не_может/не_умеет вот тут нам и удобна CMake.
Ты же сам чуть выше сообщал — типа "дополнительных утилит не нужно!"...
А чем тот же CMake отличается от чего-то другого?

SaZ>Так, чисто для развлечения, попробуйте собрать solution, чтобы встроить компиляцию OpenSSL в свой проект.
Я работал с OpenCV (и тоже использовал, эпизодически, CMake). Я в курсе, что CMake — инструмент для открытых кроссплатформенных проектов.
Вопрос в другом — почему мы должны применять этот инструмент, имея отличный штатный инструментарий в Qt?
Ну доведут разработчики Qt свою новую версию, и всё будет отлично! В чём же вопрос?

SaZ>Лично у меня для своих проектов есть шаблоны CMake файлов (написанные за пару дней), к которым, в большинстве случаев, достаточно просто подложить исходники и всё будет работать с любой IDE (MSVS, XCode, QtCreator).
Молодец!
Только вот вопрос — зачем тратить пару дней, когда (ИМХО) всё это должно было бы работать из-коробки?
Здесь, конечно, есть поле для творчества: можно сделать свои скрипты (на том же Python, например), можно сделать свои утилиты (с GUI или командной строки), на том же Qt, если тебе эта технология знакомее и ближе, только вот зачем?
Просто для того, чтобы чем-то компенсировать издержки инструментария...

SaZ>Для вас это бубен, для нормальных проектов — ...
Тот же бубен, пусть даже мощный. Просто такая вот терминология.

SaZ>... инструмент, который позволяет сделать удобной разработку для различных команд под целый зоопарк платформ.
СТОП! А для чего же тогда Qt?
Разве не кроссплатформенность преподносится, как основная фишка данного продукта?

SaZ>Если для разработки используется более чем одна IDE, то либо начинаются пляски с бубном, либо берётся CMake.
Я бы сказал точнее: начинаются пляски с бубном под названием CMake.

SaZ>В своё время мы поддерживали сборку отдельно через make...
Молодцы, проявили смекалку, смогли выйти из сложной ситуации!

SaZ>Девелопер должен обладать рядом навыков и знаний. Нужно понимать, как осуществляется компиляция и линковка.
Прекрасно, но ещё надо знать синтаксис управляющих команд для файла CMake. А надо ли этим засорять свой мозг?

Так, например, владение языковым базисом C/C++ мне представляется, как конвертируемый навык.
Перечислю системы, с котрыми я работал, используя данный базис:
1) AVOCET — это ANSI C compiler для встроенных микропроцессорных систем;
2) Borland (в двух вариантах) Borland C++ builder и древний Borland 3.1;
3) Microsoft Visual Studio (начиная от 4-ки) и до 2015-й. Правда до новой 2017-й — пока не дошли руки. Не скрываю, это Лидер среди IDE;
4) QtCreator — удобная тулза, нередко пользуюсь этой IDE, особенно в Linux (Debian);
5) Watcom C — было и такое, ещё во времена DOS-а.
То есть — это навыки и знания, востребованные каждый день.
Hint — в отличие от синтаксиса CMake, который потребуется максимум один раз в год...

P.S. Я не указал здесь, что также работал с Eclipse (для Java), PyCharm (для Python). Но это уже за пределами вселенной C++