5 ms·

Doesn’t seem to offer much over just using clang.

jmull 3y ago
Here's some more info why you might use this instead of plain clang. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
klardotsh 3y ago
Other than the complete lack of writing CMake, Makefiles, autoconf, or any number of other end-user-configuration complicated systems as such, and other than the trivial statically-linked cross-compilation support, sure, I guess it's "just" a wrapper around clang, if you squint.
- david2ndaccount 3y ago
  If you aren’t supporting more than one compiler, almost all of those tools vanish. You can just use clang.
  - klardotsh 3y ago
    If you aren't supporting more than one compiler, aren't needing to compile anything in parallel, aren't needing to find and link shared libraries on the system, aren't needing to deal with any number of real complexities that happen when building C software, then sure, build.sh calling clang a few times manually is absolutely reasonable. (And again: cross-compilation is a real concern: shipping for amd64 only is not enough in 2023). And to be clear - there are plenty of small-scale projects that fit this description! But to simply hand-wave away `zig build` or other modernized build systems and say "just use clang directly" seems a bit dishonest or incomplete to me.
    - david2ndaccount 3y ago
      Note that I am not advocating for just having a few shell scripts that invoke clang. The context is someone saying to use `zig build`, and linking a blog post where all they do is compile redis from scratch, including all dependencies from source except for libc. In that context, `zig build` is just a wrapper around clang. Nowhere in their comment or linked blog post is the issue of these real complexities you allude to addressed at all. Now I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C projects instead of a cross-platform C compiler, but people can do whatever they want.
  - reverius42 3y ago
    Or more than one operating system, or more than one stdlib, etc., etc.
  - convolvatron 3y ago
    to be fair - my goto move on a smallish project when autoconf barfs is 'cc *.c -o foo'. it works pretty damn often, sometimes you need to throw in some -I action
- rewmie 3y ago
  > or any number of other end-user-configuration complicated systems as such If you think that cmake is complicated, when in reality all it does is set targets using a declarative stye, then programming might not be for you.
  - klardotsh 3y ago
    Personal attacks are pretty unnecessary here, thanks. This kind of comment is what gives (some) C developers the reputation they have in some circles, I guess.
  - duped 3y ago
    > when in reality all it does is set targets using a declarative stye That's like the hello world of cmake builds Bigger cmake builds are doing dependency resolution, configuration tests, and configuration for development or release builds/installs. Go poke at the cmake logs and result artifacts in Debug/Release build types and see if it's "just declaring targets."
    - rewmie 3y ago
      > Bigger cmake builds are doing dependency resolution, find_package(foo) #... target_link_libraries(myapp foo::Static) > configuration tests, I don't know what you mean by configuration tests. I don't think I ever added any test resembling that description other than sanity checks in cmake find modules and sanity checks on projects just for convenience. > and configuration for development or release builds Those are not handled by cmake other than setting a flag that's used in the code. > /installs. You don't need to do anything other than setting the install target. https://cmake.org/cmake/help/latest/command/install.html https://cmake.org/cmake/help/latest/command/install.html I think you're either wildly exaggerating or you've been creating your own problems.
      - duped 3y ago
        Ok. How does find_package work? Hint: you need to understand how cmake module paths are discovered and their precedence, and you'll probably see a cmake folder in a build with the actual logic behind it as a .cmake file for each dependency. Depending on what package manager you're using you may not need this, or if you support many you'll need to own it. > I don't know what you mean by configuration tests. When you run cmake -S <my project> -B build folder you'll see a bunch of output. What this output corresponds to may include a number of tests that either succeed or fail to indicate whether the project will build. For example, the aforementioned find_package logic, finding the compiler tool chain (especially if cross compiling), testing for random shit like endianness, etc. > Those are not handled by cmake other than setting a flag that's used in the code. if(STREQ ${CMAKE_BUILD_TYPE} Release) .... endif() Is ridiculously common with the "..." filled in by various things like setting optimization flags, paths within the build directory, etc > You don't need to do anything other than setting the install target. No but you should probably understand what RPATH is and why it's set in release builds but not installed artifacts or why doing something that seems obvious like checking the checksum of your built object is the same as the installed one might fail. The point is that cmake does a lot of work and it's not just declaring targets. Builds are hard.
- schemescape 3y ago
  Out of curiosity, what DO you write instead of Makefiles in this case? I’m genuinely curious if it’s actually easier, but I’m assuming you’re just using a different tool, maybe without as much historical baggage (and incompatible implementations)…

