4 ms·

>Because then you don't actually have to do anything at all. It's wishful thinking to suggest that all build related tasks can and will be doable with cargo. I

>Because then you don't actually have to do anything at all. It's wishful thinking to suggest that all build related tasks can and will be doable with cargo. If cargo does not do exactly what I want, either it's impossible to do with cargo or is made more difficult by forcing me to use it. >All the work is pushed onto the provider of the library. What work is there to do for me as someone who depends on a C library? Ignoring weird edge cases like OpenMP, it's trivial to write in my documentation "Depends on SDL v2" and add 'sdl2' to my libs array or whatever particular build system detail there is.

nicoburns 5y ago
> What work is there to do for me as someone who depends on a C library? Ignoring weird edge cases like OpenMP, it's trivial to write in my documentation "Depends on SDL v2" and add 'sdl2' to my libs array or whatever particular build system detail there is. As someone who isn't overly familiar with the C ecosystem: suppose I want to depend on SDL2, and I want my code to work across windows, macOS and linux. What does a minimal build config look like (in a build system of your choice)? And how (as a second developer or on a second machine) would I then use that config assuming it was committed as part of the codebase?
- sanxiyn 5y ago
  As I think this is a genuine question, I will answer accordingly. My build system of choice is CMake and my package system of choice is vcpkg. I will assume both are already setup. They are easy to setup on all of Windows/macOS/Linux by following the instruction. I tested. First, you need to find out the package name. Run vcpkg search sdl2. It tells you that the package is called sdl2. It is trivial in this case, but if you wanted SDL 1.x, it could have been called sdl, or sdl1. vcpkg search will tell you it's sdl1. Next, you install it by running vcpkg install sdl2. This will build from source. >1000 packages in the official repository should build cleanly, warning free, etc. Installation tells you how you should use the package with CMake. It is two lines. find_package(SDL2), and target_link_libraries(main SDL2::SDL2). To use CMake with vcpkg, copy and paste two lines to your CMakeLists.txt, and run CMake with CMAKE_TOOLCHAIN_FILE set to vcpkg.cmake. Yes, C situation is bad, but it is not as bad as people think.
- Arch-TK 5y ago
  GNUmakefile: LDLIBS += $(shell pkg-config --libs sdl2) CFLAGS += $(shell pkg-config --cflags sdl2) prog: prog.o Then you just run `make` or `gmake` (the developer should be aware of what his platform of choice prefers to call gnu make) and prog.c gets compiled to prog using the appropriate flags. I missed out some important details like setting the standard revision but I wanted to keep this short. This will work with gnu make, gcc and clang on linux, mac, any BSD, and windows (under wsl or msys or cygwin). Cross compilation is possible too. Personally I would use redo as the build system but this is shorter in make for such a simple project. More complex projects can be made to work with this basic pattern. When using autotools, cmake or meson you also have plenty of good options although I'm not entirely familiar with them as I don't use autotools, cmake or meson. Obviously this won't work if your machine is broken or if you don't have SDL2 installed in the correct place, but these are concerns for the package manager. The documentation simply needs to instruct you to install SDL2 (with development headers and the pkg-config definition). If you need a more advanced use-case such as you're trying to vendor the dependencies, you need to deal with PKG_CONFIG_PATH but I should stress that vendoring is NOT a normal use-case in the open-source-project-relying-on-sdl2 world.
  - sanxiyn 5y ago
    The main deficit here is package manager. People are not writing yet another cross-platform package managers for no reason. Providing a consistent cross-platform experience is a value add. With "use system package manager", you'd need something like the following at least: On Windows/MSYS2, run pacman -S mingw-w64-SDL2. On macOS/Homebrew, run brew install sdl2. On Linux/DEB, run apt install libsdl2-dev. On Linux/RPM, run dnf install SDL2-devel. Which is no fun, not to speak of problems when versions in system package managers are different.
    - Arch-TK 5y ago
      Using the system package manager means that your software can actually in the future be packaged for a distribution. This is a major win in the sense that if your software ever achieves any level of popularity, it is more likely to actually get packaged and as a result, your end users are more likely to actually be able to easily make use of it. Distro package managers are a far superior solution than having 5 different language package managers you have to keep in sync and then having to compile your own software.

