Mirrors_UI_SDK/GacUI
1
0
Fork 0
mirror of https://github.com/vczh-libraries/Release.git synced 2026-08-17 09:21:41 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Sync copilot context

Browse Source
This commit is contained in:
vczh
2026-06-06 15:36:04 -07:00
parent a8750a35ab
commit 8e761e4641
2 changed files with 29 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/Guidelines/SourceFileManagement.md
+21
View File
@@ -15,6 +15,27 @@
- All affected `*.vcxitems`, `*.vcxproj`, `*.vcxitems.filters` and `*.vcxproj.filters` must be updated.
## Adding new C++ Project
- There are two kinds of projects: `*.vcxproj` and `*.vcxitems`.
- Usually `*.vcxproj` comes with a `*.vcxproj.filters` because solution explorer organization of source files are always needed.
- Usually `*.vcxitems` does not come with a `*.vcxitems.filters` because all files are just listed below the project in the solution explorer.
- When adding a new project, find a existing project to copy.
- For a typical `*.vcxproj` project, there will always be solution explorer folders `Header Files`, `Resource Files` and `Source Files`.
- `Header Files` and `Resource Files` should be kept during copy even when there will be no files adding to them.
- `Header Files` is never used, all source files, including header files, should be in `Source Files` or custom created folders.
- If all options are correctly copied from another `*.vcxproj` files, it should be good but you still need to make sure that:
- `Debug` and `Release` are always needed.
- `Win32` and `x64` are always needed.
- All configuration should define `VCZH_DEBUG_NO_REFLECTION` macro, unless there is special requirement to enable C++ reflection.
- All `Debug` configuration should define `VCZH_CHECK_MEMORY_LEAKS`.
- When `*.vcxproj` is added to the solution, you need to build the solution against all configuration to make sure everything works:
- `Debug` and `Release`.
- `Win32` and `x64`.
- Even if you find any pre-existing issues, you should fix them.
- You can skip the test, as adding new project should not affect test cases, unless existing projects are modified as part of the refactoring.
- Only add the `/bigobj` compiler option to a `*.cpp` file when needed.
## Working on Linux
`makefile` for each project is generated from MSBuild project files during the build.
.github/prompts/investigate.prompt.md
+8
View File
@@ -188,3 +188,11 @@ Propose any solution you can think of and write them down in the document, you m
- When different `## Task X` happens in different repos, you are going to change the `Copilot_Investigate.md` in that repo.
- If multiple repos are involved, for all involved repos that has the `Copilot_Investigate.md` file, decide which repo is the main repo for the task and update that file in the main repo.
- If the repo does not have such document, you are allowed not to create one, skip writing such file.
- When `git push` is blocked because of needing to merge, you are allowed to rebase by yourself:
- Always rebase to the latest change of the remote branch, instead of making a rebase commit.
- Usually there is only documentation or instruction changes. In this case, you can rebase and skip the testing.
- When there is code conflict, you are required to rebase all local changes first (when multiple commits are created for one task), and redo the testing process.
- There are two kinds of source code:
- Code files for manual editing, you need to carefully resolve all conflicts.
- Code files that is auto generated, you can just accept the remote change, and redo the testing process to regenerate these file and ensure all test cases passed. `git commit` all local changes during the process.
- After the rebase is done and all test cases passed, `git push` it again.