Here's some more info why you might use this instead of plain clang. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

klardotsh 3y ago

Other than the complete lack of writing CMake, Makefiles, autoconf, or any number of other end-user-configuration complicated systems as such, and other than the trivial statically-linked cross-compilation support, sure, I guess it's "just" a wrapper around clang, if you squint.

david2ndaccount 3y ago
If you aren’t supporting more than one compiler, almost all of those tools vanish. You can just use clang.
- klardotsh 3y ago
  If you aren't supporting more than one compiler, aren't needing to compile anything in parallel, aren't needing to find and link shared libraries on the system, aren't needing to deal with any number of real complexities that happen when building C software, then sure, build.sh calling clang a few times manually is absolutely reasonable. (And again: cross-compilation is a real concern: shipping for amd64 only is not enough in 2023). And to be clear - there are plenty of small-scale projects that fit this description! But to simply hand-wave away `zig build` or other modernized build systems and say "just use clang directly" seems a bit dishonest or incomplete to me.
  - david2ndaccount 3y ago
    Note that I am not advocating for just having a few shell scripts that invoke clang. The context is someone saying to use `zig build`, and linking a blog post where all they do is compile redis from scratch, including all dependencies from source except for libc. In that context, `zig build` is just a wrapper around clang. Nowhere in their comment or linked blog post is the issue of these real complexities you allude to addressed at all. Now I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C projects instead of a cross-platform C compiler, but people can do whatever they want.
- reverius42 3y ago
  Or more than one operating system, or more than one stdlib, etc., etc.
- convolvatron 3y ago
  to be fair - my goto move on a smallish project when autoconf barfs is 'cc *.c -o foo'. it works pretty damn often, sometimes you need to throw in some -I action
rewmie 3y ago
> or any number of other end-user-configuration complicated systems as such If you think that cmake is complicated, when in reality all it does is set targets using a declarative stye, then programming might not be for you.
- klardotsh 3y ago
  Personal attacks are pretty unnecessary here, thanks. This kind of comment is what gives (some) C developers the reputation they have in some circles, I guess.
- duped 3y ago
  > when in reality all it does is set targets using a declarative stye That's like the hello world of cmake builds Bigger cmake builds are doing dependency resolution, configuration tests, and configuration for development or release builds/installs. Go poke at the cmake logs and result artifacts in Debug/Release build types and see if it's "just declaring targets."
  - rewmie 3y ago
    > Bigger cmake builds are doing dependency resolution, find_package(foo) #... target_link_libraries(myapp foo::Static) > configuration tests, I don't know what you mean by configuration tests. I don't think I ever added any test resembling that description other than sanity checks in cmake find modules and sanity checks on projects just for convenience. > and configuration for development or release builds Those are not handled by cmake other than setting a flag that's used in the code. > /installs. You don't need to do anything other than setting the install target. https://cmake.org/cmake/help/latest/command/install.html https://cmake.org/cmake/help/latest/command/install.html I think you're either wildly exaggerating or you've been creating your own problems.
    - duped 3y ago
      Ok. How does find_package work? Hint: you need to understand how cmake module paths are discovered and their precedence, and you'll probably see a cmake folder in a build with the actual logic behind it as a .cmake file for each dependency. Depending on what package manager you're using you may not need this, or if you support many you'll need to own it. > I don't know what you mean by configuration tests. When you run cmake -S <my project> -B build folder you'll see a bunch of output. What this output corresponds to may include a number of tests that either succeed or fail to indicate whether the project will build. For example, the aforementioned find_package logic, finding the compiler tool chain (especially if cross compiling), testing for random shit like endianness, etc. > Those are not handled by cmake other than setting a flag that's used in the code. if(STREQ ${CMAKE_BUILD_TYPE} Release) .... endif() Is ridiculously common with the "..." filled in by various things like setting optimization flags, paths within the build directory, etc > You don't need to do anything other than setting the install target. No but you should probably understand what RPATH is and why it's set in release builds but not installed artifacts or why doing something that seems obvious like checking the checksum of your built object is the same as the installed one might fail. The point is that cmake does a lot of work and it's not just declaring targets. Builds are hard.
schemescape 3y ago
Out of curiosity, what DO you write instead of Makefiles in this case? I’m genuinely curious if it’s actually easier, but I’m assuming you’re just using a different tool, maybe without as much historical baggage (and incompatible implementations)…