luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-12-28 00:16:15 +01:00
Code Issues Packages Projects Releases Wiki Activity
8d68a27f70
glib/build/win32/vs10/glib-install.vcxproj

182 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>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(GlibEtcInstallRoot)\</OutDir>
<ExtensionsToDeleteOnClean Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" />
<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(GlibEtcInstallRoot)\</OutDir>
<ExtensionsToDeleteOnClean Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" />
<OutDir Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(GlibEtcInstallRoot)\</OutDir>
<ExtensionsToDeleteOnClean Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" />
<OutDir Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(GlibEtcInstallRoot)\</OutDir>
<ExtensionsToDeleteOnClean Condition="'$(Configuration)|$(Platform)'=='Release|x64'" />
</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">
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">Generating .pc files...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(GlibGenPC)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(GlibPCFiles);%(Outputs)</Outputs>
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">Generating .pc files...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(GlibGenPC)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(GlibPCFiles);%(Outputs)</Outputs>
<Message Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">Generating .pc files...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(GlibGenPC)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(GlibPCFiles);%(Outputs)</Outputs>
<Message Condition="'$(Configuration)|$(Platform)'=='Release|x64'">Generating .pc files...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(GlibGenPC)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(GlibPCFiles);%(Outputs)</Outputs>
</CustomBuild>
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 Include="..\..\..\config.h.win32">
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">Installing Build Results...</Message>
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
<AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(GlibPCFiles)</AdditionalInputs>
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
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(GlibDoInstall)</Command>
Visual Studio projects: Clean up a little bit For the Visual Studio 201x projects, we can force the "install" projects to always run in a simpler way, by specifying an output file that will never exist. Makes things look a bit cleaner.
2016-06-15 10:31:40 +02:00
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">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
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">Installing Build Results...</Message>
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
<AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(GlibPCFiles)</AdditionalInputs>
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
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(GlibDoInstall)</Command>
Visual Studio projects: Clean up a little bit For the Visual Studio 201x projects, we can force the "install" projects to always run in a simpler way, by specifying an output file that will never exist. Makes things look a bit cleaner.
2016-06-15 10:31:40 +02:00
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">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
<Message Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">Installing Build Results...</Message>
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
<AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(GlibPCFiles)</AdditionalInputs>
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
<Command Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(GlibDoInstall)</Command>
Visual Studio projects: Clean up a little bit For the Visual Studio 201x projects, we can force the "install" projects to always run in a simpler way, by specifying an output file that will never exist. Makes things look a bit cleaner.
2016-06-15 10:31:40 +02:00
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">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
<Message Condition="'$(Configuration)|$(Platform)'=='Release|x64'">Installing Build Results...</Message>
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
<AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(GlibPCFiles)</AdditionalInputs>
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
<Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(GlibDoInstall)</Command>
Visual Studio projects: Clean up a little bit For the Visual Studio 201x projects, we can force the "install" projects to always run in a simpler way, by specifying an output file that will never exist. Makes things look a bit cleaner.
2016-06-15 10:31:40 +02:00
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">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-genmarshal.vcxproj">
<Project>{bd12e835-5c52-4e5d-8234-1c579f33e27a}</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>
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
Visual C++ 2010 Project Files These are the actual GLib VS2010 project files (*.vcxproj, *.vcxproj.filters) and property sheet file (*.props) that are used to compile the GLib, GModule, GObject, GThread, GIO DLLs, along with the gspawn-win32-helper* programs, glib-genmarshal utility and testglib test program. A readme.txt file is also enclosed for references for building GLib under VS2010. Note that the project files for GLib, GIO and GObject are templates that makes use of the autotools items of my last commit so that maintenance of those files are simplified as new source files are added to these rather frequently. Suggestions are welcome for these-please let me know via BugZilla. Thank you!
2011-02-22 13:08:36 +01:00
</Project>
Reference in New Issue Copy Permalink