[stb] Use stb's STB_XXX_IMPLEMENTATION macros and have real stb implementation files, and have seperate stb implementations
- Dominant language
- CMake
- Stars
- 27.5k
- Forks
- 7.7k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 321
Description
### Is your feature request related to a problem? Please describe.
Note, I'm planning on doing the work for this anyway in a personal vcpkg registry regardless of how people feel, but this is a fairly big change so I can't just make a pull request for this.
stb is not a real "header only library" yet, vcpkg treats as if it is in the port. Most files require `STB_XXX_IMPLEMENTATION` inside only in a *single* source file to work properly, it's not a simple include process. It's also not a *single* library, it's several *separate* libraries that don't have dependencies on one another. I propose that instead of the current set up, the port for stb get split into
```
stb-vorbis
stb-hexwave
stb-image
stb-truetype
stb-image-write
stb-image-resize2
stb-rect-pack
stb-perlin
stb-ds
stb-sprintf
stb-textedit
stb-voxel-render
stb-dxt
stb-easy-font
stb-tilemap-editor
stb-herringbone-wang-tile
stb-c-lexer
stb-divide
stb-connected-components
stb-leakcheck
stb-include
```
and each properly deal with `STB_XXX_IMPLEMENTATION`
### Proposed solution
Each of these ports would use fetch content/fiile download/external project add to grab the relevant files. Features could then be enabled for each relevant library with features (for example, stb-vorbis), and each would be able to be used via stb::image stb::truetype etc... in the relevant cmake file. As it stands, the naive solution with out VCPKG is actually easier to manage stb than vcpkg's solution is.
### Describe alternatives you've considered
We could instead add "features" to stb which would include each of the relevant libraries, but this would break anybody who's relying on stb right now. The change above would not necessitate a change to the stb port itself, besides maybe deprecating it if need be. Additionally, there libraries aren't even features. Unlike a regular repo, each of the stb_files.h should really be their own repo and project, it's just organized as one repo.
### Additional context
Our current code depends on the whole `STB_XXX_IMPLEMENTATION` issue being fixed, so that we don't have to worry about including `stb_xxx.h` files in more than one place causing issues. With out changes, it's impossible to use VCPKG's publically availible stb port in our codebase.
Contributor guide
Assessment
This issue has not been assessed yet.