Возможно ли в VS иметь разный набор исходников для DEBUG и RELEASE конфигурации? , Вопрос по настройкам солюшена\проекта в вижуал студии

[Felan]

Цитата sharky72 @ 08.10.26, 06:02

А зачем вам тогда видеть эти зависимости в основном проекте, если их не собираетесь редактировать? Достаточно прописать include в файле, а в настройках проекта указать другой путь для Include для debug/release.

Так исторически сложилось. И, насколько я понимаю, что бы сгенерить исходники надо что бы был доступ к серверу лицензий для asn компилятора. Вобщем там какие-то полубюрократические сложности... Не знаю. Я понимаю, что есть много обходных путей. Меня итересует конкретный вопрос, можно ли это сделать в VS2026 штаными средствами. Руками редактирвоать файл пректа я не считаю штатным средством.

Цитата sharky72 @ 08.10.26, 06:02

Или как вариант создать два .vcprojx в котором подключены заголовки и сырцы из разных каталогов которые генерит ASN. Оба подключить в один солюшн, а какой проект будет собираться настроить через Configuration Manager (либо через меню Build, либо через контекстное меню на Solution)

Цитата ЫукпШ @ 08.10.26, 10:00

На одном солюшене просто делаем два разных проекта - NameRelease, NameDebug.

Интересная идея.

А вот если проект не содержит вообще никаких файлов, только есть путя для дополнительных инклюдов.... По идее ничего же не собирется тогда?
А если сдеать пустой класс и заинклюдить в него все? Тогда и проект будет один и инклюды настроены по конфигурации...

[ЫукпШ]

Цитата Felan @ 08.10.26, 13:13

А вот если проект не содержит вообще никаких файлов, только есть путя для дополнительных инклюдов.... По идее ничего же не собирется тогда?

Такого я вообще не понимаю..
Для меня такое надо рассматривать на конкретном примере.
Хорошо, сделаем "пустой" модуль с "пустой" процедурой и заинклюдим всё.
Никогда такое не понадобилось, не могу представить, зачем это надо.
Помню, я делал противоположное - много (все) файлов считаются файлами проекта.
На сайте ситфорум-а я обнаружил статью "как можно использовать мэйк".
Используя её, я стал писать не сложные мэйк-файлы которые:
1. собирают проект из указанных папок.
2. все файлы в папке - файлы проекта
3. после компиляции (если нужно) все результаты заносятся в библиотеки.
4. все библиотеки всех папок проекта отдаются линкеру
результаты собираются только из тех модулей, которые нужны для сборки.
Для добавления файла к проекту его достаточно занести в папку проекта.
Удобно.
---
Вообще вся тема выглядит подозрительно и проблемно, и вот почему.
Неоднократно я видел в разных конференциях один и тот же крик
о помощи: "Помогите, debug работает устойчиво, release - нет".
Те надо стремиться к тому, чтобы обе конфигурации были максимально близки,
а не наоборот. Делать разные сборки разными проектами можно.
Но это может оказаться совершенно напрасным. Получится, что
debug фактически тестирует и отлаживает другой проект.
А это значит, что целевой проект остался без дибага.

Сообщение отредактировано: ЫукпШ - 08.10.26, 13:40

[Felan]

Цитата ЫукпШ @ 08.10.26, 13:31

Такого я вообще не понимаю..

Ну тут исторические проблемы + привычка вышестоящих + просто спортивный интерес. Я тут просто посчитал излишним реагировать на колобка, но он, хоть и мимо тазика конкретно тут, но прав. Я уже 2 года пытаюсь убедить начальство перейти на билдсервер. Пока безуспешно. Теперь есть шанс на Гит экшены, но тут опять же компилятору (ASN) нужен доступ к верверу лицензий. Пока не знаю как это можно вообще организовать из гита. Но посколько и переезд еще виллами по воде писан, то и не особо заморачиваюсь.

Цитата ЫукпШ @ 08.10.26, 13:31

Вообще вся тема выглядит подозрительно и проблемно, и вот почему.
Неоднократно я видел в разных конференциях один и тот же крик
о помощи: "Помогите, debug работает устойчиво, release - нет".
Те надо стремиться к тому, чтобы обе конфигурации были максимально близки,
а не наоборот.

Вот я полностю согласен. Но еще раз. Нет проблемы собрать правильно проект.
Тут чисто мой "спортивный" интерес, можно ли подобный выкрутас сделать "штатными настройками Visual Studio 2026". А знаю про билдсерверы, про cmake, про бат файлы, про черта лысыго

У меня конкретный вопрос про VS2026. Может я просто гуглил плохо, а иишечка меня кинула, есть еще какой-то способ...

[ЫукпШ]

Цитата Felan @ 08.10.26, 13:59

Может я просто гуглил плохо, а иишечка меня кинула, есть еще какой-то способ...

Логика ответа на этот вопрос такая:
1. Чтобы собирать проект разными сборками из разных файлов,
надо написать разные make-файлы
2. Работая из VS сделать разные make-файлы можно создавая разные
проекты.
3. Проекты сильно связаны - имеют много общих исходников.
Значит, монтируем их в одном солюшене.
Итого - делаем проекты в одном солюшене с разным набором
файлов и настроек.
4. Другого способа может и не быть, поскольку проблема
уже решается имеющимися средствами.

