Здравствуйте, Евгений Музыченко, Вы писали:
У>>Про 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 синдрома у С++ разработчиков. Он же во всем, а причин для него реально ноль
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, удусекшл, Вы писали:
У>>Чего тут геморрного?
ЕМ>Например, то, что для всех внешних скриптов, использующих параметры через запуск обсуждаемой вспомогательной программы, потребуется обеспечить их соответствие в заголовках и в 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 который тоже далеко не идеал, но проблемы на подобее вашей там решаются просто.
В общем я категорически против пропаганды и распространения решений подобных вашему, это вред для отрасли. Хотя с другой стороны надо посмотреть на это как "больше возможностей для меня"
Re[2]: Колхозинг по извлечению параметров проекта :)
Здравствуйте, 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]: Колхозинг по извлечению параметров проекта :)
Во многих из моих задач требуется менять стандартные параметры на нестандартные, и я имел достаточно геморроя с автоматизированными системами сборки, которые сложнее make/nmake. Например, в DDK/WDK была утилита Build, которая работала поверх nmake. Для простых типовых проектов — очень удобно, но шаг влево/вправо, и сразу геморрой в полный рост. Я на борьбу с ее особенностями в совокупности потратил столько времени, что можно было написать собственную. 
