To clarify one thing: it's not like VS with its own proprietary compiler and build system. You choose what c, c++ compiler (eg gcc, g++), debugger (gdb), copy of cmake etc to use. Projects are built from a CMakeLists.txt you maintain.
Anyone with cmake (and know how to use it) can build your source.
Haven't messed with it much so I don't know yet what ways it DOES lock you in. There's probably something.. (other than needing to use cmake)
edit: By all that I mean, you can use the versions of SFML compiled for whatever compiler you plan to use it with.
I don't really care about the compiler, really. MSVC compiler has many C++11 features so it's fine, as long as things compile.
If I have to build SFML from source because SFML doesn't provide binaries for clion, and if it's a pain in the ass because it doesn't work out of the box, it's not a lock in, but it makes thing harder for clion.
I just hate to deal with library cross-platform gimmicks, not to mention CMake scripts. I want to write code, not learn some build scripting language that is just some hack and might go extinct some day.
> Anyone with cmake (and know how to use it) can build your source.
Usually I can give a project file, eventually I even give a zip with the library binaries, and it's fine. Once you use a binary library the heavy lifting is done.
What I'm worried about is that having a cross-platform IDE doesn't nullify the binary incompatibility between binaries.
I guess clion might be useful for very large C++ application projects who want to work in cross-platorm, but not libraries. Games are usually not very large applications, they just use some inputs and opengl.
You shouldn't have to build SFML from source. The blog post says that CLion supports Cygwin and MinGW toolchains on Windows and SFML provides MinGW binaries, so you should be fine there. As I think the parent post was trying to explain, not many IDEs are as closely tied to a specific compiler as Visual Studio is tied to MSVC. A lot of IDEs, including CLion, just use GCC, so anything that works with GCC will work with CLion.
To clarify your confusion in "provide binaries for clion":
That does not make sense. You don't need binaries for CLion. If anything, you need binaries for GCC or Clang (the compiler - not the editor/IDE).
In case of a C library, the library binaries build with any compiler will work with any other compiler in your C/C++ project.
In case of a C++ library, you might need to have the library binaries build with the same compiler. So, as CLion uses GCC, you need library binaries which were also build with GCC. You can build the library with whatever build system you like (Xcode, CMake, by hand, automake, ...) as long as you use GCC.
In any case, it does not matter what editor/IDE (Vim, Xcode, CLion) and what build system (Xcode, CMake, ...) you use, it only matters, what compiler (GCC, Clang) you use.
> In any case, it does not matter what editor/IDE (Vim, Xcode, CLion) and what build system (Xcode, CMake, ...) you use, it only matters, what compiler (GCC, Clang) you use.
so if I use clion on mac, do I give it frameworks or .dylib ?
How exactly to you choose a compiler? I have both cygwin gcc and clang (3.4 cygwin, and 3.5 native) installed. I can't seem to get it to use anything other than cygwin gcc.
Anyone with cmake (and know how to use it) can build your source.
Haven't messed with it much so I don't know yet what ways it DOES lock you in. There's probably something.. (other than needing to use cmake)
edit: By all that I mean, you can use the versions of SFML compiled for whatever compiler you plan to use it with.