luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-14 13:26:16 +01:00
Code Issues Packages Projects Releases Wiki Activity
dc4361f4cb
glib/build/win32/vs10/gmodule.vcxproj

206 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>{4214047C-F5C1-40B3-8369-5DCED8C32770}</ProjectGuid>
<RootNamespace>gmodule</RootNamespace>
<Keyword>Win32Proj</Keyword>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>true</WholeProgramOptimization>
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>true</WholeProgramOptimization>
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</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" />
Visual Studio Projects: Cleanup Property Sheets Make the projects include a single property sheet as necessary, which will in turn include the other property sheet(s) as needed, so that we can avoid warnings where we include the same property sheets twice in a single project. Also make the copying of pre-configured headers into custom build rules so that they can be removed upon the clean command from the IDE and that they can be re-copied if their counterpart *.h.win32 are updated.
2013-12-27 05:25:18 +01:00
<Import Project="glib-gen-srcs.props" />
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
</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" />
Visual Studio Projects: Cleanup Property Sheets Make the projects include a single property sheet as necessary, which will in turn include the other property sheet(s) as needed, so that we can avoid warnings where we include the same property sheets twice in a single project. Also make the copying of pre-configured headers into custom build rules so that they can be removed upon the clean command from the IDE and that they can be re-copied if their counterpart *.h.win32 are updated.
2013-12-27 05:25:18 +01:00
<Import Project="glib-gen-srcs.props" />
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
</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" />
Visual Studio Projects: Cleanup Property Sheets Make the projects include a single property sheet as necessary, which will in turn include the other property sheet(s) as needed, so that we can avoid warnings where we include the same property sheets twice in a single project. Also make the copying of pre-configured headers into custom build rules so that they can be removed upon the clean command from the IDE and that they can be re-copied if their counterpart *.h.win32 are updated.
2013-12-27 05:25:18 +01:00
<Import Project="glib-gen-srcs.props" />
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
</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" />
Visual Studio Projects: Cleanup Property Sheets Make the projects include a single property sheet as necessary, which will in turn include the other property sheet(s) as needed, so that we can avoid warnings where we include the same property sheets twice in a single project. Also make the copying of pre-configured headers into custom build rules so that they can be removed upon the clean command from the IDE and that they can be re-copied if their counterpart *.h.win32 are updated.
2013-12-27 05:25:18 +01:00
<Import Project="glib-gen-srcs.props" />
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
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</LinkIncremental>
<LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">false</LinkIncremental>
<LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">true</LinkIncremental>
<LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Release|x64'">false</LinkIncremental>
</PropertyGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<ClCompile>
<Optimization>Disabled</Optimization>
<PreprocessorDefinitions>_DEBUG;$(GModuleBuildDefines);%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MinimalRebuild>true</MinimalRebuild>
<BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
<RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
<PrecompiledHeader>
</PrecompiledHeader>
<WarningLevel>Level3</WarningLevel>
<DebugInformationFormat>EditAndContinue</DebugInformationFormat>
<CompileAs>CompileAsC</CompileAs>
</ClCompile>
<Link>
<OutputFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).dll</OutputFile>
<GenerateDebugInformation>true</GenerateDebugInformation>
MSVC Builds: Few More Enahncements Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn helper programs), so that they match the names of the DLLs/EXEs that are built. Also update the .lib generation so that all will use -$(ApiVersion) from the property sheets instead of the -2.0 which was previously hard coded (as we will eventually move into GLib 3.x in the future, for example)
2015-03-04 13:11:43 +01:00
<ProgramDatabaseFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).pdb</ProgramDatabaseFile>
MSVC 2010+ builds: Explicitly use /LTCG The Visual Studio projects used a default setting for link-time code generation, which is a part of the various linker optimizations that is available, which is set as /LTCG for Visual Studio 2013 and earlier. This changed in Visual Studio 2015 to become /LTCG:incremental, which would cause GResources-generated code to be optimized out during linking, unless they were referred to directly in the main line code (such as when the GResource is manually registered), causing programs to crash as a result as they can't find the needed code/data at run time. Fix this by explicitly setting /LTCG for all release builds, for Visual Studio 2010 and later. https://bugzilla.gnome.org/show_bug.cgi?id=752837
2015-10-13 13:30:22 +02:00
<ImportLibrary>$(TargetDir)$(ProjectName)-$(ApiVersion).lib</ImportLibrary>
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
<SubSystem>Windows</SubSystem>
<RandomizedBaseAddress>false</RandomizedBaseAddress>
<DataExecutionPrevention>
</DataExecutionPrevention>
<TargetMachine>MachineX86</TargetMachine>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<ClCompile>
<PreprocessorDefinitions>$(GModuleBuildDefines);%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
<PrecompiledHeader>
</PrecompiledHeader>
<WarningLevel>Level3</WarningLevel>
<DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
<CompileAs>CompileAsC</CompileAs>
</ClCompile>
<Link>
<OutputFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).dll</OutputFile>
<GenerateDebugInformation>true</GenerateDebugInformation>
MSVC Builds: Few More Enahncements Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn helper programs), so that they match the names of the DLLs/EXEs that are built. Also update the .lib generation so that all will use -$(ApiVersion) from the property sheets instead of the -2.0 which was previously hard coded (as we will eventually move into GLib 3.x in the future, for example)
2015-03-04 13:11:43 +01:00
<ProgramDatabaseFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).pdb</ProgramDatabaseFile>
MSVC 2010+ builds: Explicitly use /LTCG The Visual Studio projects used a default setting for link-time code generation, which is a part of the various linker optimizations that is available, which is set as /LTCG for Visual Studio 2013 and earlier. This changed in Visual Studio 2015 to become /LTCG:incremental, which would cause GResources-generated code to be optimized out during linking, unless they were referred to directly in the main line code (such as when the GResource is manually registered), causing programs to crash as a result as they can't find the needed code/data at run time. Fix this by explicitly setting /LTCG for all release builds, for Visual Studio 2010 and later. https://bugzilla.gnome.org/show_bug.cgi?id=752837
2015-10-13 13:30:22 +02:00
<ImportLibrary>$(TargetDir)$(ProjectName)-$(ApiVersion).lib</ImportLibrary>
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
<SubSystem>Windows</SubSystem>
<OptimizeReferences>true</OptimizeReferences>
<EnableCOMDATFolding>true</EnableCOMDATFolding>
<RandomizedBaseAddress>false</RandomizedBaseAddress>
<DataExecutionPrevention>
</DataExecutionPrevention>
MSVC 2010+ builds: Explicitly use /LTCG The Visual Studio projects used a default setting for link-time code generation, which is a part of the various linker optimizations that is available, which is set as /LTCG for Visual Studio 2013 and earlier. This changed in Visual Studio 2015 to become /LTCG:incremental, which would cause GResources-generated code to be optimized out during linking, unless they were referred to directly in the main line code (such as when the GResource is manually registered), causing programs to crash as a result as they can't find the needed code/data at run time. Fix this by explicitly setting /LTCG for all release builds, for Visual Studio 2010 and later. https://bugzilla.gnome.org/show_bug.cgi?id=752837
2015-10-13 13:30:22 +02:00
<LinkTimeCodeGeneration>UseLinkTimeCodeGeneration</LinkTimeCodeGeneration>
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
<TargetMachine>MachineX86</TargetMachine>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<ClCompile>
<Optimization>Disabled</Optimization>
<PreprocessorDefinitions>_DEBUG;$(GModuleBuildDefines);%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MinimalRebuild>true</MinimalRebuild>
<BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
<RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
<PrecompiledHeader>
</PrecompiledHeader>
<WarningLevel>Level3</WarningLevel>
<DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
<CompileAs>CompileAsC</CompileAs>
</ClCompile>
<Link>
<OutputFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).dll</OutputFile>
<GenerateDebugInformation>true</GenerateDebugInformation>
MSVC Builds: Few More Enahncements Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn helper programs), so that they match the names of the DLLs/EXEs that are built. Also update the .lib generation so that all will use -$(ApiVersion) from the property sheets instead of the -2.0 which was previously hard coded (as we will eventually move into GLib 3.x in the future, for example)
2015-03-04 13:11:43 +01:00
<ProgramDatabaseFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).pdb</ProgramDatabaseFile>
MSVC 2010+ builds: Explicitly use /LTCG The Visual Studio projects used a default setting for link-time code generation, which is a part of the various linker optimizations that is available, which is set as /LTCG for Visual Studio 2013 and earlier. This changed in Visual Studio 2015 to become /LTCG:incremental, which would cause GResources-generated code to be optimized out during linking, unless they were referred to directly in the main line code (such as when the GResource is manually registered), causing programs to crash as a result as they can't find the needed code/data at run time. Fix this by explicitly setting /LTCG for all release builds, for Visual Studio 2010 and later. https://bugzilla.gnome.org/show_bug.cgi?id=752837
2015-10-13 13:30:22 +02:00
<ImportLibrary>$(TargetDir)$(ProjectName)-$(ApiVersion).lib</ImportLibrary>
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
<SubSystem>Windows</SubSystem>
<RandomizedBaseAddress>false</RandomizedBaseAddress>
<DataExecutionPrevention>
</DataExecutionPrevention>
<TargetMachine>MachineX64</TargetMachine>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ClCompile>
<PreprocessorDefinitions>$(GModuleBuildDefines);%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
<PrecompiledHeader>
</PrecompiledHeader>
<WarningLevel>Level3</WarningLevel>
<DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
<CompileAs>CompileAsC</CompileAs>
</ClCompile>
<Link>
<OutputFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).dll</OutputFile>
<GenerateDebugInformation>true</GenerateDebugInformation>
MSVC Builds: Few More Enahncements Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn helper programs), so that they match the names of the DLLs/EXEs that are built. Also update the .lib generation so that all will use -$(ApiVersion) from the property sheets instead of the -2.0 which was previously hard coded (as we will eventually move into GLib 3.x in the future, for example)
2015-03-04 13:11:43 +01:00
<ProgramDatabaseFile>$(OutDir)$(GlibDllPrefix)$(ProjectName)$(GlibDllSuffix).pdb</ProgramDatabaseFile>
MSVC 2010+ builds: Explicitly use /LTCG The Visual Studio projects used a default setting for link-time code generation, which is a part of the various linker optimizations that is available, which is set as /LTCG for Visual Studio 2013 and earlier. This changed in Visual Studio 2015 to become /LTCG:incremental, which would cause GResources-generated code to be optimized out during linking, unless they were referred to directly in the main line code (such as when the GResource is manually registered), causing programs to crash as a result as they can't find the needed code/data at run time. Fix this by explicitly setting /LTCG for all release builds, for Visual Studio 2010 and later. https://bugzilla.gnome.org/show_bug.cgi?id=752837
2015-10-13 13:30:22 +02:00
<ImportLibrary>$(TargetDir)$(ProjectName)-$(ApiVersion).lib</ImportLibrary>
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
<SubSystem>Windows</SubSystem>
<OptimizeReferences>true</OptimizeReferences>
<EnableCOMDATFolding>true</EnableCOMDATFolding>
<RandomizedBaseAddress>false</RandomizedBaseAddress>
<DataExecutionPrevention>
</DataExecutionPrevention>
MSVC 2010+ builds: Explicitly use /LTCG The Visual Studio projects used a default setting for link-time code generation, which is a part of the various linker optimizations that is available, which is set as /LTCG for Visual Studio 2013 and earlier. This changed in Visual Studio 2015 to become /LTCG:incremental, which would cause GResources-generated code to be optimized out during linking, unless they were referred to directly in the main line code (such as when the GResource is manually registered), causing programs to crash as a result as they can't find the needed code/data at run time. Fix this by explicitly setting /LTCG for all release builds, for Visual Studio 2010 and later. https://bugzilla.gnome.org/show_bug.cgi?id=752837
2015-10-13 13:30:22 +02:00
<LinkTimeCodeGeneration>UseLinkTimeCodeGeneration</LinkTimeCodeGeneration>
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
<TargetMachine>MachineX64</TargetMachine>
</Link>
</ItemDefinitionGroup>
<ItemGroup>
<ClCompile Include="..\..\..\gmodule\gmodule.c" />
</ItemGroup>
Visual Studio Projects: Cleanup Property Sheets Make the projects include a single property sheet as necessary, which will in turn include the other property sheet(s) as needed, so that we can avoid warnings where we include the same property sheets twice in a single project. Also make the copying of pre-configured headers into custom build rules so that they can be removed upon the clean command from the IDE and that they can be re-copied if their counterpart *.h.win32 are updated.
2013-12-27 05:25:18 +01:00
<ItemGroup>
<CustomBuild Include="..\..\..\gmodule\gmoduleconf.h.win32">
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">Copying gmoduleconf.h from gmoduleconf.h.win32...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(GenGModuleConfH)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">..\..\..\gmodule\gmoduleconf.h;%(Outputs)</Outputs>
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">Copying gmoduleconf.h from gmoduleconf.h.win32...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(GenGModuleConfH)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">..\..\..\gmodule\gmoduleconf.h;%(Outputs)</Outputs>
<Message Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">Copying gmoduleconf.h from gmoduleconf.h.win32...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(GenGModuleConfH)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">..\..\..\gmodule\gmoduleconf.h;%(Outputs)</Outputs>
<Message Condition="'$(Configuration)|$(Platform)'=='Release|x64'">Copying gmoduleconf.h from gmoduleconf.h.win32...</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(GenGModuleConfH)</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">..\..\..\gmodule\gmoduleconf.h;%(Outputs)</Outputs>
</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>
<ResourceCompile Include="..\..\..\gmodule\gmodule.rc" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="glib.vcxproj">
<Project>{12bca020-eabf-429e-876a-a476bc9c10c0}</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