1. 25 May, 2024 4 commits
  2. 22 May, 2024 1 commit
  3. 11 May, 2024 2 commits
  4. 23 Oct, 2023 1 commit
  5. 20 Oct, 2023 1 commit
    • Chris Thrasher's avatar
      Remove MinGW CI job · cb8bcf6b
      Chris Thrasher authored
      Removed for the same reason it was removed from SFML. GitHub Actions
      switched to a version that expects different C runtime libraries
      resulting in linker errors. Let's just remove this job since fixing
      it is overkill for a project as simple as this.
      cb8bcf6b
  6. 21 Sep, 2023 2 commits
  7. 19 Sep, 2023 1 commit
  8. 07 Sep, 2023 4 commits
  9. 26 Feb, 2023 1 commit
  10. 18 Jul, 2022 1 commit
  11. 31 May, 2022 1 commit
  12. 16 May, 2022 1 commit
  13. 10 May, 2022 10 commits
    • Chris Thrasher's avatar
      Add more CMake resources · 581960a9
      Chris Thrasher authored
      581960a9
    • Chris Thrasher's avatar
      Find latest SFML release · 040b05f8
      Chris Thrasher authored
      040b05f8
    • Chris Thrasher's avatar
      Remove comments · bfcf8153
      Chris Thrasher authored
      bfcf8153
    • Chris Thrasher's avatar
      Use default executable installation directory · b2c1b235
      Chris Thrasher authored
      On a system like macOS, this means installating the executable to
      /usr/local/bin instead of /usr/local.
      b2c1b235
    • Chris Thrasher's avatar
      Don't glob source files · a6da2871
      Chris Thrasher authored
      This is a notorious CMake debate but I come down on the side of
      strict correctness and avoid globbing. For a template project like
      this where users are prone to be adding new source files regularly,
      I worry that even with CONFIGURE_DEPENDS they may still have issues
      with CMake not reconfiguring and not picking up the new .cpp file
      they added. I'd prefer to leave globbing to experienced CMake users
      who are likely not the audience of this template project.
      a6da2871
    • Chris Thrasher's avatar
      Explicitly write out executable name · edd61567
      Chris Thrasher authored
      While using ${PROJECT_NAME} for simple single-executable projects
      isn't an awful idea, it scales poorly. If you want to add tests or
      a library or any other targets, it becomes awkward to keep using
      ${PROJECT_NAME} with various prefixes and suffixes to ensure all
      targets have unique names. The readability benefits of spelling out
      the name outweight the potential copy-paste-ability of using
      ${PROJECT_NAME} to name your executable.
      edd61567
    • Chris Thrasher's avatar
      Don't over-specify language requirements · edf38e55
      Chris Thrasher authored
      Disabling compiler extensions isn't a bad idea because it changes
      -std=gnu++17 to -std=c++17 and it makes it harder to accidentally
      use extensions but it's not really particularly helpful given how
      hard it is to accidentally use compiler extensions. Besides, the CI
      pipeline already in this project will build with enough compilers
      to guarantee that compilers extensions are not being used.
      
      As for CMAKE_CXX_STANDARD_REQUIRED, this one is overspecifying the
      requirements. If you request C++17 but only use C++14 features, it's
      fine if your compiler only supports C++14. It's better to let a
      compiler attempt to build the project than fail prematurely before
      even giving it a chance to work.
      edf38e55
    • Chris Thrasher's avatar
      Specify privacy of link libraries · 1c91ad3a
      Chris Thrasher authored
      By default, link libraries are public so it's recommended to always
      explicitly specify the privacy.
      1c91ad3a
    • Chris Thrasher's avatar
      b6d75c82
    • Chris Thrasher's avatar
      Simplify .gitignore to include a single CMake binary directory · 63700fcf
      Chris Thrasher authored
      Because in-source builds are so widely accepted as a bad idea, it's
      reasonable to ignore a single binary directory and nothing else. If
      users choose to dump their build products into the repo then they
      may do so at their own risk. For users who put their binary directory
      outside of their source directory then this is not even necessary
      so we only need to cater to users who want the convenience of cloning
      a repo and immediately running `cmake -B build`.
      63700fcf
  14. 12 Mar, 2022 3 commits