Add clang format from samples repo #131
Conversation
Format compute shader chapter as an example
|
Besides lots of other settings I'm using with the Vulkan-Hpp project, something like Just for reference, I've attached the clang-format from Vulkan-Hpp as a text file: clang-format.txt |
|
As agreed on the last call: I'll apply the clang format to all files and update this PR. |
|
No idea why the Android build fails. |
clang_format has sorted the includes. Now, |
|
Oh, that was prob. stupid. Will redo this PR without reordering the includes :/ |
No, that was not stupid. It's vulkan, that is stupid. Or maybe just |
|
That would be the better option. Didn't realize that the tutorial did explicitly include the core/platform specific headers. That indeed does not make much sense and should be changed indeed. Also feels odd that every chapter explicitly includes "vk_platform.h". |
| PointerAlignment: Right | ||
| ReflowComments: true | ||
| SortIncludes: true | ||
| SortIncludes: false |
There was a problem hiding this comment.
I thought, you wanted to keep the includes sorted, just handle the android cases locally by either just including vulkan.hpp, or not sorting those headers by using //clang-format off and //clang-format on
There was a problem hiding this comment.
Yeah, but if I enable this globally, there is a chance a maintainer forgets about that. Will try with the //clang-format off route (didn't know that existed 👍🏻)
|
Probably a good idea to add it to CI in same way we do in Samples so it fails if maintainers forget ;-). |
|
Having CI builds for all supported platforms would be very helpful indeed. |
|
Well we already have CI build for all platforms, this should just be the same copyright/clang check that Samples uses. https://github.com/KhronosGroup/Vulkan-Samples/blob/main/.github/workflows/check.yml take that and update pathing for here should just work. hopefully? Maybe add the ignore stuff as in what we use there. |
# Conflicts: # attachments/07_image_views.cpp # attachments/08_graphics_pipeline.cpp # attachments/09_shader_modules.cpp # attachments/10_fixed_functions.cpp # attachments/12_graphics_pipeline_complete.cpp # attachments/14_command_buffers.cpp # attachments/15_hello_triangle.cpp # attachments/16_frames_in_flight.cpp # attachments/17_swap_chain_recreation.cpp # attachments/18_vertex_input.cpp # attachments/19_vertex_buffer.cpp # attachments/20_staging_buffer.cpp # attachments/21_index_buffer.cpp # attachments/22_descriptor_layout.cpp # attachments/23_descriptor_sets.cpp # attachments/24_texture_image.cpp # attachments/25_sampler.cpp # attachments/26_texture_mapping.cpp # attachments/27_depth_buffering.cpp # attachments/28_model_loading.cpp # attachments/29_mipmapping.cpp # attachments/30_multisampling.cpp # attachments/31_compute_shader.cpp # attachments/32_ecosystem_utilities.cpp # attachments/33_vulkan_profiles.cpp # attachments/34_android.cpp # attachments/35_gltf_ktx.cpp # attachments/36_multiple_objects.cpp # attachments/37_multithreading.cpp
3 participants
As noted in #126 code style is all over the place, making things hard to read.
We should start using a clang format file like we did in the samples to make sure code style follows a fixed set of guidelines.
This PR is there to discuss that. It adds the clang format file from the samples and applies that to one chapter.
We prob. still would have to do at least some manual fixups, as even clang format can't get everything into a good-to-read shape. But it should do hopefully around 90% of the job.
While modern C++ is generally hard on the eyes, this makes it at least somewhat easier to read and (more importantly) more consistent.