3 ms·
> There's a complete dearth of decent guides for how to setup a C/C++ environment with dependencies, including some sort of build system, and it's often been m
by P_I_Staker 3y ago
> There's a complete dearth of decent guides for how to setup a C/C++ environment with dependencies, including some sort of build system, and it's often been my biggest stumbling block.
Disagree. I had to learn make for my first job. I found two ways to manage dependencies that are probably the most common, and the limitations. There really isn't a method that is perfect; I don't know if dependencies can be done (even outside of C) without occasionally rebuilding.
The methods that I've seen rely on using the compiler to generate .h dependencies via the preprocess command. This can be done with gcc / cygwin for cross compilation, or with the native compiler. I'll explain.
Method 1: the "better" method. Generate dependencies for your header files at make invocation, before compile step. This is more robust, but outside of very small projects, this can add a ton of time to the build.
Method 2: the faster, more common method. Generate dependencies as a side effect of the build. When you compile, you use the previous dependencies. A new dependency file is generated for next time.
They both have limitations. Method 2 can detect changes in the header files included from C files, but not headers included from H files. Method 2 can detect changes in header chain, but not all the time. I think it's the files that the headers include, those includes from that file don't get updated, but it's been a while since I've read the paper.
Anyway neither method is that hard. You use gcc to generate dependencies for each file, then combine into one file (or you may create .d files, but for some reason a single file is common). That's it.
Otherwise, add a step to compilation (some compilers may have a build in "byproduct" command). Every time you generate .c there's also .d. When you compile, you use the previous *.d file.
Yes you need to know make, and this is an intermediate-to-advanced make task, but this is true for any build system! Entry level is a user that usually just adapts a build from the engineer experienced with the build system.
- Sakos 3y agoAnd none of this is ever really explained anywhere step-by-step.
- P_I_Staker 3y agoI've seen very good guides, I wish I had one on hand. I saw both of the examples first hand and assumed these were the "main" ways to get the job done. When developing for a very small project the generate dependency first method was used. It's more complete. Still added an annoying amount of time to the build ~20-60 sec. For our main project (which also might be considered fairly small, relatively) this method ends up being too time consuming. So the generate dependencies as a byproduct of build method is typically employed, including by: a completely separate team, a competent supplier, and recommended by our compiler company. Honestly, once you know, you're golden: The generate ahead can be done with gcc (I think g++ is typically employed) via the preprocess command. You create a rule to generate all *.d first, and combine into one file (this may not be necessary). To generate as a byproduct, you simply add a command to your compile rule. That's it. Can be described in one line. I can't recall offhand, but you will need to figure out how to include the dependency files and the formats may need fine tuning. This isn't asking very much. I saw a really good document out there, and interestingly our supplier copied it almost verbatim. Our build ended up being somewhat similar. So that sweet, sweet doc is out there, you just gotta find it.
- lmz 3y agoThis guide, maybe? https://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ https://make.mad-scientist.net/papers/advanced-auto-dependen...