[HN Gopher] A Modern C Development Environment
___________________________________________________________________
A Modern C Development Environment
Author : 5ADBEEF
Score : 36 points
Date : 2023-08-10 21:08 UTC (1 hours ago)
(HTM) web link (interrupt.memfault.com)
(TXT) w3m dump (interrupt.memfault.com)
| anon7331 wrote:
| My idea of a C development environment has always been Vim, Tmux
| and a decent compiler.
| 0xbadcafebee wrote:
| since the container is executed in a VM, the I/O performance is
| significantly worse compared to a container that is run
| natively. For compiled languages or for any process that creates
| a lot of files, this impact can be significant since the
| overhead can be up to 100x of what you're experiencing natively
|
| Uhhhhhhh. I don't know what VM you're using... but if the I/O in
| your VM is 100x slower than the host, you can fix that. It should
| not take a minute and a half to write a single file.
| maccard wrote:
| I'm guessing OP is on Docker for Mac. This isn't so much a VM
| is slow, it's that file IO on docker for mac on mounted volumes
| is _dog_ slow. (It 's not exactly ripping fast on windows
| either).
|
| If you don't mount the intermediate directory, it'll be _way_
| faster. Alternatively, use OrbStack (I feel like I 'm shilling
| this a lot recently, I'm just a happy user), and the problem
| goes away.
| p_l wrote:
| Sounds like a case of "Running Docker Desktop on a Mac and
| editing file on filesystem mounted from host".
| znpy wrote:
| More like: writing to an overlay filesystem mounted on top of
| several more overlay filesystem running in a linux virtual
| machine started by docker desktop on a mac.
| maccard wrote:
| I'm a big containers fan, they work really well (assuming you're
| not developing with MSVC). They give you a repeatable build
| environment, which is a boon for something like C where you're
| implicitly depending on system include paths for versioning.
|
| I said this elsewhere, but you'll get a pretty decent perf boost
| if you set your build intermediate directory outside your mounted
| volume.
|
| Instead of rm -rf /var/lib/apt/lists/*, running `apt-get clean`
| as part of that layer will help more.
|
| Wrapping docker commands with makefiles is sad times. Use
| https://magefile.org/ or a task runner instead. Try to avoid
| making it a scripting language dependency.
|
| Installing ruby to install a build system when you're using cmake
| in the container is a bit bonkers, and the cause of the majority
| of the "bloat" here. I'd replace it with calls to cmake and unity
| directly. (And honestly, if you're going as far as using cmake,
| I'd ditch C altogether and usea subset of C++ with gtest)
|
| But honestly, that's about all I can complain about. This is a
| neat, modern workflow.
| anotherhue wrote:
| Also see:
|
| Make Zig Your C/C++ Build System
|
| https://zig.news/kristoff/make-zig-your-c-c-build-system-28g...
|
| Edit: this is a better demo (thanks jmull)
| https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
| david2ndaccount wrote:
| Doesn't seem to offer much over just using clang.
| jmull wrote:
| Here's some more info why you might use this instead of plain
| clang.
|
| https://andrewkelley.me/post/zig-cc-powerful-drop-in-
| replace...
| klardotsh wrote:
| 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 wrote:
| If you aren't supporting more than one compiler, almost all
| of those tools vanish. You can just use clang.
| klardotsh wrote:
| 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 wrote:
| 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 wrote:
| Or more than one operating system, or more than one
| stdlib, etc., etc.
| rewmie wrote:
| > 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.
| duped wrote:
| > 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."
| klardotsh wrote:
| 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.
| 38 wrote:
| > A Modern C Development Environment
|
| OK fine
|
| > 09 Aug 2023
|
| huh? the correct answer to this question should be "get a time
| machine and go back to 2003 or something. why people insist on
| carrying on with C in the face of its glaring issues is beyond
| me. I am not advocating for any specific language, because
| several other languages are around that might be a better fit.
| Rust, Zig, D, Nim, Go. just please let C die already.
| ryan-c wrote:
| At the risk of being featured in a future episode of "Hacker News
| reacts to (Dropbox|iPhone)"...
|
| ...a Makefile and vim (or emacs, or even nano, I'm not going to
| judge your kink) are fine. If they are not fine, then C is
| probably not the right language for the project.
| heisenzombie wrote:
| I don't quite understand the sentiment.
|
| So, let's say we have a project. For whatever technical (or
| social, historical, religious...) reason, C is chosen as the
| right language.
|
| Why does that imply that the programmers on that project should
| therefore write that C code in a terminal, with no linter, code
| formatter, static analysis, test runner, etc.?
| maccard wrote:
| A dockerfile gives a clean, repeatable build environment. If
| there is ever a toolchain that needed that, it's native
| toolchains like gcc and clang.
| [deleted]
| xaduha wrote:
| > If they are not fine, then C is probably not the right
| language for the project.
|
| It's for C/C++ as author says, not just for C. And even if
| you're using Qt and write mostly QML you still need some C++
| and it's much easier with code completion. I'd rather use
| VSCode than Qt Creator for that and I'm certainly not going
| back to vim.
| Aurornis wrote:
| > If they are not fine, then C is probably not the right
| language for the project.
|
| This is called gatekeeping and it's not helpful.
|
| It's fine to write C in vim/emacs/nano if you want.
|
| It's fine to write C in Visual Studio Code if you want.
|
| It's fine to write C in CLion if you want.
|
| There is nothing wrong with any approach and no need to
| gatekeeper an entire programming language based on editor
| preference.
| the-printer wrote:
| Is it really gatekeeping? Does this opinion (that was valid
| and useful to me) carry any preventive force that the term
| suggests?
| bryancoxwell wrote:
| It dissuades people who aren't comfortable with Makefiles
| and Vim from using C, so I'd agree it's gatekeep-y.
| Aurornis wrote:
| The colloquial definition of "gatekeeping" doesn't require
| literal preventative force.
|
| See
| https://www.urbandictionary.com/define.php?term=Gatekeeping
| sophacles wrote:
| The term has become common on the web to refer to
| enthusiasts trying to control how people enjoy/use a term
| or participate in an activity - for instance "real fans
| only like the stuff from before $album" or "only filthy
| casuals play the game that way" (or "you shouldn't use C if
| you want modern, good tooling"). This might be worth
| reading through:
|
| https://www.urbandictionary.com/define.php?term=Gatekeeping
| rewmie wrote:
| > ...a Makefile and vim (or emacs, or even nano, I'm not going
| to judge your kink) are fine. If they are not fine, then C is
| probably not the right language for the project.
|
| Sorry buddy, you might believe Makefiles are fine only if you
| are not aware of the most basic requirements of a build system.
| CMake does stuff like running sanity checks on libraries,
| configure them for you with minimal effort, and even add
| platform-specific configuration easily. Did you know that cmake
| started as a Makefile generator? Why do you think people need
| that?
|
| Makefiles alone were never enough, as the development of tools
| such as the autotools family demonstrated decades ago. Claiming
| otherwise just seems naive flexing from someone who has no real
| world experience whatsoever.
| znpy wrote:
| > Did you know that cmake started as a Makefile generator?
| Why do you think people need that?
|
| I like make myself, but I'm honest enough to acknowledge that
| the whole autotools suite (autoconf/automake) was born to,
| essentially, generate makefiles.
|
| Which is not 100% make's complexity's fault though... the
| toolchains have their own complexity (even more so when a
| project must build across platforms)...
| sfpotter wrote:
| Strongly recommend using meson or CMake instead of Make unless
| you have a very specific reason you can't use one of these
| tools.
| jjgreen wrote:
| I once had to compile cmake from source (the cmake version of
| something I needed to build was lower that the OS version of
| cmake). Not a fun afternoon.
___________________________________________________________________
(page generated 2023-08-10 23:00 UTC)