nicoburns 5y ago

> What work is there to do for me as someone who depends on a C library? Ignoring weird edge cases like OpenMP, it's trivial to write in my documentation "Depends on SDL v2" and add 'sdl2' to my libs array or whatever particular build system detail there is. As someone who isn't overly familiar with the C ecosystem: suppose I want to depend on SDL2, and I want my code to work across windows, macOS and linux. What does a minimal build config look like (in a build system of your choice)? And how (as a second developer or on a second machine) would I then use that config assuming it was committed as part of the codebase?

sanxiyn 5y ago
As I think this is a genuine question, I will answer accordingly. My build system of choice is CMake and my package system of choice is vcpkg. I will assume both are already setup. They are easy to setup on all of Windows/macOS/Linux by following the instruction. I tested. First, you need to find out the package name. Run vcpkg search sdl2. It tells you that the package is called sdl2. It is trivial in this case, but if you wanted SDL 1.x, it could have been called sdl, or sdl1. vcpkg search will tell you it's sdl1. Next, you install it by running vcpkg install sdl2. This will build from source. >1000 packages in the official repository should build cleanly, warning free, etc. Installation tells you how you should use the package with CMake. It is two lines. find_package(SDL2), and target_link_libraries(main SDL2::SDL2). To use CMake with vcpkg, copy and paste two lines to your CMakeLists.txt, and run CMake with CMAKE_TOOLCHAIN_FILE set to vcpkg.cmake. Yes, C situation is bad, but it is not as bad as people think.
Arch-TK 5y ago
GNUmakefile: LDLIBS += $(shell pkg-config --libs sdl2) CFLAGS += $(shell pkg-config --cflags sdl2) prog: prog.o Then you just run `make` or `gmake` (the developer should be aware of what his platform of choice prefers to call gnu make) and prog.c gets compiled to prog using the appropriate flags. I missed out some important details like setting the standard revision but I wanted to keep this short. This will work with gnu make, gcc and clang on linux, mac, any BSD, and windows (under wsl or msys or cygwin). Cross compilation is possible too. Personally I would use redo as the build system but this is shorter in make for such a simple project. More complex projects can be made to work with this basic pattern. When using autotools, cmake or meson you also have plenty of good options although I'm not entirely familiar with them as I don't use autotools, cmake or meson. Obviously this won't work if your machine is broken or if you don't have SDL2 installed in the correct place, but these are concerns for the package manager. The documentation simply needs to instruct you to install SDL2 (with development headers and the pkg-config definition). If you need a more advanced use-case such as you're trying to vendor the dependencies, you need to deal with PKG_CONFIG_PATH but I should stress that vendoring is NOT a normal use-case in the open-source-project-relying-on-sdl2 world.
- sanxiyn 5y ago
  The main deficit here is package manager. People are not writing yet another cross-platform package managers for no reason. Providing a consistent cross-platform experience is a value add. With "use system package manager", you'd need something like the following at least: On Windows/MSYS2, run pacman -S mingw-w64-SDL2. On macOS/Homebrew, run brew install sdl2. On Linux/DEB, run apt install libsdl2-dev. On Linux/RPM, run dnf install SDL2-devel. Which is no fun, not to speak of problems when versions in system package managers are different.
  - Arch-TK 5y ago
    Using the system package manager means that your software can actually in the future be packaged for a distribution. This is a major win in the sense that if your software ever achieves any level of popularity, it is more likely to actually get packaged and as a result, your end users are more likely to actually be able to easily make use of it. Distro package managers are a far superior solution than having 5 different language package managers you have to keep in sync and then having to compile your own software.