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

[Felan]

Здравствуйте.

Гуглеж и ИИ дали определенный ответ. Но како-то он мне не нравится. Предлагается либо использовать какие-то странные файлы дополнительных свойств либо ручками редактировать фала проекта. Я допускаю, что другого варианта нет, но малоли, может я просто не с той стороны захожу.

Дело в том, что есть большой солюшен. В нем два проекта исходники которых полностью генерятся сторонним компилятором по пребилд эвенту. Эти сгенеренные исходники немного отличаются в дебаг и релиз конфигурациях потому что генерятся с разными ключами. Но они генерятся в одну и ту же папку, что бы проект мог их правильно собрать в статическую библиотеку. Библиотека тоже зависит от конфига. Но это нормально разруливается в обычных свойствах проекта.

И получается что в гит в той же самой папке попадают разные версии сгенеренных исходников, в зависимости от того, какую конфигурацию билдили последней. Не то, что бы большая проблема, но последнее время стало сильно раздражать.

Получаетя где-то так.

1 Билд проекта (Разные настройки для дебаг и релиз)
1.а Пребилд евент для генерации исходников в папку src (одна и та же папка)
1.b Билд проекта по исходникам в папке src (разные настройки для дебаг и релиз)
1.с Получение результата (разный для дебаг и релиз)


Хотелось бы так что бы 1.б складывал сгенеренные исходники в свои папки src/debug и src/release, а 1.б подхватывал бы нужные.

Но я не нашел способа добавить в проект фалы по разным путям в зависимости от конфигурации билда.

ИИ предлагает либо добавлять дополнительные файлы свойств где будет разные пути до исходников или напрямую редактировать файл проекта. Первое делать не хочется, а второе противно натуре. И еще не понятно как при этом будут добавлены файлы в проект и как будут отображаться в Солюшен эксплорере.

Какие могут быть еще варианты?

ПС: Убедительная просьба, генерить в разные папки и в пребилде копировать в общую не предлагать.

[Qraizer]

M

Тема перенесена из C/C++ => C/C++: Общие вопросы

Сообщение на автоудалении

[sharky72]

1. Если это генерируемые файлы - зачем их хранить в GIT?
2. Что мешает в свойствах проекта завести разные папки Include/Lib для каждого типа билда. Вплоть до 32/64 MB/Uncode
3. Можно рассмотреть вариант с package. Например conan/vcpkg. В нем как раз можно разрулить debug/release варианты. Ну и по сборке будет немного проще.

[Felan]

Цитата sharky72 @ 03.10.26, 17:22

1. Если это генерируемые файлы - зачем их хранить в GIT?

Хм... ну вообще вариант пожалуй... Хотя тут придется убедить несколько людей которые привыкли что они там. Только сейчас подумал, может вообще их отдельными длл, а просто добавить их в другой проект... Но тут тоже надо будет преодолеть административные барьеры.

Цитата sharky72 @ 03.10.26, 17:22

2. Что мешает в свойствах проекта завести разные папки Include/Lib для каждого типа билда. Вплоть до 32/64 MB/Uncode

Ну потому, что они не инклюды, они и есть весь проект. Если их убрать из проекта и оставить инклюдами, то вообще нечего будет собирать в проекте, не уверен как это будет работать.

Цитата sharky72 @ 03.10.26, 17:22

3. Можно рассмотреть вариант с package. Например conan/vcpkg. В нем как раз можно разрулить debug/release варианты. Ну и по сборке будет немного проще.

А вот тут по подробнее можно?

[sharky72]

1. Административное решение зачастую проще программного
3. Погуглите что такое пакетные менеджеры. Но это решение хорошо если внешние проекты не очень часто меняются и имеют версирование. Например есть несколько команд которые работают над своей частью проекта. Периодически его релизят в виде пакета, а в своем проекте посто подключается пакет нужной версии. Он может быть как уже откомпилирован в виде lib/o/dll/so и имеет необходимые include, или поставляться в исходниках и собирается при сборке основного проекта. На разных проекта в основном использовали conan. Для своих поделок - я остановился на vcpkg. Избавило от необходимости самому собирать boost/fmt/etc.

Сообщение отредактировано: sharky72 - 04.10.26, 10:42

[Felan]

Цитата sharky72 @ 04.10.26, 10:40

3. Погуглите что такое пакетные менеджеры.

Видимо в нашем случае это перебор.

Цитата sharky72 @ 04.10.26, 10:40

1. Административное решение зачастую проще программного

Эх, пойдем этим путем значитцца.

[Qraizer]

