2021-06-26 17:16:06

@175
They're relying on the fact that every C developer who isn't learning knows how library and header include paths work and that many libraries also need preprocessor definitions specified at the command line, and not bothering to spell this out for you.  It's not advertised wrong.

The reason that you get pushed at build systems is because build systems can handle this kind of stuff.  Vcpkg then said "we need to pick one, how about CMake and msbuild" and then supported those.  Don't try to use msbuild: they support it because it's by Microsoft and it's incredibly hard to use and not cross platform. Stick to CMake.

For some idea of the complexity, I can build sdl in at least the following ways from my computer (a 64-bit X86): 32-bit with static linking, 64-bit with static linking, 32-bit with dynamic linking, 64-bit with dynamic linking, cross-compiled to arm with static or dynamic linking.  And I can do that with MSVC, Clang, GCC from Cygwin, or GCC from MinGW.  You can't mix and match these, it has to match what the rest of your app did.  That's easily 30 combinations.  And I haven't even looked to see what macros I can define that turn various parts of sdl on or off (it almost certainly has some).

You kinda sorta get away with this on Linux via apt because Linux has standard places to put include paths and libraries, but it's kinda sorta because those will compile for your machine and if you thought Windows was bad about this stuff, just start looking into distributing a binary that works on all 20 or so of the popular Linux distros.

My Blog
Twitter: @ajhicks1992

2021-06-26 18:07:53

I broke out sweats just by the very thought of distribution. Am I correct in assuming that compiling on linux for say, windows, is similarly complicated?

2021-06-26 18:33:59 (edited by camlorn 2021-06-26 18:34:31)

You basically need to compile your app on the platform your app is for.  You can technically cross-compile, but it tends to break in weird ways or you run into things like "haha this dependency used a Microsoft extension GCC doesn't support" or whatever.  A fully cross-platform app will require at least a Windows machine/VM, a Linux machine/VM, and an actual physical Mac.  For Windows in the blindness community you probably still need to compile a 32-bit version for at least Windows but maybe also Linux, though in the wider world that no longer matters.  Finally, for Linux distribution is a problem and you probably need to look at a variety of containerization solutions and other things that can hide/eliminate the incompatibilities between Linux distros.

CMake will hide compiler command line differences and to some limited extent can do things like find libraries even on Windows, CMake plus VCPKG will get you as far as having packages.  But you'll still need to deal with compiler and library differences.  For example, even though C++ filesystem support is a standard feature as of C++17, Synthizer has special checks because until GCC 9 you had to do an extra step, and GCC 9 is only like a year old so lots of Linux installs have older versions and can't/won't update their versions.  VC++ can be particularly bad about this in various ways.

The one place you can probably get away with cross compilation is Windows x86 to Windows Arm because Microsoft has gone out of their way to support it.  But if any of your dependencies use X86 intrinsics or assembly you'll lose out on that, cross compiling or not.  Sdl is fine.  Other things may not be.

Why do I use Python? Rust? Electron?  Lots of reasons but this particular hell is certainly high on that list.

My Blog
Twitter: @ajhicks1992

2021-06-26 18:49:07

Okay, I should have asked this question from the very beginning for the clearity. Can I expect things to be easier for me with CMake with use of libraries (Not getting into distribution?)

Just for actually creating some toy programs to get used to it.

Also curiosity, rust doesn't have this problem, judging from the last statement?

Also thanks for answering my questions. I realize it can be infuriating some times. (Scratch that, most of the time.)

2021-06-26 18:55:46

Nevermind libraries.  You need CMake if you don't want to put all your code in one file, and if you don't want to write a new set of makefiles or whatever for each platform.  There are other options, but either you're going to double down on C/C++ in which case whether it makes libraries easier isn't the point and you should go learn it, or you're leaving C/C++ in which case it doesn't matter.  But it integrates with vcpkg so from that perspective it makes libraries easier, it's got some scripts to help you find libraries if it can, and so on.

You will always need some access to all platforms to build your app, but most languages that aren't C/C++ avoid the standard library and language differences.  This means that you won't have to worry so much about platform specific code.  Additionally, most modern languages offer better dependency management and won't have the linker/include path issues, you can build on all platforms with the same command, and what version you're running doesn't depend on your operating system so much.

To be frank, I think you're at a decision point.  I'm honestly astonished you're still bothering with C.  You should decide here whether or not you want C to be your career.  If not, move to something easier.  Not Rust, Python or JS or something really high level.

My Blog
Twitter: @ajhicks1992

2021-06-26 19:03:51

I think that my unwillingness to let go of c has to do with the fact that it is my first language. I learned java as my second, which kind of made me depressed, (To be honest, the guy who was teaching me was responsible for it as well, you can only take so much praise for one language,) and probably because I have written nothing substantial.

I don't see myself as a professional low level programmer, if I did end up getting a job, it'll probably be python, or node.js.

2021-06-26 19:19:25 (edited by camlorn 2021-06-26 19:19:58)

Well I mean Java is terrible.  Most programmers I know hate Java, and most often the person defending it doesn't do programming in the tech sense, they do programming somewhere where the point is to be all enterprise and the code is considered boring and unimportant.  That's not universally true, but to be frank "I hate java" is something I use as an indicator of someone who is or will eventually be a good programmer.  I think maybe I've even talked about this somewhere in this thread already, but Java intentionally punishes the skilled programmer in order to make sure that the new programmer can't do things so badly wrong that it's unmanageable.  Then it fails at doing exactly that, kind of, but eh.  It's from the school of programming language design that wants to be able to throw an army of fresh college grads at a problem rather than a few skilled people and is willing to punish the skilled people to make that happen.

But unless you want to go into low-level coding C is a waste of your time.  It's the only language I know of where you have to script your build process.  It's 10 to 50 times harder than using something else in practice.  That said if you do go into lower level coding it's worth a  lot of money.

I currently do C and Rust.  Rust isn't exactly low-level, it's complicated, but it's not high level either.  99% of the world's software is written in something else, but most of the world's most important software is C/C++ and that won't change anytime soon.  Being able to handle it was and is my continuing path to frankly absurd amounts of money.  My most recent project which is public enough that I can talk about it is a thing that has to be able to handle hundreds of millions of requests a day in order to collect app analytics, and for something like that it's a low-level native language or it's "we're spending an additional $50000 on servers" so you don't have a choice really.  The Python/JS/etc stuff can make frankly ridiculous amounts of money too, and in terms of available positions it's probably about the same.  But C is a valid choice.  It's just the kind of valid choice where you're not going to be doing audiogames or something along the way, and need to go do stuff like contribute to the Linux kernel or something, and it is a very much harder path.  But in addition to the job security, your knowledge won't be outdated for at least 20 years.

But in any case: your choices are learn CMake and SDL, and maybe some C++ so that you have conveniences that C doesn't offer.  Or, well, not do that.  And which I think you should do depends a lot on whether you're doing C because it's interesting and you like where the career goes, or not.  Consider that (at least as far as I know) you've been doing this for months and your projects still aren't bigger than one file.  There is always a price to pay when learning programming.  The price of Python/JS and the like is that you will learn them quickly, then stagnate in your career for a while and have to spend a bunch of time learning some other tech like postgres and kubernetes to justify paying you more/moving up the ladder.  The price of C is that you have a massively huge learning cliff at the beginning that you have to climb over, if you will, and you're not going to put out a bunch of software along the way while you learn it because it's hard.

My Blog
Twitter: @ajhicks1992