luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-10 19:36:18 +01:00
Code Issues Packages Projects Releases Wiki Activity
7d64d109f0
glib/win32/vs10/glib-install.vcxproj

189 lines
11 KiB
XML
Raw Normal View History

Visual Studio Projects: Use Unix Line Endings ...where possible, to make application of patches easier in the future. The README.txt's and the .sln files are still in Windows/DOS line endings as they need to be so.
2013-12-27 03:50:35 +01:00
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|Win32">
<Configuration>Release</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{2093D218-190E-4194-9421-3BA7CBF33B10}</ProjectGuid>
MSVC Builds: Rename "install" Projects Rename the project to "install" the GLib files, as we are planning to have a grand solution file that would build the entire GTK+ stack with its deps, to ease the process for people building the GTK+ stack from a stock installation of Visual Studio.
2015-02-02 05:49:42 +01:00
<RootNamespace>glibinstall</RootNamespace>
Visual Studio Projects: Use Unix Line Endings ...where possible, to make application of patches easier in the future. The README.txt's and the .sln files are still in Windows/DOS line endings as they need to be so.
2013-12-27 03:50:35 +01:00
<Keyword>Win32Proj</Keyword>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration">
<ConfigurationType>Utility</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>true</WholeProgramOptimization>
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<ConfigurationType>Utility</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>Utility</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>true</WholeProgramOptimization>
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<ConfigurationType>Utility</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="glib-install.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="glib-install.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="glib-install.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="glib-install.props" />
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
Visual Studio builds: Move project files to win32/ It was suggested that the project files be moved here as we don't actually need to go two directory layers from $(srcroot), and would help us to standardize on things in the future across the board.
2017-01-09 07:00:46 +01:00
<OutDir Condition="'$(Configuration)'=='Debug'">$(GlibEtcInstallRoot)\</OutDir>
<ExtensionsToDeleteOnClean Condition="'$(Configuration)'=='Debug'" />
<OutDir Condition="'$(Configuration)'=='Release'">$(GlibEtcInstallRoot)\</OutDir>
<ExtensionsToDeleteOnClean Condition="'$(Configuration)'=='Release'" />
Visual Studio Projects: Use Unix Line Endings ...where possible, to make application of patches easier in the future. The README.txt's and the .sln files are still in Windows/DOS line endings as they need to be so.
2013-12-27 03:50:35 +01:00
</PropertyGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
</ItemDefinitionGroup>
MSVC 2010+ Projects: Update "Installation" Process Currently, due to the way that Visual Studio 2010+ projects are handled, the "install" project does not re-build upon changes to the sources, as it does not believe that its dependencies have changed, although the changed sources are automatically recompiled. This means that if a part or more of the solution does not build, or if the sources need some other fixes or enhancements, the up-to-date build is not copied automatically, which can be misleading. Improve on the situation by forcing the "install" project to trigger its rebuild, so that the updated binaries can be copied. This does trigger an MSBuild warning, but having that warning is way better than not having an up-to-date build, especially during testing and development.
2014-06-09 04:27:36 +02:00
<ItemGroup>
MSVC builds: Add scripts to generate .pc files Add a generic script, pc_base.py, which can be utilized to obtain path info, along with user-input version info, which can be used to generate pkg-config .pc files. Also enhance replace.py a bit so that it can also be used in the future to replace multiple items in a file in one shot. This is done to make building introspection files easier, as it depends much on the pkg-config .pc files to work. Update the project files so that when Python is available, we can generate the full, usable .pc files when we complete and 'install' the builds, and copy them to appropriate locations so that pkg-config can be set to find them easily.
2016-03-10 13:33:35 +01:00
<CustomBuild Include="..\glibpc.py">
Visual Studio builds: Move project files to win32/ It was suggested that the project files be moved here as we don't actually need to go two directory layers from $(srcroot), and would help us to standardize on things in the future across the board.
2017-01-09 07:00:46 +01:00
<Message Condition="'$(Configuration)'=='Debug'">Generating .pc files...</Message>
<Command Condition="'$(Configuration)'=='Debug'">$(GlibGenPC)</Command>
<Outputs Condition="'$(Configuration)'=='Debug'">$(GlibPCFiles);%(Outputs)</Outputs>
<Message Condition="'$(Configuration)'=='Release'">Generating .pc files...</Message>
<Command Condition="'$(Configuration)'=='Release'">$(GlibGenPC)</Command>
<Outputs Condition="'$(Configuration)'=='Release'">$(GlibPCFiles);%(Outputs)</Outputs>
MSVC builds: Add scripts to generate .pc files Add a generic script, pc_base.py, which can be utilized to obtain path info, along with user-input version info, which can be used to generate pkg-config .pc files. Also enhance replace.py a bit so that it can also be used in the future to replace multiple items in a file in one shot. This is done to make building introspection files easier, as it depends much on the pkg-config .pc files to work. Update the project files so that when Python is available, we can generate the full, usable .pc files when we complete and 'install' the builds, and copy them to appropriate locations so that pkg-config can be set to find them easily.
2016-03-10 13:33:35 +01:00
</CustomBuild>
Visual Studio builds: Redo utility script generation Use the new gen_util_scripts.py script to generate the glib-mkenums and gdbus-codegen scripts with the proper info in them so that they can be used properly by other build systems such as Meson, during "install".
2017-05-24 09:43:59 +02:00
<CustomBuild Include="..\..\gobject\glib-mkenums.in">
<Message Condition="'$(Configuration)'=='Debug'">Generating glib-mkenums...</Message>
<Command Condition="'$(Configuration)'=='Debug'">$(GenGLibMKEnums)</Command>
<Outputs Condition="'$(Configuration)'=='Debug'">..\..\gobject\glib-mkenums;%(Outputs)</Outputs>
<Message Condition="'$(Configuration)'=='Release'">Generating glib-mkenums...</Message>
<Command Condition="'$(Configuration)'=='Release'">$(GenGLibMKEnums)</Command>
<Outputs Condition="'$(Configuration)'=='Release'">..\..\gobject\glib-mkenums;%(Outputs)</Outputs>
</CustomBuild>
win32: Update MSVC projects for glib-genmarshal glib-genmarshal is now a Python script instead of a compiled program, so we need to: -Remove the projects that are used to build the glib-genmarshal sources. -Generate the full glib-genmarshal Python script from glib-genmarshal.in -Make Python a hard build-time requirement, since we use this tool in many parts of the stack (and it is the case for glib-mkenums). -Tell people in the Visual Studio build README.txt files that Python 2.7.x or 3.x is now required for the build/"install".
2017-07-12 05:45:34 +02:00
<CustomBuild Include="..\..\gobject\glib-genmarshal.in">
<Message Condition="'$(Configuration)'=='Debug'">Generating glib-genmarshal...</Message>
<Command Condition="'$(Configuration)'=='Debug'">$(GenGLibGenmarshal)</Command>
<Outputs Condition="'$(Configuration)'=='Debug'">..\..\gobject\glib-genmarshal;%(Outputs)</Outputs>
<Message Condition="'$(Configuration)'=='Release'">Generating glib-genmarshal...</Message>
<Command Condition="'$(Configuration)'=='Release'">$(GenGLibGenmarshal)</Command>
<Outputs Condition="'$(Configuration)'=='Release'">..\..\gobject\glib-genmarshal;%(Outputs)</Outputs>
</CustomBuild>
Visual Studio builds: Redo utility script generation Use the new gen_util_scripts.py script to generate the glib-mkenums and gdbus-codegen scripts with the proper info in them so that they can be used properly by other build systems such as Meson, during "install".
2017-05-24 09:43:59 +02:00
<CustomBuild Include="..\..\gio\gdbus-2.0\codegen\gdbus-codegen.in">
<Message Condition="'$(Configuration)'=='Debug'">Generating gdbus-codegen...</Message>
<Command Condition="'$(Configuration)'=='Debug'">$(GenGDBusCodegen)</Command>
<Outputs Condition="'$(Configuration)'=='Debug'">..\..\gio\gdbus-2.0\codegen\gdbus-codegen;%(Outputs)</Outputs>
<Message Condition="'$(Configuration)'=='Release'">Generating gdbus-codegen...</Message>
<Command Condition="'$(Configuration)'=='Release'">$(GenGDBusCodegen)</Command>
<Outputs Condition="'$(Configuration)'=='Release'">..\..\gio\gdbus-2.0\codegen\gdbus-codegen;%(Outputs)</Outputs>
</CustomBuild>
<CustomBuild Include="glib_install_placeholder">
Visual Studio builds: Move project files to win32/ It was suggested that the project files be moved here as we don't actually need to go two directory layers from $(srcroot), and would help us to standardize on things in the future across the board.
2017-01-09 07:00:46 +01:00
<Message Condition="'$(Configuration)'=='Debug'">Installing Build Results...</Message>
Visual Studio builds: Redo utility script generation Use the new gen_util_scripts.py script to generate the glib-mkenums and gdbus-codegen scripts with the proper info in them so that they can be used properly by other build systems such as Meson, during "install".
2017-05-24 09:43:59 +02:00
<AdditionalInputs Condition="'$(Configuration)'=='Debug'">$(GlibPCFiles);$(GlibUtilScripts)</AdditionalInputs>
Visual Studio builds: Move project files to win32/ It was suggested that the project files be moved here as we don't actually need to go two directory layers from $(srcroot), and would help us to standardize on things in the future across the board.
2017-01-09 07:00:46 +01:00
<Command Condition="'$(Configuration)'=='Debug'">$(GlibDoInstall)</Command>
<Outputs Condition="'$(Configuration)'=='Debug'">blah;%(Outputs)</Outputs>
<Message Condition="'$(Configuration)'=='Release'">Installing Build Results...</Message>
Visual Studio builds: Redo utility script generation Use the new gen_util_scripts.py script to generate the glib-mkenums and gdbus-codegen scripts with the proper info in them so that they can be used properly by other build systems such as Meson, during "install".
2017-05-24 09:43:59 +02:00
<AdditionalInputs Condition="'$(Configuration)'=='Release'">$(GlibPCFiles);$(GlibUtilScripts)</AdditionalInputs>
Visual Studio builds: Move project files to win32/ It was suggested that the project files be moved here as we don't actually need to go two directory layers from $(srcroot), and would help us to standardize on things in the future across the board.
2017-01-09 07:00:46 +01:00
<Command Condition="'$(Configuration)'=='Release'">$(GlibDoInstall)</Command>
<Outputs Condition="'$(Configuration)'=='Release'">blah;%(Outputs)</Outputs>
MSVC 2010+ Projects: Update "Installation" Process Currently, due to the way that Visual Studio 2010+ projects are handled, the "install" project does not re-build upon changes to the sources, as it does not believe that its dependencies have changed, although the changed sources are automatically recompiled. This means that if a part or more of the solution does not build, or if the sources need some other fixes or enhancements, the up-to-date build is not copied automatically, which can be misleading. Improve on the situation by forcing the "install" project to trigger its rebuild, so that the updated binaries can be copied. This does trigger an MSBuild warning, but having that warning is way better than not having an up-to-date build, especially during testing and development.
2014-06-09 04:27:36 +02:00
</CustomBuild>
</ItemGroup>
Visual Studio Projects: Use Unix Line Endings ...where possible, to make application of patches easier in the future. The README.txt's and the .sln files are still in Windows/DOS line endings as they need to be so.
2013-12-27 03:50:35 +01:00
<ItemGroup>
<ProjectReference Include="gio.vcxproj">
<Project>{f3d1583c-5613-4809-bd98-7cc1c1276f92}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="glib.vcxproj">
<Project>{12bca020-eabf-429e-876a-a476bc9c10c0}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gmodule.vcxproj">
<Project>{4214047c-f5c1-40b3-8369-5dced8c32770}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gobject.vcxproj">
<Project>{f172effc-e30f-4593-809e-db2024b1e753}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gspawn-win32-helper-console.vcxproj">
<Project>{e40e8a7e-7cae-4659-9b8b-bc38898e3074}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gspawn-win32-helper.vcxproj">
<Project>{289240e7-e167-47ce-a20c-58d852e520ba}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gthread.vcxproj">
<Project>{c8afb8c3-fffd-460f-bc13-9ac25d7b117c}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="glib-compile-schemas.vcxproj">
<Project>{015d69d0-8b42-438a-adae-052ac036e065}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gsettings.vcxproj">
<Project>{05041c63-f1c5-49ba-a7de-61ebb5307eaa}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="glib-compile-resources.vcxproj">
<Project>{b0cdec7f-dce1-4f7e-b8a4-a3009c18fb2a}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gresource.vcxproj">
<Project>{95a1571f-61be-4c51-be53-2f2dab280685}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gio-querymodules.vcxproj">
<Project>{95a1571f-61be-4c51-be53-2f2dab280686}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="gdbus.vcxproj">
<Project>{95a1571f-61be-4c51-be53-2f2dab280687}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Visual Studio builds: Build the gio tool https://bugzilla.gnome.org/show_bug.cgi?id=768357
2016-07-04 06:43:36 +02:00
<ProjectReference Include="gio-tool.vcxproj">
<Project>{d0403e9a-2b00-4fd3-b3dd-3c8f9cb9a338}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Visual Studio Projects: Use Unix Line Endings ...where possible, to make application of patches easier in the future. The README.txt's and the .sln files are still in Windows/DOS line endings as they need to be so.
2013-12-27 03:50:35 +01:00
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
Visual Studio builds: Move project files to win32/ It was suggested that the project files be moved here as we don't actually need to go two directory layers from $(srcroot), and would help us to standardize on things in the future across the board.
2017-01-09 07:00:46 +01:00
</Project>
Reference in New Issue Copy Permalink