{"id":31923672,"url":"https://github.com/fletcher/c-template","last_synced_at":"2025-10-13T23:56:20.418Z","repository":{"id":33729406,"uuid":"37383757","full_name":"fletcher/c-template","owner":"fletcher","description":"Boilerplate to set up a c project, include CuTest unit testing, cmake build setup","archived":false,"fork":false,"pushed_at":"2019-01-16T19:22:42.000Z","size":198,"stargazers_count":73,"open_issues_count":0,"forks_count":17,"subscribers_count":7,"default_branch":"master","last_synced_at":"2023-05-06T01:18:17.788Z","etag":null,"topics":["astyle","boilerplate","c","cmake","cpack","doxygen"],"latest_commit_sha":null,"homepage":"http://fletcher.github.io/c-template/","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/fletcher.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-06-13T18:53:44.000Z","updated_at":"2023-05-05T23:59:23.000Z","dependencies_parsed_at":"2022-08-31T19:02:17.724Z","dependency_job_id":null,"html_url":"https://github.com/fletcher/c-template","commit_stats":null,"previous_names":[],"tags_count":null,"template":null,"template_full_name":null,"purl":"pkg:github/fletcher/c-template","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fletcher%2Fc-template","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fletcher%2Fc-template/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fletcher%2Fc-template/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fletcher%2Fc-template/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/fletcher","download_url":"https://codeload.github.com/fletcher/c-template/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fletcher%2Fc-template/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279017193,"owners_count":26086017,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-13T02:00:06.723Z","response_time":61,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["astyle","boilerplate","c","cmake","cpack","doxygen"],"created_at":"2025-10-13T23:55:44.231Z","updated_at":"2025-10-13T23:56:20.411Z","avatar_url":"https://github.com/fletcher.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"## About ##\n\n|            |                           |  \n| ---------- | ------------------------- |  \n| Title:     | C-Template        |  \n| Author:    | Fletcher T. Penney       |  \n| Date:      | 2019-01-16 |  \n| Copyright: | Copyright © 2015-2019 Fletcher T. Penney.    |  \n| Version:   | 1.0.9      |  \n\n\n## Introduction ##\n\nThis template was created out of a desire to simplify some of the setup and\nconfiguration that I was doing over and over each time I started a new project.\nAdditionally, I wanted to try to start encouraging some \"better practices\"\n(though not necessarily \"best practices\"):\n\n1. [Test-driven development][tdd] -- My development of MultiMarkdown\n\tfocused on integration testing, but really had no unit testing to\n\tspeak of.  Some newer projects I began working on were a bit math-\n\theavy, and ensuring that each piece works properly became even more\n\timportant.  It was also nice to be able to actually develop code that\n\tcould do *something* (via the test suite), even though the project as\n\ta whole was nowhere near complete.)  To accomplish this, I include the\n\t[CuTest] project to support writing tests for your code.\n\n2.  Use of the [cmake] build system.  `cmake` is not perfect by any\n\tmeans, but it does offer some very useful features and a means for\n\tbetter integrating the compilation and packaging/installation aspects\n\tof development.  Rather than reinventing the wheel each time, this\n\tsetup incorporates basic `cmake` functionality to make it easy to \n\tcontrol how your project is compiled, and includes automated generation\n\tof the test command.\n\n3.\tTemplates -- `cmake` has a reasonable templating system, so that you\n\tcan define basic variables (e.g. author, project name, etc.) and allow\n\t`cmake` to combine those elements to ensure consistency across source\n\tcode and README files.\n\n4.\tDocumentation -- some default setup to allow for [Doxygen]-generated\n\tdocumentation.  The generated `README.md` file is used as the main \n\tpage, and the source c/header files are included.  Naturally, Doxygen\n\tis a complex system, so you're responsible for figuring out how to \n\tproperly document your code.\n\n5.\tSimplify `git` a touch -- In my larger projects, I make heavy use of\n\tgit modules.  One project may make use of 20-30 modules, which are\n\tdesigned to be re-usable across other projects.  I found that I was\n\tspending too much time making sure that I had the latest version\n\tof a module checked out, so I created two scripts to help me keep\n\tmy modules in line: `link_git_modules` and `update_git_modules`.\n\tYou run the `link` script once to ensure that your modules are properly\n\tset up, and can then run the `update` script at any time to be sure\n\tyou've pulled the latest version.  One advantage of this is that your\n\tmodules are set to a branch, rather than just a detached commit. It\n\tmay or may not work for your needs, but it saves me a bunch of time\n\tand headache.\n\n\n[tdd]:\thttps://en.wikipedia.org/wiki/Test-driven_development\n[cmake]:\thttp://www.cmake.org/\n[CuTest]:\thttp://cutest.sourceforge.net\n[Doxygen]:\thttp://www.stack.nl/~dimitri/doxygen/\n\n\n## How do I use it? ##\n\nYou can download the source from [github] and get to work. The file \"IMPORTANT\"\ncontains instructions on the various build commands you can use.\n\n\nI recommend using the following script to automatically create a new git repo,\npull in the default project template, and configure git-flow.  You simply have\nto rename your project directory from `new-project` to whatever you desire:\n\n\n\t#!/bin/sh\n\n\tgit init new-project\n\n\tcd new-project\n\n\tgit remote add \"template\" https://github.com/fletcher/c-template.git\n\n\tgit pull template master\n\n\tgit flow init -d\n\n\tgit checkout develop\n\n\nUsing this approach, you can define your own `origin` remote if you like, but\nthe `template` remote can be used to update the core project files should any\nimprovements come about:\n\n\tgit checkout develop\n\tgit merge template master\n\n**NOTE**: `cmake` is a complex suite of utilities, and if you have trouble you\nwill need to get support elsewhere.  If you find errors in this template, by\nall means I want to hear about them and fix them, but this is just a basic \nframework to get you started.  In all likelihood, all but the most basic\nprojects will need some customization.\n\n\n[github]:\thttps://github.com/fletcher/c-template\n\n\n## Configuration ##\n\n\n### CMakeLists.txt File ###\n\nFirst, you should update the project information under the \"Define Our Project\"\nsection, including the title, description, etc.  This information will be used\nto update the README, as well as to create the `version.h` file so that the \nproject can have access to its own version number.\n\nYou will then need to update the various groups in the \"Source Files\" section\nso that Cmake will be able to determine which files are used to build your\nproject.  For reasons that will become clear later, try to follow the\nsuggestions for the different groups of files.\n\nYou then need to define your targets, such as a library, or executable, etc.\nObviously, this will depend on the needs of your project.  You can also add\ncustom steps based on the Target OS (OS X, Windows, *nix, etc.).\n\nYou can use CPack to generate installers for your software.  This can be\ncomplex, and you will need to modify this section heavily.\n\nCuTest is used by default to provide unit testing (see below), but you\ncan also use CMake/CTest to provide integration testing.  Again, this will\nbe up to you to configure.\n\n\n### CuTest ###\n\n[CuTest] provides a means to integrate unit testing with your C source code.\nOnce you get the hang of it, it's easy to use.\n\n\n### Doxygen ###\n\n[Doxygen] is used to generate documentation from the source code itself. \nProperly configuring your source for this is up to you.  You can modify the\n`doxygen.conf.in` template with your desired settings as desired, but most\nof the basics are handled for you based on your CMake configuration.\n\n\n### GitHub Pages Support ###\n\nThe `configure-gh-pages` script sets up a `documentation` directory that is \nlinked to a `gh-pages` branch of the project.  You can then run `make gh-pages` \nto update the documentation in this directory.  Commit and push to your origin,\nand your projects gh-page is updated.\n\n\n### Makefile ###\n\nThe overall build process is controlled by the master `Makefile`.  It provides\nthe following commands:\n\n\tmake\n\tmake release\n\nGenerate the CMake build files for use or distribution.  Once complete you will\nneed to change to the `build` directory and run `make`, `make test`, and\n`cpack` as desired.\n\n\tmake zip\n\nDirect CPack to create a zip installer rather than a graphical installer.\n\n\tmake debug\n\nGenerate build files for [CuTest] unit testing.  In the `build` directory, \nrun `make`, then `make test`.\n\n\tmake analyze\n\nIf you have `clang` installed, this will generate debug build files with the\n`scan-build` command.  In the `build` directory, run `scan-build -V make`\nto compile the software and view the static analysis results.\n\n\tmake xcode\n\nBuild a project file for Xcode on OS X.\n\n\tmake windows\n\tmake windows-zip\n\tmake windows-32\n\tmake windows-zip-32\n\nUse the MinGW software to cross-compile for Windows on a *nix machine.  You can\nspecify the 32 bit option, and also the zip option as indicated.\n\n\tmake documentation\n\nBuild the [Doxygen]-generated documentation.\n\n\tmake clean\n\nClean out the `build` directory.  Be sure to run this before running another\ncommand.\n\n\n## Git Submodules ##\n\nApparently, submodules are a rather controversial feature in git.  For me,\nhowever, they have proven invaluable.  My most active projects depend on each\nother, and the submodule feature allows me to easily keep everything up to\ndate.  That said, however, I quickly realized that submodules don't work very\nwell using default commands.\n\nThe problem is that I want to always use the latest version of my submodules.\nThis is more easily accomplished when the submodule is set to the `master`\nbranch of the original repository, rather than a detached commit as happens\nby default.  In order to easily keep all submodules updated, there are two \nscripts:\n\n1. `link_git_modules` -- this script is generally only run when the master\nrepository is first cloned, but can also be run after a new submodule is \nadded.  It causes the submodules to automatically track the master branch.\nIf you need to modify this, there are instructions in the script itself \nexplaining how to modify it on a per submodule basis.  Running this script \nmore than one time will not hurt anything.\n\n2. `update_git_modules` -- this script simply causes each submodule to be\nupdated to the latest commit in the original repository.  Again, running it\nmultiple times doesn't hurt anything.\n\n\n## Source File Templates ##\n\nIn the `templates` directory are two files, `template.c.in` and\n`template.h.in`.  These are used to create default source files that include\nthe project title, copyright, license, etc. They are also set up to include\nsome example information for [Doxygen] and [CuTest].\n\n\n## License ##\n\nThe `c-template` project is released under the MIT License.\n\nGLibFacade.c and GLibFacade.h are from the MultiMarkdown v4 project:\n\n\thttps://github.com/fletcher/MultiMarkdown-4/\n\nMMD 4 is released under both the MIT License and GPL.\n\n\nCuTest is released under the zlib/libpng license. See CuTest.c for the text\nof the license.\n\n\n## The MIT License ##\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in\nall copies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\nTHE SOFTWARE.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffletcher%2Fc-template","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffletcher%2Fc-template","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffletcher%2Fc-template/lists"}