[EDIT] ==>
Для пояснения: в тех средах, где несколько целей развернуты в одном каталоге, Planet Earth приняла решение о добавлении «d» или «_d» или «_debug» к версии «DEBUG». (из библиотеки или исполняемого файла). Такое соглашение можно считать «вездесущим» и «понятым», хотя (конечно) не каждый делает это.
ПОНИМАТЕЛЬНО, чтобы разрешить неоднозначность между «разделяемой» и «статической» версиями библиотеки, общепринятым условием является добавление чего-либо для различия между static-and-shared (например, «myfile.lib» для shared-import-lib). -on-Windows и "myfile_s.lib" для статического импорта-lib-on-Windows). Хотя Posix не имеет этой неоднозначности, основанной на расширении файла, помните, что расширение файла не используется в «строке ссылки», поэтому также полезно иметь возможность явно указывать «статическую» или «общую» версию библиотеки .
Для целей этого вопроса и "debug/release", и "static/shared" повышены до "повсеместного соглашения для украшения корня имени файла" .
ВОПРОС: Получается ли какая-либо другая конфигурация развертывания "повышена" до этого уровня "вездесущего соглашения", чтобы она стала явной в имени целевого корневого файла?
Мое текущее предположение "нет". Чтобы ответ был «Да», потребовалось бы: «Использовать» более одной конфигурации для данной цели (и, следовательно, развернуть ее в общем каталоге, который является предполагаемой основой для вопроса).
Раньше мы компилировали с возможностью «и без веб-плагина» и без нее, для которой аналогично требовалось оформление имени, но мы больше не строили эти цели (поэтому я не буду утверждать это в качестве примера). Точно так же мы иногда компилируем с поддержкой и без поддержки многобайтовых символов, но я ненавижу это, поэтому я не буду утверждать это тоже.
[ОРИГИНАЛЬНЫЙ ВОПРОС]
Мы устанавливаем соглашения об именах библиотек / policy, для применения на разных языках и платформах (например, мы поддерживаем гибридные продукты, использующие несколько языков на разных платформах, включая C / C ++ , C #, Java). Особой целью является обеспечение того, чтобы мы обрабатывали цели / ресурсы для мобильной разработки (что является для нас новым) в дополнение к нашим традиционным настольным (и встроенным) приложениям.
Конечно, опция one должна иметь разные пути для целей из разных конфигураций сборки. Для целей этого вопроса принято решение о размещении всех целей в одном каталоге и «украшении» имени библиотеки / ресурса / исполняемого файла, чтобы избежать коллизий на основе конфигурации сборки (например, «DEBUG» v. "RELEASE", "static lib" v. "Shared / DLL" и т. Д.)
Текущее решение аналогично другим в сети, где мы добавляем токены, чтобы избежать коллизий имен:
MyName.lib (release build, import for shared/dll)
MyName_s.lib (release build, static lib)
MyName_d.lib (debug build, import for shared/DLL)
MyName_ud.lib (Unicode/wide-char, debug, import for shared/DLL)
MyName_usd.lib (Unicode/wide-char, static lib, debug)
(Выше приведены примеры Windows, но эти политики также применимы к нашим системам POSIX.)
Они основаны на:
d (release or debug)
u (ASCII or Unicode/wide-char)
s (shared/DLL or static-lib)
ВОПРОС: У нас нет устаревших приложений, которые должны быть скомпилированы однопоточными, и я понимаю, что (в отличие от Microsoft) системы POSIX могут связывать однопоточные и многопоточные цели в одно приложение без вопрос. Учитывая сегодняшнее стремление к многоядерности и многопоточности, Есть ли необходимость в крупном предприятии , чтобы установить следующее для идентификации скомпилированных целей «одно-» против «многопоточных»?
t (single-threaded or multi-threaded) *(??needed??)*
... и мы пропустили любое другое столкновение с целью, например, компиляцию с STL и без него (на C ++)?
Кроме того, у Microsoft есть соглашения об именах библиотек по адресу:
http://msdn.microsoft.com/en-us/library/aa270400(v=vs.60).aspx и их соглашения об именах DLL по адресу: http://msdn.microsoft.com/en-us/library/aa270964(v=vs.60).aspx
Подобный вопрос о SO год назад, в котором не говорилось о многопоточности и не ссылались на соглашения Microsoft, можно найти по адресу: Что такое правильное соглашение об именах для библиотек MSVC, статических библиотек и библиотек импорта