4 ms·

my point is that in this case there are no libraries to be "detected" at all. This is just vanilla ansi C without any requirement besides the standard C librar

my point is that in this case there are no libraries to be "detected" at all. This is just vanilla ansi C without any requirement besides the standard C library. This can be compiled anywhere without need to "detect" anything. EDIT: I put "detect" in quotes, because I find the whole concept of detecting libraries ridiculous in a context of a C program. Either a library XYZ is installed on my system, in which case the compiler finds it with the -lXYZ flag, or it isn't. If it is not installed, I expect the compilation to fail. I do not expect the build system to look in my hard disk by itself and try to find some files that look like the XYZ library; that would be extremely untoward.

rightbyte 8y ago
The CMake script is platform independent. Otherwise you everyone would have to write a build file themself. The linker would look for the lib anyway so you can just as well have CMake try it before linking.
derefr 7y ago
> I find the whole concept of detecting libraries ridiculous in a context of a C program. Either a library XYZ is installed on my system, in which case the compiler finds it with the -lXYZ flag, or it isn't. If it is not installed, I expect the compilation to fail. Things autoconf/cmake does: • decides whether the system version of a lib is "good enough" to use in place of a vendored copy (e.g. the vendored libxml in Ruby's Nokogiri) • detects libraries (and system calls) that nominally obey some standard, but use nonconformant names/types for their implementation of the standard; and generates shim source files which wrap these functions to give them the correct name/type to allow your code to blindly link to the standard symbol and have it "just work" on the system in question. • generates header files full of defines saying which optional (system/library) features were discovered as being available or not in the linked version of the (system/library). You can then use these defines to decide which implementation to use in your code, in such a way that you won't ever be attempting to reference a (static) symbol that doesn't exist in the library you ended up linking to. • for entirely nonstandard APIs (e.g. kernel semaphores), lets you just use the API of the version you know, and then shims it into the totally different API used by this particular system. Or, on systems that sometimes have both an advanced implementation and a basic one, and sometimes only have the basic version (such as Linux pre/post introduction of io_uring), generates a shim to translate the advanced stuff to the basic stuff on systems where the advanced stuff isn't available. The goal of projects like autotools and cmake, is to make code portable to every platform they can, even if the platform is utter bollocks. They do a bunch of seemingly-silly stuff so that e.g. you can write code that calls into POSIX-standardized system facilities, developing solely on Linux; and then someone can download your project on macOS and it'll turn out to compile and run perfectly, without you ever having tested on macOS—even though macOS doesn't even have the system facilities you called into. Or, to put that another way: these build tools are to C, as "ECMA$n-shim.js" is to Javascript.
- enriquto 7y ago
  > Things autoconf/cmake does: (...) All these things are horrifying! The problem does not seem to be "bollocks" platforms, but bollocks programs. If you code really depends on a specific version of a standard library, shame on you. Anyhow, the code in question here does not need more libraries than "hello.c", which is naturally portable to whatever platform without the humongous help of cmake.

rightbyte 8y ago

The CMake script is platform independent. Otherwise you everyone would have to write a build file themself. The linker would look for the lib anyway so you can just as well have CMake try it before linking.

derefr 7y ago

> I find the whole concept of detecting libraries ridiculous in a context of a C program. Either a library XYZ is installed on my system, in which case the compiler finds it with the -lXYZ flag, or it isn't. If it is not installed, I expect the compilation to fail. Things autoconf/cmake does: • decides whether the system version of a lib is "good enough" to use in place of a vendored copy (e.g. the vendored libxml in Ruby's Nokogiri) • detects libraries (and system calls) that nominally obey some standard, but use nonconformant names/types for their implementation of the standard; and generates shim source files which wrap these functions to give them the correct name/type to allow your code to blindly link to the standard symbol and have it "just work" on the system in question. • generates header files full of defines saying which optional (system/library) features were discovered as being available or not in the linked version of the (system/library). You can then use these defines to decide which implementation to use in your code, in such a way that you won't ever be attempting to reference a (static) symbol that doesn't exist in the library you ended up linking to. • for entirely nonstandard APIs (e.g. kernel semaphores), lets you just use the API of the version you know, and then shims it into the totally different API used by this particular system. Or, on systems that sometimes have both an advanced implementation and a basic one, and sometimes only have the basic version (such as Linux pre/post introduction of io_uring), generates a shim to translate the advanced stuff to the basic stuff on systems where the advanced stuff isn't available. The goal of projects like autotools and cmake, is to make code portable to every platform they can, even if the platform is utter bollocks. They do a bunch of seemingly-silly stuff so that e.g. you can write code that calls into POSIX-standardized system facilities, developing solely on Linux; and then someone can download your project on macOS and it'll turn out to compile and run perfectly, without you ever having tested on macOS—even though macOS doesn't even have the system facilities you called into. Or, to put that another way: these build tools are to C, as "ECMA$n-shim.js" is to Javascript.

enriquto 7y ago
> Things autoconf/cmake does: (...) All these things are horrifying! The problem does not seem to be "bollocks" platforms, but bollocks programs. If you code really depends on a specific version of a standard library, shame on you. Anyhow, the code in question here does not need more libraries than "hello.c", which is naturally portable to whatever platform without the humongous help of cmake.