Как-то так.

[sharky72]

Цитата Felan @ 08.10.26, 13:13

А вот если проект не содержит вообще никаких файлов, только есть путя для дополнительных инклюдов.... По идее ничего же не собирется тогда?
А если сдеать пустой класс и заинклюдить в него все? Тогда и проект будет один и инклюды настроены по конфигурации...

Можно, а зачем? (с)

Если меняются только Include/Lib path то нафига вообще городить огород с дополнительными проектами??? Ну и прописать их в основном проекте для каждого вида билда и не маяться ерундой.
Спортивный интерес он конечно интересен - но потом это выльется в постоянку и перейдет по наследству. Делать надо хорошо, плохо само получится. Решайте административную проблему. А костыли всегда успеете присобачить.

Сообщение отредактировано: sharky72 - 08.10.26, 17:36

[Majestio]

Felan, читал-читал

Мой ИИ мне дал несколько другую инфу. Я попробую ее описать от общего к частностям ...

1. "Да, отвязка от VS-проектов и переход этих двух проектов на CMake — один из самых правильных способов решить именно эту проблему. Это не «костыль», а более подходящий инструмент для config-dependent generated sources."
2. Выбор IDE для удобной работы с cmake-проектами. Увы и ох, я не могу дать точной объективной оценки. Я - фанат QtCreator + MSYS2 (для венды).

Да, и мой ИИ утверждает что IDE VS не совсем полно работает с таким проектами. Может имеет смысл не "ёжики плакали, но жрали кактус", а попробовать что-то иное, кроме VS?! Хотя бы ради эксперимента? Небольшой оффтопик 1998 год. На то время я плотно сидел на Virtual Pascal + TASM. Эта была моя "база" на то время. Потом меня познакомили, вернее заставили познакомится с Clarion DOS/Windows. Шло туго, но потом крайне продуктивно. И потом ... самое интересное, я ради прикола (подчеркну - ради прикола) начал изучать и выучил Perl. Да, сперва, как меня и предупреждали - сцуко "птичий" язык. Но!!! Как-то получилось так, что Perl вот уже 28 лет является языком программирования, на котором хочется не только писать, но и думать! Да, потом были и С/С++, PHP, javascript, Lua, да и вообще ещё много экзотической хрени типа Rexx, Maximus ...

К чему этот мой спич?! Во-первых. Твоя задача наиболее гибко и полно решается cmake-проектами. Во-вторых - не одним VS как IDE красив мир разработчика. Есть варианты:

• Clion (условная оценка 5.0) - Лучшее понимание CMake-модели, generator expressions, targets, custom commands. Удобные профили. Платный, иногда тяжёлый по ресурсам
• Qt Creator (условная оценка 4.5) - Лучшие и самые понятные kits/toolchains. Очень удобно переключать компиляторы, конфигурации, пути, кросс-тулчейны. Хорошая работа с CMake, generated sources и разными build directories. Стабильно и предсказуемо. Code model и рефакторинг слабее, чем у CLion; не такой «умный» по части сложных CMake-конструкций
• Visual Studio (условная оценка 4.5) - Отличная поддержка CMake + multi-config, сильный дебаггер (MSVC). Только Windows, тулчейны менее гибкие, чем в Qt Creator.
• VS Code / VSCodium (условная оценка 4.0) - Гибко, легко, хорошо с CMake Tools и presets. Требует больше ручной настройки kits/toolchains, чем Qt Creator.

Предлагаю абстагироваться (от ёжиков и кактусов) и посмотреть чуть выше на свое "удобство". Дя, я признаю, что топлю за QtCreator, и тому есть аргументы:

• Для задачи «разные исходники / разные папки на Debug и Release» kits + отдельные build directories работают очень естественно и прозрачно;
• Kits — действительно одни из самых вменяемых и простых в настройке среди всех IDE. Можно быстро описать несколько тулчейнов (разные компиляторы, sysroots, кросс-компиляция) и переключаться между ними одним кликом;
• CMake-поддержка у него давно уже не «пристройка», а полноценная и стабильная;
• Всё это бесплатно и кроссплатформенно.

В общем, есть пища "на подумать" Удачи!

[Felan]

Да ЁКЛМН!!!

Госпада. Я благадарен за участие и разносторонние взгляды и попытки наставить меня на пусть истинный. Серьезно. Без сарказма. Мне кажется что в этом участии я и душевности все еще больше на таких форумах чем на SO или у ИИ. И это более ценно.

НО!
Я не ищу правильного способа\совета о том как расположить исходники и как их скомпилировать и т.д. и т.п.
Я знаю про билд серверы, про cmake, и про альтернативные подходы.

Дело не в этом. По разным причинам, в том числе и административным, мы используем то, что используем. Это работало так и будет работать так еще какое-то продолжительное время. Это не обсуждается. Я просто хотел немного облегчить свою жизнь в _данных_и_неизменных_ условиях - VS 2026, штатный файл проекта, только встроенные настройки и билд из VS.

