search

mesonbuild / mesonwrap

Meson wraps service and tools, please use https://github.com/mesonbuild/wrapdb for wraps issues
https://wrapdb.mesonbuild.com
Apache License 2.0
26 stars 7 forks source link

new wrap: GSL #75

Closed gnail closed 5 years ago

gnail commented 5 years ago

upstream url: https://github.com/Microsoft/GSL/releases version: 2.0.0

sarum9in commented 5 years ago

I wonder if we should name it microsoft_gsl as there is another https://en.wikipedia.org/wiki/GNU_Scientific_Library. @koponomarenko another interesting example triggering policy inconsistency. The problem is, there are clear cases when the project is well known and unambiguous, sometimes the opposite (like json), but we will see something in the middle pretty often as well, e.g. this one.

jpakkane commented 5 years ago

A rule of thumb used in the beginning was to name things after their pkg-config names. I would imagine gsl to be taken by GNU Scientific Library so we should probably reserve that for it.

gnail commented 5 years ago

For reference there's also https://github.com/martinmoene/gsl-lite which provides another implementation so microsoft_gsl does make sense. I can see there could be disagreement on whether it should be ms-gsl, msft-gsl, gsl-ms, gsl-cpp etc. but I guess that's more about naming policy in general which is outside the scope of this issue.

sarum9in commented 5 years ago

Okay, I am not sure if it matters, but what I found in our wrapbase is that name-project is used for ambigous names (e.g. https://github.com/mesonbuild/hinnant-date) or https://github.com/mesonbuild/nlohmann_json which is the full name itself. So I created https://github.com/mesonbuild/microsoft-gsl.