You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+52-5Lines changed: 52 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,14 +19,14 @@ These instructions define how GitHub Copilot should assist with this project. Th
19
19
20
20
## General Guidelines
21
21
22
-
-**Code Style**: The project uses an .editorconfig file to enforce coding standards. Follow the rules defined in `.editorconfig` for indentation, line endings, and other formatting. Additional information can be found on the wiki at [Implementation](https://github.com/microsoft/DirectXMesh/wiki/Implementation). The library's public API requires C++11, and the project builds with C++17 (`CMAKE_CXX_STANDARD 17`). The command-line tools also use C++17, including `<filesystem>` for long file path support. This code is designed to build with Visual Studio 2022, Visual Studio 2026, clang for Windows v12 or later, and GCC on Linux or Windows.
22
+
-**Code Style**: The project uses an .editorconfig file to enforce coding standards. Follow the rules defined in `.editorconfig` for indentation, line endings, and other formatting. Additional information can be found on the wiki at [Implementation](https://github.com/microsoft/DirectXMesh/wiki/Implementation). The library's public API requires C++11, and the project builds with C++17 (`CMAKE_CXX_STANDARD 17`). The command-line tools also use C++17, including `<filesystem>` for long file path support. This code is designed to build with Visual Studio 2022, Visual Studio 2026, clang for Windows v12 or later, MinGW, and GCC on Linux.
23
23
> Notable `.editorconfig` rules: C/C++ files use 4-space indentation, `crlf` line endings, and `latin1` charset — avoid non-ASCII characters in source files.
24
24
-**Documentation**: The project provides documentation in the form of wiki pages available at [Documentation](https://github.com/microsoft/DirectXMesh/wiki/).
25
25
-**Error Handling**: Use C++ exceptions for error handling and uses RAII smart pointers to ensure resources are properly managed. For some functions that return HRESULT error codes, they are marked `noexcept`, use `std::nothrow` for memory allocation, and should not throw exceptions.
26
26
-**Testing**: Unit tests for this project are implemented in this repository [Test Suite](https://github.com/walbourn/directxmeshtest/) and can be run using CTest per the instructions at [Test Documentation](https://github.com/walbourn/directxmeshtest/wiki). See [test copilot instructions](https://github.com/walbourn/directxmeshtest/blob/main/.github/copilot-instructions.md) for additional information on the tests.
27
27
-**Security**: This project uses secure coding practices from the Microsoft Secure Coding Guidelines, and is subject to the `SECURITY.md` file in the root of the repository. Functions that read input from geometry files are subject to OneFuzz fuzz testing to ensure they are secure against malformed files.
28
28
-**Dependencies**: The project uses CMake and VCPKG for managing dependencies, making optional use of DirectXMath and DirectX-Headers. The project can be built without these dependencies, relying on the Windows SDK for core functionality.
29
-
-**Continuous Integration**: This project implements GitHub Actions for continuous integration, ensuring that all code changes are tested and validated before merging. Platforms tested include Windows (MSVC, clang-cl, MinGW), Windows on ARM64, Xbox, UWP, and WSL (Linux). This includes building the project for a number of configurations and toolsets, running a subset of unit tests, and static code analysis including GitHub super-linter, CodeQL, and MSVC Code Analysis.
29
+
-**Continuous Integration**: This project implements GitHub Actions for continuous integration, ensuring that all code changes are tested and validated before merging. Platforms tested include Windows (MSVC, clang-cl, MinGW), Windows on ARM64, Xbox, UWP, WSL (Linux with GCC), and macOS (Apple Clang). This includes building the project for a number of configurations and toolsets, running a subset of unit tests, and static code analysis including GitHub super-linter, CodeQL, and MSVC Code Analysis.
30
30
-**Code of Conduct**: The project adheres to the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). All contributors are expected to follow this code of conduct in all interactions related to the project.
31
31
32
32
## File Structure
@@ -223,9 +223,11 @@ When creating documentation:
223
223
224
224
## Cross-platform Support Notes
225
225
226
-
- The code targets Win32 desktop applications for Windows 8.1 or later, Xbox One, Xbox Series X\|S, Universal Windows Platform (UWP) apps for Windows 10 and Windows 11, and Linux.
227
-
- Portability and conformance of the code is validated by building with Visual C++, clang/LLVM for Windows, MinGW, and GCC for Linux compilers.
226
+
- The code targets Win32 desktop applications for Windows 8.1 or later, Xbox One, Xbox Series X\|S, Universal Windows Platform (UWP) apps for Windows 10 and Windows 11, and Windows Subsystem for Linux (WSL).
227
+
- macOS is not officially supported due to a lack of support for Direct3D, which is reflected in the fact that the *directx-headers* VCPKG port is not supported for macOS.
228
+
- Portability and conformance of the code is validated by building with Visual C++ (MSVC), clang/LLVM for Windows (clang-cl), MinGW, GCC for Linux, and Apple Clang for macOS.
228
229
- The project ships MSBuild projects for Visual Studio 2022 (`.sln` / `.vcxproj`) and Visual Studio 2026 (`.slnx` / `.vcxproj`). VS 2019 projects have been retired.
230
+
- CMake is the primary build system and can be used on all supported platforms.
229
231
230
232
### Platform and Compiler `#ifdef` Guards
231
233
@@ -250,7 +252,7 @@ Use these established guards — do not invent new ones:
250
252
251
253
> `_M_ARM`/ `__arm__` is legacy 32-bit ARM which is deprecated.
252
254
253
-
Non-Windows builds (Linux/WSL) use `<directx/dxgiformat.h>` and `<wsl/winadapter.h>` from the DirectX-Headers package instead of the Windows SDK.
255
+
Non-Windows builds (Linux/WSL/macOS) use `<directx/dxgiformat.h>` and `<wsl/winadapter.h>` from the DirectX-Headers package instead of the Windows SDK.
254
256
255
257
### Error Codes
256
258
@@ -288,6 +290,51 @@ When reviewing documentation, do the following:
288
290
- Read the documentation on the wiki located in [this git repository](https://github.com/microsoft/DirectXMesh.wiki.git).
289
291
- Report any specific gaps in the documentation compared to the public interface.
290
292
293
+
## Code Change Rules
294
+
295
+
- Make precise, surgical changes that **fully** address the request. Don't modify unrelated code, but ensure changes are complete and correct.
296
+
- Don't fix pre-existing issues unrelated to your task. However, if you discover bugs directly caused by or tightly coupled to the code you're changing, fix those too.
297
+
- Update documentation if it is directly related to the changes you are making.
298
+
- Always validate that your changes don't break existing behavior.
299
+
300
+
### Linting, Building, Testing
301
+
302
+
- Only run linters, builds and tests that already exist. Do not add new linting, building or testing tools unless necessary for the task.
303
+
- Use the smallest targeted test, build, or lint command that covers the changed behavior. When related targeted selectors use the same runner, include them in one invocation; escalate to full-suite or baseline runs only when targeted validation shows they are needed.
304
+
- Documentation changes do not need to be linted, built or tested unless there are specific tests for documentation.
- Install packages only when changing dependencies or after a missing-dependency failure.
310
+
311
+
### Code Commenting Style
312
+
313
+
- Only comment code that needs a bit of clarification. Do not comment otherwise.
314
+
291
315
## Release Process
292
316
293
317
The release process is documented in the [release skill](.github/skills/release/SKILL.md). Invoke the `release` skill for step-by-step guidance when performing a release.
318
+
319
+
The release workflow includes:
320
+
- Preparing release branch with version updates in `CMakeLists.txt`, `README.md`, and `.nuspec` files
321
+
- Tagging releases with verified GPG signatures
322
+
- Creating GitHub releases with release notes from `CHANGELOG.md`
323
+
- Publishing to MSCodeHub mirror, Azure DevOps signed binaries, and NuGet packages
324
+
- Source archive signing with minisign
325
+
- NuGet package validation and publishing to nuget.org
326
+
327
+
## CoPilot Skills
328
+
329
+
The project includes published CoPilot skills for developers:
330
+
331
+
-**Release-Process**: Guide for performing the DirectXMesh release process. Invoked when asked to help with releasing a new version, publishing packages, or updating ports. See [Release Process skill](.github/skills/release/SKILL.md) for details.
332
+
-**directxmesh-usage**: Provides usage guidance for the DirectXMesh library. Located in the `skills/directxmesh-usage/` directory.
333
+
-**mesh-converter**: Provides guidance for using the meshconvert command-line tool. Located in the `skills/mesh-converter/` directory.
0 commit comments