Мне это нужно для автоматизации построения параметризованных продуктов при помощи командных файлов, чтобы не дублировать одни и те же параметры в разных местах.
То, да, это очень уродливое решение. Все это решается системами сборки типа CMake.
option(MY_PRODUCT_FEATURE_X_SUPPORT "My Product feature X support" OFF)
...
if (MY_PRODUCT_FEATURE_X_SUPPORT)
add_compile_definitions(MY_PRODUCT_FEATURE_X_SUPPORT)
endif()
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, удусекшл, Вы писали:
У>>Чего тут геморрного?
ЕМ>Например, то, что для всех внешних скриптов, использующих параметры через запуск обсуждаемой вспомогательной программы, потребуется обеспечить их соответствие в заголовках и в EXE.
В чем проблема, если эта прога собирается в том же проекте, что и остальное?
ЕМ>То есть, либо не забыть вручную запустить сборку в студии, и только потом запускать скрипт, либо запускать альтернативную сборку из скрипта. Второе уже реализовано в том, что описано в исходном сообщении. Какой тогда смысл добавлять зависимости в студию?
Зачем вручную-то?
Ладно, пили как знаешь, дело хозяйское.
Эх, мне бы столько лишнего времени...
Re[7]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Так и через CMake и аналоги тоже не надо — по крайней мере, пока. Просто потому, что изящного и надежного решения задачи нет, любое решение предполагает колхозинг и напиллинг.
Нет и еще раз нет. Есть стандартное для таких задач решение не требующее никаких особых допиливаний.
ЕМ>Определение параметров в заголовках C++ мне нравится тем, что файлы .cpp/.h в разработке первичны, все остальные — вспомогательные.
Нет и еще раз нет. cpp/.h первичны только для "Hello world", когда весь проект умещается в пару файлов.
В реальном мире иерархия такая:
* гит репозиторий (без него у вас тупо нет исходников)
* файл описывающий сборку для CI/CD
* файл проекта (Makefile, CMakeLists.txt, *.sln, etc)
* только после этого исходники (на любых языках)
ЕМ>Определения в заголовках могут быть непосредственно использованы в коде.
Нет и еще раз нет. Опции сборки, параметры — все это внешиние сущности по отношению к исходникам, код не знает как его будут собирать.
ЕМ>Если их выносить в makefile, то нужно передавать их компилятору в командной строке, хоть вручную, хоть автоматически.
Если выносить параметры в файл проекта, то ничего ручками передавать не надо.
ЕМ>Я традиционно не люблю стандартных решаторов.
Ну это заметно. Для левши-одиночки это иногда работает, но в общем случае — это профессиональный тупик.
ЕМ>Во многих из моих задач требуется менять стандартные параметры на нестандартные, и я имел достаточно геморроя с автоматизированными системами сборки, которые сложнее make/nmake. Например, в DDK/WDK была утилита Build, которая работала поверх nmake. Для простых типовых проектов — очень удобно, но шаг влево/вправо, и сразу геморрой в полный рост. Я на борьбу с ее особенностями в совокупности потратил столько времени, что можно было написать собственную.
Средства от МС — это далеко не идеал, поэтому они сами переходят на CMake. CMake который тоже далеко не идеал, но проблемы на подобее вашей там решаются просто.
В общем я категорически против пропаганды и распространения решений подобных вашему, это вред для отрасли. Хотя с другой стороны надо посмотреть на это как "больше возможностей для меня"
минимально извращенный способ извлечения в командном файле Windows параметров C++-проекта из .h-файлов. Средне-извращенный у меня уже много лет был (прямой парсинг заголовков с обрезкой кавычек, если есть). Он мне не нравился тем, что не умел склеивать строки, отчего нельзя было определять производные параметры через определенные ранее (например, название продукта фигурирует в именах ряда экспортируемых объектов).
Предложенные варианты с использованием промежуточной выдачи препроцессора "в лоб" не прокатили — они особо ничем не лучше того, что уже было. А вчера я совершенно неожиданно вспомнил о __pragma (message ()). Это уже конструкция не препроцессора, а компилятора, она умеет склеивать строки.
В итоге получилось изрядное извращение:
— Командный файл создает временный .cpp-файл, включающий нужные параметрические заголовки и серию __pragma (message ()).
— Парсит параметры проекта, добывая путь к базовой библиотеке, где определены некоторые сервисные макросы.
— Вызывает компилятор, который на каждый вызов __pragma (message ()) выдает строку вида "set Var=Value".
— Копирует эти строки из выдачи компилятора во временный .cmd-файл.
— Вызывает временный .cmd-файл для определения переменных в текущей среде выполнения.
И в статичесткую либу его положите. В проект он не будет линковаться, но можно с ним собрать отдельную программу которая запишет все ваши параметры в нужно вам виде.
Сам файл генерировать скриптом.
Re[2]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, kov_serg, Вы писали:
_>В проект он не будет линковаться, но можно с ним собрать отдельную программу которая запишет все ваши параметры в нужно вам виде.
Чем это будет лучше описанного способа?
Re[3]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, kov_serg, Вы писали:
ЕМ>>Чем это будет лучше описанного способа?
_>Убираются этапы парсинга.
А толку? Эта вспомогательная программа сама себя не соберет. Если ее собирать в рамках сборки всего проекта, то нужно будет как-то разделить этапы, чтобы сперва собралась только вспомогательная, затем запустить ее, получить параметры, и с ними продолжить сборку всего остального. Упрощения или унификации не вижу, вижу только усложнение.
_>И можно в runtime иметь список параметров компиляции или их хеш.
Они там и так есть — параметрические заголовки всегда включаются в исходники проекта при сборке.
Re[5]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
_>>И можно в runtime иметь список параметров компиляции или их хеш.
ЕМ>Они там и так есть — параметрические заголовки всегда включаются в исходники проекта при сборке.
Может всё-таки сделать как обычно. Сделать файл манифеста проекта где описаны все параметры и зависимости и из него генерировать заголовки, а не наоборот. https://youtu.be/XW8XHW3hs3o?t=398
Здравствуйте, kov_serg, Вы писали:
_>Может всё-таки сделать как обычно. Сделать файл манифеста проекта где описаны все параметры и зависимости и из него генерировать заголовки, а не наоборот.
"Как обычно" манифест делается не для себя, а для системы, распространителей, магазинов приложений и т.п. Сомневаюсь, что кто-то в здравом уме стал бы делать его сугубо для внутренних целей.
Re[2]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Определи эти параметры в файле с удобной для тебя структурой КД>Из этого файла генерируй хедер
Опять же, чем это будет проще? Нужен код, который парсит этот файт и генерит заголовок. Отладочные варианты я собираю студией, если включить туда этот файл в качестве зависимости, то надо будет прописывать для него способ обработки, к нему цеплять код преобразователя. Заголовки относятся к числу файлов, редактируемых студией: если вдруг этот заголовок окажется открыт в редакторе — студия возбудится, что он изменился. Такой же уродливый колхозинг.
Re[7]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Может всё-таки сделать как обычно. Сделать файл манифеста проекта где описаны все параметры и зависимости и из него генерировать заголовки, а не наоборот.
ЕМ>. Сомневаюсь, что кто-то в здравом уме стал бы делать его сугубо для внутренних целей.
А что смущает ?
Re[8]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Михaил, Вы писали:
_>>>Сделать файл манифеста проекта
ЕМ>>Сомневаюсь, что кто-то в здравом уме стал бы делать его сугубо для внутренних целей.
М>А что смущает ?
Чрезмерный уровень сложности. Имеет смысл лишь при наличии удобных встроенных средств как создания/редактирования, так для парсинга/обработки XML.
Re[2]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Skorodum, Вы писали:
S>Все это решается системами сборки типа CMake.
С таким же успехом оно решается и использованием банального nmake от MS. Вопрос в том, как это увязать со студией, в которой я делаю отладочные сборки (у меня еще и VS 2008 до сих пор). Если бы нужно было делать только рабочие сборки скриптами давно бы вынес определения в makefile или сами скрипты.
Re[3]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С таким же успехом оно решается и использованием банального nmake от MS.
То бишь Makefile.
ЕМ>Вопрос в том, как это увязать со студией, в которой я делаю отладочные сборки (у меня еще и VS 2008 до сих пор).
Новая студия (2017, 2019) поддерживает CMake, компилятор aka toolchain, наверное, можно прописать и старый.
ЕМ>Если бы нужно было делать только рабочие сборки скриптами давно бы вынес определения в makefile или сами скрипты.
Какие еще "рабочие сборки"? Не стоит придумывать какие-то свои термины для совершенно стандартных задач.
Вариантов компиляции может быть хоть сколько. В чем тут проблема?
Re[4]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Skorodum, Вы писали:
S>Новая студия (2017, 2019) поддерживает CMake, компилятор aka toolchain, наверное, можно прописать и старый.
Так компиляторы мне как раз больше нравятся новые — они, поддерживая все больше новых возможностей языка, предупреждений, оптимизаций и т.п., очень умеренно растут в размерах (самые последние занимают не больше 50 Мб на платформу), работают так же быстро, как и 10-15 лет назад, и почти не жрут память. А вот со всех студий после 2008 меня все время блевать тянет — они пухнут со страшной скоростью, тормозят совершенно запредельно, и при этом жрут память непонятно куда.
Судя по всему, у MS осталось две команды относительно пряморуких разработчиков — на ядро и на VC++. Все остальные — или просто, или неимоверно криворуки.
S>Какие еще "рабочие сборки"?
Сборки, которые я ежедневно делаю в ходе разработки. Управлять ими непосредственно из-под студии гораздо удобнее, чем через внешние конфиги. У меня уже был опыт многолетней поддержки 16-разрядных модулей для Win9x, которые собирались через внешний makefile — удовольствие было так себе.
S>Вариантов компиляции может быть хоть сколько. В чем тут проблема?
В удобстве многочасовой ежедневной работы, вестимо.
Re[5]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А толку? Эта вспомогательная программа сама себя не соберет. Если ее собирать в рамках сборки всего проекта, то нужно будет как-то разделить этапы, чтобы сперва собралась только вспомогательная, затем запустить ее, получить параметры, и с ними продолжить сборку всего остального. Упрощения или унификации не вижу, вижу только усложнение.
Про dependencies и custom build steps не слышал?
Re[5]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> А вот со всех студий после 2008 меня все время блевать тянет — они пухнут со страшной скоростью, тормозят совершенно запредельно, и при этом жрут память непонятно куда.
OFFTOP. Тебе надо на 2022-ю переходить. Она хоть и жрет память, но хотя бы не упирается рогами в 32-битную крышу
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Skorodum, Вы писали: S>>Новая студия (2017, 2019) поддерживает CMake, компилятор aka toolchain, наверное, можно прописать и старый. ЕМ>Так компиляторы мне как раз больше нравятся новые — они, поддерживая все больше новых возможностей языка, предупреждений, оптимизаций и т.п., очень умеренно растут в размерах (самые последние занимают не больше 50 Мб на платформу), работают так же быстро, как и 10-15 лет назад, и почти не жрут память. А вот со всех студий после 2008 меня все время блевать тянет — они пухнут со страшной скоростью, тормозят совершенно запредельно, и при этом жрут память непонятно куда.
Ну если вы привязаны к студии 2008, то наверное и там можно как-то прикрутить сборку на CMake как вызов внешней команды, но оно действительно так надо?
ЕМ>Сборки, которые я ежедневно делаю в ходе разработки. Управлять ими непосредственно из-под студии гораздо удобнее, чем через внешние конфиги.
Ну так в чем проблема? Определяете сборку где CMake передается опция "BUILD RELEASE VERSION WITH FEATURE X, Y, Z", CMake добавляет 100500 необходимых дефайнов.
Это совершенно стандартная ситуация со стандарнтым решением
А у ваше решение это вывернутый наизнанку ежик.
ЕМ>В удобстве многочасовой ежедневной работы, вестимо.
Если велосипеды на 3-угольных колесах не изобретать, то все удобно и просто
Re[6]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Тебе надо на 2022-ю переходить. Она хоть и жрет память, но хотя бы не упирается рогами в 32-битную крышу
Сомневаюсь, что когда-нибудь сумею увидеть это упирание на своих проектах.
Re[7]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
У>>Про dependencies и custom build steps не слышал?
ЕМ>Слышал, периодически пользуюсь. Для описанной задачи — слишком геморройно.
Чего там геморрного? Dependencies — в вижуалке ПКМ на проекте, выбрать там в меню, в диалоге поставить галку.
custom build step — ну это тоже одно поле в свойствах проекта заполнить. У тебя для остальных проектов все одинаковое, поэтому можно сделать After Build step для одного проекта, чем Before Build для всех. Ну, депенденсю надо для каждого выставить.
Чего тут геморрного? несколько кликов мышкой, вот буквально вот
Re[6]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Skorodum, Вы писали:
S>Ну если вы привязаны к студии 2008, то наверное и там можно как-то прикрутить сборку на CMake как вызов внешней команды, но оно действительно так надо?
Так и через CMake и аналоги тоже не надо — по крайней мере, пока. Просто потому, что изящного и надежного решения задачи нет, любое решение предполагает колхозинг и напиллинг. Определение параметров в заголовках C++ мне нравится тем, что файлы .cpp/.h в разработке первичны, все остальные — вспомогательные. Определения в заголовках могут быть непосредственно использованы в коде. Если их выносить в makefile, то нужно передавать их компилятору в командной строке, хоть вручную, хоть автоматически.
S>Ну так в чем проблема? Определяете сборку где CMake передается опция "BUILD RELEASE VERSION WITH FEATURE X, Y, Z", CMake добавляет 100500 необходимых дефайнов. S>Это совершенно стандартная ситуация со стандарнтым решением
Я традиционно не люблю стандартных решаторов. Во многих из моих задач требуется менять стандартные параметры на нестандартные, и я имел достаточно геморроя с автоматизированными системами сборки, которые сложнее make/nmake. Например, в DDK/WDK была утилита Build, которая работала поверх nmake. Для простых типовых проектов — очень удобно, но шаг влево/вправо, и сразу геморрой в полный рост. Я на борьбу с ее особенностями в совокупности потратил столько времени, что можно было написать собственную.
Re[8]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, удусекшл, Вы писали:
У>Чего тут геморрного?
Например, то, что для всех внешних скриптов, использующих параметры через запуск обсуждаемой вспомогательной программы, потребуется обеспечить их соответствие в заголовках и в EXE. То есть, либо не забыть вручную запустить сборку в студии, и только потом запускать скрипт, либо запускать альтернативную сборку из скрипта. Второе уже реализовано в том, что описано в исходном сообщении. Какой тогда смысл добавлять зависимости в студию?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Уродливо, аж смотреть противно, но работает.
Поздравляю, вы сделали маленькое, кривое подобие небольшого набора функционала из CMake. Никогда не понимал сильнейшего NIH синдрома у С++ разработчиков. Он же во всем, а причин для него реально ноль
Здравствуйте, kaa.python, Вы писали:
KP>Поздравляю, вы сделали маленькое, кривое подобие небольшого набора функционала из CMake.
Насколько я знаю, в CMake это делается наоборот.
KP>Никогда не понимал сильнейшего NIH синдрома у С++ разработчиков.
Я тоже никогда не понимал синдрома "если нужна ямка полметра на полметра, то нужно приобрести универсальную землеройную машину".
Здесь совершенно другой случай. Если кому-то нравится и удобен CMake, они подобного делать не станут. Лично мне он сильно избыточен, его использование потребует изучения особенностей и наложит ограничения. В данном случае нужно локальное и предсказуемое решение, а не универсальный инструмент "для всего".
Re[10]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, удусекшл, Вы писали:
ЕМ>>Например, то, что для всех внешних скриптов, использующих параметры через запуск обсуждаемой вспомогательной программы, потребуется обеспечить их соответствие в заголовках и в EXE.
У>В чем проблема, если эта прога собирается в том же проекте, что и остальное?
В том же, да не так же. В студии, в ходе разработки/отладки, собираются только рабочие бинарники. Когда все отлажено, полный релиз собирается теми самыми скриптами, что упомянуты в исходном сообщении. Зачем мне усложнять процесс сборки в студии, если в ходе рутинной работы этого не требуется?
ЕМ>>То есть, либо не забыть вручную запустить сборку в студии, и только потом запускать скрипт
У>Зачем вручную-то?
А как еще — по таймеру, что ли? Имеется в виду сама команда на сборку (F7).
У>Эх, мне бы столько лишнего времени...
У меня его далеко не так много, как кажется. Когда творческий процесс идет нормально, я подобными вещами не заморачиваюсь, и какое-то время терплю дублирование параметров и подобные косяки. В последнее время процесс буксует, поэтому понемногу подчищаю накопившиеся хвосты.
Re[8]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Skorodum, Вы писали:
S>Есть стандартное для таких задач решение не требующее никаких особых допиливаний.
Не "стандартное", а "типовое", "рекомендуемое" и т.п. Стандартное — это когда оно есть в любой ОС, или любой системе разработки.
S>.cpp/.h первичны только для "Hello world", когда весь проект умещается в пару файлов.
А что меняется, если проект умещается в сотню файлов?
S>В реальном мире иерархия такая:
Не в "реальном", а в "корпоративном", в определенных сообществах и т.п.
S>* гит репозиторий (без него у вас тупо нет исходников)
Не использую CI/CD, и пока не планирую.
S>* только после этого исходники (на любых языках)
Вы забыли добавить "составление ТЗ и графика работы, визирование у начальника отдела".
S>Опции сборки, параметры — все это внешиние сущности по отношению к исходникам, код не знает как его будут собирать.
Мой код — знает.
S>Если выносить параметры в файл проекта, то ничего ручками передавать не надо.
Если бы существовал единый стандарт на такой файл проекта, который легко подключался бы и к студии, и к nmake — я бы его использовал.
S>Для левши-одиночки это иногда работает, но в общем случае — это профессиональный тупик.
Согласен, для групповой разработки такие решения не годятся.
S>В общем я категорически против пропаганды и распространения решений подобных вашему, это вред для отрасли.
Да нибожежмой, ни в коем случае не рекомендую их для отрасли.
Re[9]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Skorodum, Вы писали: S>>Есть стандартное для таких задач решение не требующее никаких особых допиливаний. ЕМ>Не "стандартное", а "типовое", "рекомендуемое" и т.п. Стандартное — это когда оно есть в любой ОС, или любой системе разработки.
Так это задача решается в 99% проектов. В какой системе сборки ее нет?
S>>.cpp/.h первичны только для "Hello world", когда весь проект умещается в пару файлов. ЕМ>А что меняется, если проект умещается в сотню файлов?
Первичными становится система контроля версий и файл проекта, без них смотреть в исходники бесполезно.
S>>В реальном мире иерархия такая: ЕМ>Не в "реальном", а в "корпоративном", в определенных сообществах и т.п.
Этот реальный мир создает 99,9999% продуктовых программных продуктов.
S>>* гит репозиторий (без него у вас тупо нет исходников) ЕМ>У меня есть исходники, а вот гит-репозитория нет, и я до сих пор не уверен, что он мне нужен
S>>* файл описывающий сборку для CI/CD ЕМ>Не использую CI/CD, и пока не планирую.
Использвуешь в виде самописных скриптов для сборки.
S>>* только после этого исходники (на любых языках) ЕМ>Вы забыли добавить "составление ТЗ и графика работы, визирование у начальника отдела".
Нет. Это вообще ортогонально обсуждаемым техническим вопросам.
S>>Опции сборки, параметры — все это внешиние сущности по отношению к исходникам, код не знает как его будут собирать. ЕМ>Мой код — знает.
Плохо. А система сборки у тебя не знает и ты извращаешься со всякими скриптами.
S>>Если выносить параметры в файл проекта, то ничего ручками передавать не надо. ЕМ>Если бы существовал единый стандарт на такой файл проекта, который легко подключался бы и к студии, и к nmake — я бы его использовал.
CMake. И подкдлючается и генерит Makefile.
S>>Для левши-одиночки это иногда работает, но в общем случае — это профессиональный тупик. ЕМ>Согласен, для групповой разработки такие решения не годятся.
+1
S>>В общем я категорически против пропаганды и распространения решений подобных вашему, это вред для отрасли. ЕМ>Да нибожежмой, ни в коем случае не рекомендую их для отрасли.
+1
Re[3]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, kaa.python, Вы писали:
KP>>Поздравляю, вы сделали маленькое, кривое подобие небольшого набора функционала из CMake. ЕМ>Насколько я знаю, в CMake это делается наоборот.
Да, и это логично.
KP>>Никогда не понимал сильнейшего NIH синдрома у С++ разработчиков. ЕМ>Я тоже никогда не понимал синдрома "если нужна ямка полметра на полметра, то нужно приобрести универсальную землеройную машину".
C++ по определению это универсальная землеройная машина с гипердвигателем.
ЕМ>Здесь совершенно другой случай. Если кому-то нравится и удобен CMake, они подобного делать не станут. Лично мне он сильно избыточен, его использование потребует изучения особенностей и наложит ограничения. В данном случае нужно локальное и предсказуемое решение, а не универсальный инструмент "для всего".
Логика и аналогии тут неверные, т.к. переплаты за универсальный интсрумент нет (особенно на фоне использования С++). Даже твои маленькие задачи CMake решит лучше и проще чем твои самописные скрипты.
Re[10]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Skorodum, Вы писали:
S>Так это задача решается в 99% проектов. В какой системе сборки ее нет?
Она есть во всех системах сборки, но в большинстве реализована по-разному. Нельзя просто взять из одной и вставить в другую, как родную — везде нужно допиливать, пусть и не радикально.
ЕМ>>А что меняется, если проект умещается в сотню файлов? S>Первичными становится система контроля версий и файл проекта, без них смотреть в исходники бесполезно.
Не вижу оснований для столь фундаментальных утверждений. Если в проекте есть файл ProductParameters.h, то вполне логично, куда смотреть.
S>Этот реальный мир создает 99,9999% продуктовых программных продуктов.
Большей частью потому, что решение вопроса "как реализовать нашу задачу?" большинство начинает с поиска готовых продуктов и библиотек. Когда готовый продукт решает хотя бы 20% задачи, его имеет смысл использовать. Но тенденция такова, что использовать стремятся любые готовые продукты, если они хоть каким-то боком подходят для решения, а новое делать избегают до последнего. В итоге нередко получается, как в том анекдоте — "нужно погасить газ и вылить из чайника воду.
ЕМ>>Не использую CI/CD, и пока не планирую. S>Использвуешь в виде самописных скриптов для сборки.
У меня нет CI/CD. Я не ставлю задачи выкатить обновление в любое время суток, чтобы оно тут же развернулось у всех пользователей.
S>А система сборки у тебя не знает и ты извращаешься со всякими скриптами.
Так в любом случае нужно извращаться — хоть так, хоть эдак. Разница лишь в том, что извращения вроде CMake — industry standard, а у меня самопал.
S>CMake. И подкдлючается и генерит Makefile.
Который потом нужно прикручивать и к студии в виде отдельного проекта, и к WDK Build System, и даже к своей системе сборки на основе nmake. Мой вариант удобнее хотя бы тем, что простой и полностью свой — не требует изучения и прикручивания дополнительного продукта вроде CMake.
Re[4]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Skorodum, Вы писали:
S>C++ по определению это универсальная землеройная машина с гипердвигателем.
Именно поэтому во многих случаях и не нужна дополнительная.
S>переплаты за универсальный интсрумент нет (особенно на фоне использования С++).
Переплаты бы не было, будь у меня продукт из хотя бы десятка модулей, каждый из которых собирается своими собственными средствами, и надо этим всем управлять централизованно. А пока у меня все текущее собирается из студии, и только в релизах добавляется пара файлов.
S>Даже твои маленькие задачи CMake решит лучше и проще чем твои самописные скрипты.
Каким именно образом? За счет чего?
Re[2]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Евгений Музыченко, Вы писали:
S>это очень уродливое решение. Все это решается системами сборки типа CMake.
Почитал доки на CMake, посмотрел примеры скриптов. Мало где видел более уродливый и запутанный синтаксис. Уж лучше делать на nmake/gmake с привлечением скриптов для cmd/powershell.
Re[3]: Колхозинг по извлечению параметров проекта :)