Гуглежь и ИИшечка выдали два варианта которые показались мне очень кривыми. И я решил поинтересоваться у более компетентных людей, есть ли способ сделать это именно штатно в VS. Если его нет - меня это устроит.

Нет так нет. Это тоже результат

Спасибо.

Сообщение отредактировано: Felan - 10.10.26, 19:52

[Qraizer]

Ну как же нет, когда да. Я ж предлагал. Два проекта в солюшне, основной с либой зависит от другого, эту либу создающую, в пребилде которого генерятся сырцы для неё. Что не так-то?

[Majestio]

Цитата Felan @ 10.10.26, 19:51

Да ЁКЛМН!!!

[Felan]

Цитата Qraizer @ 10.10.26, 22:27

Ну как же нет, когда да. Я ж предлагал. Два проекта в солюшне, основной с либой зависит от другого, эту либу создающую, в пребилде которого генерятся сырцы для неё. Что не так-то?

Ну да. Только проблема не в том, что бы либо связать. Она и так связывается правильно. Проблема в том, что сырцы для нее разные. И т.о. мы говорим про настройку "другого" проекта, того который билдит либу. И вопрос не в том ,что бы сбилденную (сбилженную? хз как правильно) либу пложить правильно и всязать основным проектом.

Проблема в том, что эта либо должна билдится из разных исходников для дебага и релиза.

И как помнимаю при одходе с отдельным (фейковым пректом) это должен быть пустой проект, который будет иклюдить разные исходники либы для дебага и релиза.
Но тогда надо бдует сделать какой-то фейковый класс который будет иклюдить исходники либы... Как я понял.

[sharky72]

Зачем делать фейковый проект??? Надо сделать 2 проекта с разными сырцами и подключить их в солюшн к основному проекту. А какой проект будет собираться с релизом/дебагом - выбирать в менеджере конфигураций.
Что проект собирает либу или экзешник - задается в самом проекте.

Сообщение отредактировано: sharky72 - 12.10.26, 08:20

[ЫукпШ]

Цитата sharky72 @ 12.10.26, 08:18

Зачем делать фейковый проект??? Надо сделать 2 проекта с разными сырцами и подключить их в солюшн к основному проекту.

Вероятно, это попытка свести два проекта в один.
Собственно, все так и делают.
Технологии приблизительно такие -
например, у нас есть файл xxmm.cpp:

//
// file xxmm.cpp
// 2026.10.12
//
#ifdef DEBUG
 
#pragma comment (lib, "..\ConfigDebugLib\xxmm.lib")
#include "..\ConfigDebug\xxmm.cpp"
 
#else
 
#pragma comment (lib, "..\ConfigReleaseLib\xxmm.lib")
#include "..\ConfigRelease\xxmm.cpp"
 
#endif

Сообщение отредактировано: ЫукпШ - 12.10.26, 16:28

[Majestio]

Более идиоматичные способы получить тот же эффект (абстрактных классов с общей логикой) - вместо «абстрактных классов» кода C++, в современном CMake обычно используют комбинацию:

1. Общий «базовый» CMake-код (функции/макросы или просто include с общими правилами), типа:
   
   
   

   Генераторные выражения для выбора исходников и опций:cmaketarget_sources(my_target PRIVATE
     common.cpp
     $<$<CONFIG:Debug>:debug_specific.cpp>
     $<$<CONFIG:Release>:release_specific.cpp>
   )
2. Config-specific custom commands для внешних генераторов (с выходом в разные директории, например ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/generated/ или явные Debug/Release подкаталоги).
3. CMakePresets (или toolchain-файлы + пресеты) — чтобы внешний «сценарий» сборки жил отдельно от логики CMakeLists.
4. Иногда — отдельные object-library или interface-library под разные «специализации», которые потом линкуются в финальную цель.

[sharky72]

Имхо изначально вопрос стоял в том МОЖЕТ ли это VS. Может. Просто чел пытается уйти куда-то в область теоритических познаний.
Переход на cmake в какой то мере - это дополнительная сущность без которой можно обойтись. А если уж пошла такая пьянка - то там вообще весь процесс надо перелопачивать. А не довольствоваться полумерами и ожидать перитонита.

Добавлено 13.10.26, 12:21

Цитата ЫукпШ @ 12.10.26, 11:40

Вероятно, это попытка свести два проекта в один.

Вопрос ЗАЧЕМ? Дополнительно прикручиваем себе лазерный прицел для выстрела в ногу?

Сообщение отредактировано: sharky72 - 13.10.26, 12:22

[Majestio]

Цитата sharky72 @ 13.10.26, 12:19

прицел для выстрела в ногу?

Очень четкая ассоциация

Но по сути есть две "цели" - target (цель сборки) + build (вариант сборки debug/release). Компиляция - решается дефайнами в коде, тупо чтобы не плодить копии исходников. CMAKE - сценарии позволяют собирать нужные таргеты и билды, так, как нужно. Это - к гадалке не ходи! Другой вопрос - IDE среда в виде VS. Вот тут меня прошу простить, я не разбираюсь в сортах говна