cheng/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
e3ec9fb124
wxWidgets/wxwidgets.props

136 lines
6.9 KiB
Plaintext
Raw Normal View History

Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
<?xml version="1.0" encoding="utf-8"?>
<!--
This is a property sheet to be included in MSVS projects of the applications
using wxWidgets. Use "View|Property Manager" and choose "Add Existing
Property Sheet..." from the context menu to add it from the IDE or edit your
Really close the <Import> tag in the comment in wxwidgets.props Corrects a mistake introduced in a supposed fix in commit a27a7e0, where the XML-tag-closing slash was wrongly places inside the quotes. Closes https://github.com/wxWidgets/wxWidgets/pull/1870
2020-05-25 12:19:43 -04:00
.vcxproj file directly and add <Import Project="$(WXWIN)\wxwidgets.props" />
Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
tag to it.
-->
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
<Project ToolsVersion="4.0" InitialTargets="CheckWXLibs" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Use nicer labels for wxWidgets property sheets in MSVS UI No real changes, just use the same _PropertySheetDisplayName element as the standard style sheets use to show a slightly more user-friendly label in the Property Sheet manager window in MSVS.
2021-04-14 10:44:09 -04:00
<PropertyGroup>
<_PropertySheetDisplayName>wxWidgets</_PropertySheetDisplayName>
</PropertyGroup>
Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
<ImportGroup Label="PropertySheets">
<Import Project="build/msw/wx_setup.props" />
<Import Project="build/msw/wx_local.props" Condition="exists('build/msw/wx_local.props')" />
</ImportGroup>
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
<PropertyGroup Label="UserMacros">
<!--
We have several possible choices for the compiler prefix:
- Default one is "vc", we want to use this to allow building this project
when wx was built from source with the default options.
- Version-specific prefix of the form "vcNNN", which is used in some other
projects.
- Version-specific but ABI-compatible prefix which differs from the
Support for VS 2022 in wxwidgets.props
2021-09-27 08:21:28 -04:00
previous value in that it's the same "vc14x" for MSVS 2015/2017/2019/2022
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
which are ABI-compatible with each other. This is used by official wx
binaries, so we want to check this one too.
-->
<wxToolsetVersion Condition="'$(VisualStudioVersion)' == '10.0'">100</wxToolsetVersion>
<wxToolsetVersion Condition="'$(VisualStudioVersion)' == '11.0'">110</wxToolsetVersion>
<wxToolsetVersion Condition="'$(VisualStudioVersion)' == '12.0'">120</wxToolsetVersion>
<wxToolsetVersion Condition="'$(VisualStudioVersion)' == '14.0'">140</wxToolsetVersion>
<wxToolsetVersion Condition="'$(VisualStudioVersion)' == '15.0'">141</wxToolsetVersion>
<wxToolsetVersion Condition="'$(VisualStudioVersion)' == '16.0'">142</wxToolsetVersion>
Support for VS 2022 in wxwidgets.props
2021-09-27 08:21:28 -04:00
<wxToolsetVersion Condition="'$(VisualStudioVersion)' == '17.0'">143</wxToolsetVersion>
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
<wxToolsetVerABICompat Condition="'$(VisualStudioVersion)' == '10.0'">100</wxToolsetVerABICompat>
<wxToolsetVerABICompat Condition="'$(VisualStudioVersion)' == '11.0'">110</wxToolsetVerABICompat>
<wxToolsetVerABICompat Condition="'$(VisualStudioVersion)' == '12.0'">120</wxToolsetVerABICompat>
<wxToolsetVerABICompat Condition="'$(VisualStudioVersion)' == '14.0'">14x</wxToolsetVerABICompat>
<wxToolsetVerABICompat Condition="'$(VisualStudioVersion)' == '15.0'">14x</wxToolsetVerABICompat>
<wxToolsetVerABICompat Condition="'$(VisualStudioVersion)' == '16.0'">14x</wxToolsetVerABICompat>
Support for VS 2022 in wxwidgets.props
2021-09-27 08:21:28 -04:00
<wxToolsetVerABICompat Condition="'$(VisualStudioVersion)' == '17.0'">14x</wxToolsetVerABICompat>
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
</PropertyGroup>
<!--
Try to find some existing wxWidgets libraries.
Note that we use wxBaseLibNamePrefix for both static libs and DLL cases,
it's simpler than constructing the DLL name and still works as we must have
the import library with this name in the DLL directory too.
-->
<Choose>
<When Condition="Exists('$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVerABICompat)$(wxArchSuffix)_dll$(wxCfg)\$(wxBaseLibNamePrefix).lib')">
<PropertyGroup Label="UserMacros">
<wxUsingVersionABICompat>1</wxUsingVersionABICompat>
<wxUsingDll>1</wxUsingDll>
<wxLibOrDllDir>$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVerABICompat)$(wxArchSuffix)_dll$(wxCfg)</wxLibOrDllDir>
</PropertyGroup>
</When>
<When Condition="Exists('$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVerABICompat)$(wxArchSuffix)_lib$(wxCfg)\$(wxBaseLibNamePrefix).lib')">
<PropertyGroup Label="UserMacros">
<wxUsingVersionABICompat>1</wxUsingVersionABICompat>
<wxUsingLib>1</wxUsingLib>
<wxLibOrDllDir>$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVerABICompat)$(wxArchSuffix)_lib$(wxCfg)</wxLibOrDllDir>
</PropertyGroup>
</When>
<When Condition="Exists('$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVersion)$(wxArchSuffix)_dll$(wxCfg)\$(wxBaseLibNamePrefix).lib')">
<PropertyGroup Label="UserMacros">
<wxUsingVersion>1</wxUsingVersion>
<wxUsingDll>1</wxUsingDll>
<wxLibOrDllDir>$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVersion)$(wxArchSuffix)_dll$(wxCfg)</wxLibOrDllDir>
</PropertyGroup>
</When>
<When Condition="Exists('$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVersion)$(wxArchSuffix)_lib$(wxCfg)\$(wxBaseLibNamePrefix).lib')">
<PropertyGroup Label="UserMacros">
<wxUsingVersion>1</wxUsingVersion>
<wxUsingLib>1</wxUsingLib>
<wxLibOrDllDir>$(MSBuildThisFileDirectory)lib\vc$(wxToolsetVersion)$(wxArchSuffix)_lib$(wxCfg)</wxLibOrDllDir>
</PropertyGroup>
</When>
<When Condition="Exists('$(MSBuildThisFileDirectory)lib\vc$(wxArchSuffix)_dll$(wxCfg)\$(wxBaseLibNamePrefix).lib')">
<PropertyGroup Label="UserMacros">
<wxUsingDll>1</wxUsingDll>
<wxLibOrDllDir>$(MSBuildThisFileDirectory)lib\vc$(wxArchSuffix)_dll$(wxCfg)</wxLibOrDllDir>
</PropertyGroup>
</When>
<When Condition="Exists('$(MSBuildThisFileDirectory)lib\vc$(wxArchSuffix)_lib$(wxCfg)\$(wxBaseLibNamePrefix).lib')">
<PropertyGroup Label="UserMacros">
<wxUsingLib>1</wxUsingLib>
<wxLibOrDllDir>$(MSBuildThisFileDirectory)lib\vc$(wxArchSuffix)_lib$(wxCfg)</wxLibOrDllDir>
</PropertyGroup>
</When>
</Choose>
<PropertyGroup Label="UserMacros" Condition="$(wxUsingVersionABICompat) != ''">
<wxVersionDefine>wxMSVC_VERSION_AUTO;wxMSVC_VERSION_ABI_COMPAT</wxVersionDefine>
</PropertyGroup>
<PropertyGroup Label="UserMacros" Condition="$(wxUsingVersion) != ''">
<wxVersionDefine>wxMSVC_VERSION_AUTO</wxVersionDefine>
</PropertyGroup>
<PropertyGroup Label="UserMacros" Condition="$(wxUsingDll) != ''">
Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
<wxUsingDllDefine>WXUSINGDLL</wxUsingDllDefine>
</PropertyGroup>
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
<Target Name="CheckWXLibs">
<Error
Condition="'$(wxUsingDll)$(wxUsingLib)' == ''"
Text="wxWidgets libraries not found under &quot;$(MSBuildThisFileDirectory)lib&quot;." />
</Target>
Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
<ItemDefinitionGroup>
<ClCompile>
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
<PreprocessorDefinitions>__WXMSW__;$(wxUsingDllDefine);$(wxVersionDefine);%(PreprocessorDefinitions)</PreprocessorDefinitions>
Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
<AdditionalIncludeDirectories>$(MSBuildThisFileDirectory)include\msvc;$(MSBuildThisFileDirectory)include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>__WXMSW__;$(wxUsingDllDefine);%(PreprocessorDefinitions)</PreprocessorDefinitions>
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
<AdditionalIncludeDirectories>$(wxLibOrDllDir)\$(wxToolkitPrefix)$(wxSuffix);$(MSBuildThisFileDirectory)include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
</ResourceCompile>
<Link>
Make props file work for builds using any prefix/DLL combinations The existing wxwidgets.props wasn't particularly useful as it couldn't be used with with wx DLLs when the user project configuration were not called "DLL Debug" or "DLL Release" (and it makes little sense for the user application to use "DLL" in its configuration names just because it happens to use wx as DLL, of course). It also couldn't be used with the libraries built using nmake with a custom COMPILER_PREFIX, which, significantly, includes the official MSW binaries. Try to fix both problems by checking for the actually existing libraries and using whichever ones we find. This is somewhat surprising for a project file to do, but it seems like it should result in the most useful behaviour in practice as it allows user projects importing this file to work out of the box in all of the following situations: - Using official wxMSW binaries. - Building wxMSW from source without any customization. - Building wxMSW from source using reasonable custom compiler prefix.
2020-05-18 18:43:37 -04:00
<AdditionalLibraryDirectories>$(wxLibOrDllDir);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
Add property sheet to allow easily configure projects using wx This seems to be the simplest possible way to let a MSVS project use the library.
2018-11-08 20:00:16 -05:00
</Link>
</ItemDefinitionGroup>
</Project>
Reference in New Issue Copy Permalink