Closed Sebanisu closed 2 years ago
Thank you for giving a nice idea. But, It would be quite annoying to overwrite README file. This repo is continuously merging commits from the source repo. and overwriting README will occur conflict 😭. Instead of updating README, I'll write a guide to use this as a pinned issue.
We could possibly rework the README to discuss both upstream and downstream projects. We can probably work something out for the benefit of end-users. I'm considering deleting the upstream cmake build, for example.
@nigels-com Thanks for caring about this :).
IMO, glew-cmake is useful for somebody wanting to build an old project - using glew-cmake - or needing recent pre-generated sources. And I cannot afford to maintain actively cmake build of this.
So, I suggest these. Mentioning this project as a provider of a recent snapshot on the upstream project. This project provides a guide about pre-generated sources, using cmake with this. and suggests using build systems of the upstream project. These can benefit end-users.
Please give any opinion about my suggestion!
Understood. Perhaps then a seperate readme file upstream to document glew-cmake specifics, which I can link from the main readme.md?
I'll try to make an update script moving upstream readme as another name, and Add glew-cmake specific one as README.md
. It should be less confusing for users.
If it seems too hard, I'll request some help. Thanks!
You're cmakelists.txt is much different than the source project. I was thinking you should include basic compiling instructions in your readme.md. Or basic linking to project examples
Here is what I'm doing: glew.cmake file:
In our program I'm using
target_link_libraries
to link toPRIVATE libglew_static
There might be better ways. I've only been using cmake for about a year always learning new stuff. :D