Стандартной практикой является (являлось?) декомпозиция проекта на два и установление зависимости одного от другого. Первый пребилдится и создаёт либу, второй эту либу юзает. Разные либы разнести по разным конфигурациям труда не составляет.
Проблемой может стать непостоянный набор сырцов пребилда. Если тулзя генерит не просто разные сырцы, а вообще набор исходников, то дерево его проекта не построить. Тут легко выручает make.

[Felan]

Ну да. Это не билд либы. Это билд именно исходников. Ну не билд, а генерация. Генерит их тулза вообще не сишная и не VS. Это ASN.1 компилятор, если о чем нибудь говорит. Набор файлов один и тот же. Но всякие ньюансы классов разные из-за разных настроек для дебага и релиза.

Я искал "удобный мне" путь именно в настройках VS.

[sharky72]

Ну хорошо, а эти исходники компиляются основным проектом? Как они включаются в сборку? В виде только .h или еще и .cpp файлов?
Можно их собрать в виде либы или dll?

В конце концов можно действительно обойтись CMAKE который будет генерить проект который будет включен в solution (хотя это очень коряво).

[Felan]

Ну есть некая конфигурация написанная на ASN.1. Этот файл скармливается некоему компилятору, на выходе получается набор .h и .cpp. В дебаге и в релезе у компилятора разные параметры, собственно поэтому и отличаются полученные исходники. Набор фалов один и тот же. Содержимое немного отличается. И вот из этих исходников надо уже собрать библиотеку.

Сейчас компилятор ASN.1 просто кладет папку src и из них билдится статическая библиотека. Ну там есть еще немного кода который рачками в проект дописан и использует сгенеренные исходники.

Сечас получается, что в дебаге генерятся исходники для дебага, и с ними собирается библиотека. А в релизе исходники перезаписываются и с ними собирается библиотека.

Хотелось бы что бы сгенерились обе версии исходников (это не проблема) и что бы именно проект vs выбирал какую версию в каком режиме испольновать.

[sharky72]

Ну так просто прописать компилеру ASN разные пути для генерации .h/.cpp и разный путь для собраной /lib. Хотя бы просто батник написать который будет задавать нужные пути. И это батник запускать в Prebuild, вплотть до генерации обеих вариантов либины. Далее в настройках проекта делаются разные пути Include/lib для debug/release и все.

[Felan]

ну так в принципе и есть. Вот вызывается из custom build action ASN и генерит .h/.cpp. Они попадают в папку src из которой они добавлены в проект VS.

В кастом билд экшоне есть разделение на то, какой конфиг сейчас, дебаг или релиз. Нет проблемы распихать их в разные папки. Но как их добавить в проект в зависимости от текущего кофига?

Я понимаю, что сторонними средствами без проблем можно разные пути указать. Даже можно в файле проекта, или доплнительными свойстваи их задать. Но это ручками надо править эти файлы.

Вопрос в том, можно ли как то это сделать из VS и что бы билд из VS работал правильно.

Вопрос не в том, как вообще скормить разные исходники. Это понятно и не проблема.

Вопрос в том, можно ли как то это сделать штатными средствами VS 2026.

[sharky72]

А зачем вам тогда видеть эти зависимости в основном проекте, если их не собираетесь редактировать? Достаточно прописать include в файле, а в настройках проекта указать другой путь для Include для debug/release.
Или как вариант создать два .vcprojx в котором подключены заголовки и сырцы из разных каталогов которые генерит ASN. Оба подключить в один солюшн, а какой проект будет собираться настроить через Configuration Manager (либо через меню Build, либо через контекстное меню на Solution)

[kolobok0]

Цитата Felan @ 08.10.26, 05:03

...сделать штатными средствами VS 2026.

Ну и когда Вы дойдёте до понимания, что по современным требованиям безопасности всё должно собирать автоматика и на серверах, то Вы уже этот чумудан без ручки жалко будет утилизировать. Такие хотелки обычно идут от не образованности. Локальное требование сборки - это чиссо пользовательская история (читай разработчиков), ну и тупик....

Удачи Вам
она вам потребуется
(круглый)
ЗЫ
Кстати на серваке замечательно идёт cmake (как тут выше прозвучало). Ну а локально его замечательно кушает (и на лету поддерживает!!!) единственная IDE QtCreator.

[ЫукпШ]

Цитата Felan @ 02.10.26, 21:19

Гуглеж и ИИ дали определенный ответ. Но како-то он мне не нравится. Предлагается либо использовать какие-то странные файлы дополнительных свойств либо ручками редактировать фала проекта.

На одном солюшене просто делаем два разных проекта - NameRelease, NameDebug.
Набор файлов для них может быть самым разнообразным для каждой версии сборки.
Могут быть и разные файлы, и общие. Всё, что нужно.

Для утилиты командной строки make можно сделать разные make-файлы.