Возможно ли в 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-файлы.

[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. Вот тут меня прошу простить, я не разбираюсь в сортах говна

[sharky72]

Цитата Majestio @ 13.10.26, 12:42

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

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

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

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

Ну уважаемый! Не надо так сразу. Я тоже не очень разбираюсь в сортах говна make/cmake/bazel.. Их столько, что всех не перенюхаешь. Есть линуксовое говно, есть виндовое, есть с отдушкой - маковское. Есть вентиляторное - в виде ведроида.
Будьте толерантны. А то от ваших пингвинов тоже смердит и эту вонь не замечают только эскимосы. Проще надо быть. По до что заказали под то и пишем. А то это ваше - я не такая, я жду трамвая - звучит не очень. Тут не платформу обсуждают и не холиварят

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

[Felan]

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

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

Вот это лично мне больше всего нравится, но общественность не поддержала

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

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

Именно что-то такое я и имелл ввиду.

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

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

Во, добавить нечго

И ну да, бывает, заносит

[ЫукпШ]

Цитата Felan @ 14.10.26, 14:49

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

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

Вот это лично мне больше всего нравится, но общественность не поддержала

Просто это не всегда удобно.
И этот вопрос имеет не только теоретический, но и прямой
практический смысл.
---
Рассмотрим "обычный" проект для VS.
Имеем сразу 3 независимых координаты:
Release-Debug,
x86-x64,
ASCII-UNICODE.
Всего, получается, целых 8 конфигураций.
Вручную переключать/пересобирать замучаешься
и ошибешься обязательно. Альтернатива - собрать
все нажатием одной кнопки.

[sharky72]

Почему вручную то? Это настраивается один раз. А потом просто собирается нужная конфигурация солюшена. Хоть через меню, хоть из скрипта.В плане его "координат" разница только в Release/Debug через Configuration Manager). x86/64 и MB/Unicode это уже свойства каждого проекта.

P.S. x86 и MB варианты, например у меня, уже давно не используются.