минимально извращенный способ извлечения в командном файле 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[7]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Может всё-таки сделать как обычно. Сделать файл манифеста проекта где описаны все параметры и зависимости и из него генерировать заголовки, а не наоборот.
ЕМ>. Сомневаюсь, что кто-то в здравом уме стал бы делать его сугубо для внутренних целей.
А что смущает ?
Re[8]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, Михaил, Вы писали:
_>>>Сделать файл манифеста проекта
ЕМ>>Сомневаюсь, что кто-то в здравом уме стал бы делать его сугубо для внутренних целей.
М>А что смущает ?
Чрезмерный уровень сложности. Имеет смысл лишь при наличии удобных встроенных средств как создания/редактирования, так для парсинга/обработки XML.
Мне это нужно для автоматизации построения параметризованных продуктов при помощи командных файлов, чтобы не дублировать одни и те же параметры в разных местах.
То, да, это очень уродливое решение. Все это решается системами сборки типа 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()
Здравствуйте, 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-битную крышу
Сомневаюсь, что когда-нибудь сумею увидеть это упирание на своих проектах.
Средне-извращенный у меня уже много лет был (прямой парсинг заголовков с обрезкой кавычек, если есть). Он мне не нравился тем, что не умел склеивать строки, отчего нельзя было определять производные параметры через определенные ранее (например, название продукта фигурирует в именах ряда экспортируемых объектов).
