this post was submitted on 04 Dec 2024
24 points (96.2% liked)
Programming
17666 readers
288 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So, I'm a bit rusty, but I believe in Kate you would hit F4 to get a terminal window and you would execute
gcc your_file.c -o your_output_file
Then after that's run you'd type just "your_output_file" and hit enter
I think on windows you'd need to make sure the output file name ends with .exe but I'm not sure about that, maybe someone else can chime in?
that does work, it's a little clunkier than i'd like but it's better than the code not running
Mate, I've built a career on that
That's kind of the bare bones of how it works, underneath all the abstraction layers and pretty GUIs.
Then it evolves.
First, you start splitting your code into multiple source files, either because your programs get too big to keep scrolling up and down one huge file to cross-check things, or because you want to incorporate someone else's code into your program, and it's more than just one or two functions you can easily copy and paste. You can still keep compiling and linking all of this in one step, but the command gets so long that you make a shell script/batch file as a shortcut.
After that, you might want to mix-and-match various source files to target different platforms, or to make other bulk changes, and you start going down the rabbit hole of having your shell script take arguments, rather than having a dozen different scripts. And then one day you take another look at "make" and realize that whereas before it seemed like impenetrable overengineering, it now makes complete and obvious sense to you.
Then you discover using "make" (or a similar utility) to split compilation and linking into separate steps, which used to seem nonsensical, but now you're dealing with codebases that take more than a couple of seconds to compile, or precompiled libraries or DLLs, and you get comfortable with the idea of just hanging on to compiled object files and (re)using them when the source for that part of the program hasn't changed.
And finally (maybe) you look at some of the crazy stuff in fancy IDEs and understand why it's there; that it's just representations of all this other stuff that you now know about and feel competent with. I say "maybe" because I've been programming for over 35 years, occasionally professionally but mostly as a hobbyist, and there are still things in IDEs that I either don't understand, or don't see the point of having them. But knowing the underlying principles makes me feel comfortable enough to ignore them.
Great!
But now try to set a breakpoint and do some debugging and you'll realise why most devs use real IDEs instead.
Dishonest and misleading. gdb ./main.elf, break 45. Learn your tools. Optimize for learning. Select tools that generalize. Avoid lock-in.