Name conflict with the GNU Scientific Library

[mapreri]

Microsoft/GSL conflicts with https://www.gnu.org/software/gsl/ (another completely different project) and not only with the name, but as far as I can see also in the installed files.

Would it be possible to ponder a rename of this project, on the basis that GNU's GSL is much older than Microsoft's GSL?

[infinity0]

GSL has been around since 1996 https://www.gnu.org/software/gsl/ and is packaged in all the popular FOSS OS distros that I checked:

https://admin.fedoraproject.org/pkgdb/package/rpms/gsl/
https://packages.debian.org/search?keywords=gsl
https://www.archlinux.org/packages/extra/i686/gsl/
https://packages.gentoo.org/packages/sci-libs/gsl
http://portsmon.freebsd.org/portoverview.py?category=math&portname=gsl
ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/math/gsl/README.html
http://ports.su/devel/gsl
https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/libraries/gsl
https://www.gnu.org/software/guix/packages/g.html

[maikel]

This is one of the earliest issues #31 and have already been discussed in detail. Concrete conflicts would help, I guess.

[infinity0]

We can't avoid conflicts with every other thing out there, so we will stick with something sensible for this library.

In fact, it is possible to avoid conflicts by using google.com. Not sure if bing.com makes it as easy to find these public conflicts, however. GNU Scientific Library is not some random small library nobody uses, like the Go vs Go! conflict, it is the number 1 result on Google for "GSL", the number 2 result being Global Starcraft League.

[neilmacintosh]

Maikel Nadolski (@maikel) has correctly identified that we have already discussed this issue. My position has not changed, so there is nothing to be done here and I am closing the issue.

To summarize:

1. Two projects sharing the same three letter acronym as a short-form name is not a conflict I am going to worry about. Most people can distinguish which one is being discussed via context. If not, then qualify appropriately (as I do in this response).

2. Namespaces are the pre-existing conflict-resolution mechanism in C++. GNU Scientific Library is a C library and so does not share the same namespace as Guideline Support Library in a C++ program. If you want to use the two in the same program, then just use namespaces appropriately.

3. There is no file conflict between the libraries. GNU Scientific Library uses a .h suffix for its files, Guideline Support Library does not. Also, I'm pretty sure there are a bunch of header names that are wildly different (I do not think we have, or will ever have a gsl_sf_bessel.h in the Guideline Support Library).

[infinity0]

The main problem is the include path, it's very confusing to install both MS-GSL and GSL into /usr/include/gsl, even if no files are directly conflicting today. I don't think any distribution is going to want to do that. I was going to suggest /usr/include/c++/gsl as an alternative path for Debian and probably other FOSS distributions, but it would be good to get an agreed standard on this alternative path from you the upstream project.

Then, as mentioned in the other thread, there is the potential problem of GSL C++ wrappers wanting to use, or already using, the gsl C++ namespace. I have no solution for this, and I haven't looked at the existing wrappers yet. Does something like

namespace std {
#include <c++/gsl/gsl>
}

work to rename namespaces in C++?

[MikeGitb]

Nope, that's wrong for so many reasons (mainly because you are also putting any indirectly included header files into the new namespace).

And yes, there are gnusl wrappers out there that use the gsl namespace (although the ones I know of seem to be no longer maintained).

:(

[galik]

I think this question is going to come up again and again as more people adopt CppCoreGuidelines, particularly in the educational and scientific communities where GNU GSL gets used a lot.

The fact that GNU GSL is a C library does not detract from its occupying the "gsl" namespace imo because namespaces are conceptual. Just because C++ has the namespace keyword doesn't give it special privileges there.

In C the namespace is usually expressed using function prefixes like

auto v = gsl_acosh(GSL_CONST_CGSM_BOHR_RADIUS);

The fact that GNU GSL uses that convention seems to me a reasonable "claim" on the "gsl" namespace and the natural expression of that in C++ is by using namespace gsl {}.

If that project (or an off-shoot) were to create C++ wrappers it will find its current namespace taken.

And apart from that people using both libraries are going to wonder what they mean by "GSL" because it is not like writing scientific programs is mutually exclusive from using the CppCoreGuidelines. Hopefully we want scientists and those in education to use the CppCoreGuidelines just as much as everyone else.

Even more so if they're building rockets...

[neilmacintosh]

Galik (@galik) if it does, then each question will get redirected to the existing answers :-) (though maybe this is a good prompt for me to go create a FAQ).

A function prefix is not the same thing as a namespace. If GNU GSL decides to add C++ wrappers AND decides to use just "gsl" as their namespace , then it will face two choices:

1. Use it anyway and let users rely on language facilities to resolve namespace conflicts in their code (these exist - namespaces are not expected to be universally unique). Seems reasonable to me.
2. Choose something else. Seems reasonable to me.

Regarding people wondering what is meant by "GSL". It still seems very easy to me to distinguish between GSL the scientific computation library and GSL the foundational types library in conversation/discussion. There are a bunch of ways to do so...none seem particularly difficult.

[MikeGitb]

Use it anyway and let users rely on language facilities to resolve namespace conflicts in their code (these exist - namespaces are not expected to be universally unique). Seems reasonable to me.

That is now the second time I hear about such language facilities. Could you shortly explain what you mean or point me to some source about such techniques?

[galik]

Perhaps it would be a good idea to make MS GSL's namespace user configurable in the install script?

Inevitably Linux distros are going to want to create a package for the MS GSL. The installation package name for GNU GSL is simply "gsl".

Also in many Linux distributions and other OSs that use GNU tools, the library and header file discovery is achieved using the pkg-config tool. Currently the GNU GSL is queried like this:

CXXFLAGS += $(shell pkg-config gsl --cflags)
LDFLAGS += $(shell pkg-config gsl --libs)

Linux distributors will need to pick a different name to "gsl" for things like package name, the colliding include folder, the pkg-config tag and maybe other things I didn't think of.

It may be that Linux distros will simply create a patch for MS GSL to change its folder name and the namespace. Making the namespace user configurable would make that less painful.

[neilmacintosh]

MikeGitb (@MikeGitb) The MSVC documentation at: https://docs.microsoft.com/en-us/cpp/cpp/namespaces-cpp covers the language facilities. In particular, namespace qualification is the simplest way to disambiguate. Using declarations and namespace aliases can also be helpful if you have to resolve conflicts.

Galik (@galik) I'm not going to make the namespace configurable. We chose gsl and we'll stick with it.

Roll on modules... ;-)

[MikeGitb]

Sorry, I still don't get it. Just to make sure we are talking about the same thing:

//libA.h
namespace foo {
    struct Bar { int i; int b; };
}

//libB.h
namespace foo {
    struct Bar { std::string name; int cnt; };
}

//app.cpp
#include "libA.h"
#include "libB.h" //compiler error

How does namespace qualification help when the namespace is the same for both libraries? I also don't see how aliases would help. In fact, the link you gave talks about using long and unambigous namespaces and then let the user create shorter aliases for convenience on a case-by-case basis.