3 ms·

Which is exactly why I'll often try and keep build configuration in C++ #ifdef s. Everyone wants/needs proper Visual Studio projects in gamedev. And XCode pro

Which is exactly why I'll often try and keep build configuration in C++ #ifdef s. Everyone wants/needs proper Visual Studio projects in gamedev. And XCode projects. Maybe makefiles on top of that for some of your other platforms. Maybe a project generator to generate it all. Maybe some .props files to express things that the project generator can't. And then CI build server configuration on top of that. And then, because you're trying to another CI solution, a second CI build configuration. It's a mess of multiple unrelated tools - so it will never be in "one place" at the build system level. Shoving it in there anyways causes tons of duplicate build configuration logic. Alternatively, I could minimize the configuration in there - to just the bare minimum needed to drive high level configuration - and then centralize all the derived configuration in the one thing that's shared between them all: C++. C++ is a common denominator among my coworkers. When they have to dig through Gradle or Ant configuration because we're doing Android builds, I become a bottleneck. Lame. Yet another project generator? Ends up on my plate again. Lame. My coworkers have legitimately better things to be doing than becoming build system experts. They already understand "hey, I can pull configuration #define s into a separate file and only rebuild the things that #include it", meaning minor settings tweaks don't invalidate several build hours worth of compiled translation units, something I still don't know how to effectively do in some build systems.

monocasa 8y ago
I mean, that's the whole point of cmake, ninja, etc. They'll build all of those projects, complete with testing and other ancillary projects. You don't have to be an "build system expert". And you can absolutely make your build times better than what you're citing, coming from someone with binaries measured in tens of megs with templates out the wazoo. Just break up your dependencies. Seriously, you can almost certainly get ten to hundred times faster with only a little bit of work (which more than pays for itself in increased productivity).
- MaulingMonkey 8y ago
  > I mean, that's the whole point of cmake, ninja, etc. They'll build all of those projects, complete with testing and other ancillary projects. You don't have to be an "build system expert". Every company I've worked for has had a new an unique variation of which ones they use and how. Most recently, I've started submitting the occasional fix upstream for genie, a premake fork. They're a horrifically leaky abstraction though, and invariably I need to fix them, extend them, or partially sidestep them. By the time you've gotten up to speed on two or three of them well enough to effectively manage all that configuration, you've probably become a build system expert, if only to debug when they fall over. I guess you don't technically need to be one though? > And you can absolutely make your build times better than what you're citing, I mean, yes. It's an ongoing battle. I enumerated one of many improvements - breaking up your configuration dependencies. > coming from someone with binaries measured in tens of megs with templates out the wazoo. Typically I'm dealing with gigs of build outputs (tens of gigs including temps like .obj files) per individual cell of a rather large CI build matrix. My current job is no exception. > Just break up your dependencies. Trust me, I get it. I'm currently dealing with several hundred separately built projects. Coworkers are happy that VS2017 can load our .sln s faster, and we have our project generator able to select subsets of that in dozens of different ways. But I work on a large C++ codebases with macros. If I tweak something truly and fundamentally global - the configuration of if and how our assertion macros should expand, for example - no amount of "breaking up dependencies" is going to fix anything. I will have invalidated everything. The build server will rebuild everything, because that's a dependency in everything. Those macros are used in a large enough subset of TUs that we toss it in a precompiled header for improved build performance. That's legitimately the right choice, and it still means rebuilding literally every single TU. When that's configured as inherited global defines in a project generator, as they almost always are, and people add their own configuration defines there, as they almost always do to "keep things in one place" and all that, suddenly tweaking configuration options that are used in one place rebuild the entire tree. So I go to fix that when I find myself needing to tweak them. Say you have a network desync check assertion or debugging macro exposed by a networking module (we'll imaginatively call it 'network'.) Where do you drive the #define s configuring when it's removed? In the generator config for the network project's private defines? No, this is a public macro, stripping it from the consumers requires they see the config too. In the generator config for the network project's public/inherited defines? Touching that now means rebuilding everything that uses the network module, which might be a lot more widely used than the macro. In the generator config of each project that uses the macro, so they can specify which file(s) to make the configuration defines in? That's incredibly brittle and an invite to merge hell and a lot of duplicate configuration spread all over. In config_network_desync_checks.h? You can #include it from just the header that defines the macro. Tweaking it will only rebuild the TUs that actually depend on that file. You can still put them in "one place" (e.g. a central directory) if you want and still retain those advantages. You don't have to rerun your project generator, wait for it to rebuild everything, click through Visual Studio prompting you to let it reload the project, watch it hang or occasionally crash as it reparses things... you can just edit, let your build system recompile a few TUs, relink as needed, and then just run.
Annatar 8y ago
If they aren’t build systems experts, they have no business programming. Seriously. That’s their job as programmers. What kind of a programmer doesn’t know build systems?
- MaulingMonkey 8y ago
  Plenty of webdev doesn't (or at least didn't, once upon a time) involve build systems at all - with that in mind, why would a webdev need to know? Even now, what use does a frontend developer have for C++ build rules arcana when they don't even touch the language? And how many thousands of lines of msbuild rules have you written? Are you sure you're a build systems expert? :P Granted, I'm going to be extra thorough in a code review request from a webdev dabbling in C++. Similarly, I'd hope those same webdevs would be extra thorough in reviewing my dabblings in JavaScript. Programmers have different specializations - nothing wrong with that, properly supported. Some sacrifice breadth for depth, or vicea versa, and there's nothing wrong with those choices either.

monocasa 8y ago

I mean, that's the whole point of cmake, ninja, etc. They'll build all of those projects, complete with testing and other ancillary projects. You don't have to be an "build system expert". And you can absolutely make your build times better than what you're citing, coming from someone with binaries measured in tens of megs with templates out the wazoo. Just break up your dependencies. Seriously, you can almost certainly get ten to hundred times faster with only a little bit of work (which more than pays for itself in increased productivity).

MaulingMonkey 8y ago
> I mean, that's the whole point of cmake, ninja, etc. They'll build all of those projects, complete with testing and other ancillary projects. You don't have to be an "build system expert". Every company I've worked for has had a new an unique variation of which ones they use and how. Most recently, I've started submitting the occasional fix upstream for genie, a premake fork. They're a horrifically leaky abstraction though, and invariably I need to fix them, extend them, or partially sidestep them. By the time you've gotten up to speed on two or three of them well enough to effectively manage all that configuration, you've probably become a build system expert, if only to debug when they fall over. I guess you don't technically need to be one though? > And you can absolutely make your build times better than what you're citing, I mean, yes. It's an ongoing battle. I enumerated one of many improvements - breaking up your configuration dependencies. > coming from someone with binaries measured in tens of megs with templates out the wazoo. Typically I'm dealing with gigs of build outputs (tens of gigs including temps like .obj files) per individual cell of a rather large CI build matrix. My current job is no exception. > Just break up your dependencies. Trust me, I get it. I'm currently dealing with several hundred separately built projects. Coworkers are happy that VS2017 can load our .sln s faster, and we have our project generator able to select subsets of that in dozens of different ways. But I work on a large C++ codebases with macros. If I tweak something truly and fundamentally global - the configuration of if and how our assertion macros should expand, for example - no amount of "breaking up dependencies" is going to fix anything. I will have invalidated everything. The build server will rebuild everything, because that's a dependency in everything. Those macros are used in a large enough subset of TUs that we toss it in a precompiled header for improved build performance. That's legitimately the right choice, and it still means rebuilding literally every single TU. When that's configured as inherited global defines in a project generator, as they almost always are, and people add their own configuration defines there, as they almost always do to "keep things in one place" and all that, suddenly tweaking configuration options that are used in one place rebuild the entire tree. So I go to fix that when I find myself needing to tweak them. Say you have a network desync check assertion or debugging macro exposed by a networking module (we'll imaginatively call it 'network'.) Where do you drive the #define s configuring when it's removed? In the generator config for the network project's private defines? No, this is a public macro, stripping it from the consumers requires they see the config too. In the generator config for the network project's public/inherited defines? Touching that now means rebuilding everything that uses the network module, which might be a lot more widely used than the macro. In the generator config of each project that uses the macro, so they can specify which file(s) to make the configuration defines in? That's incredibly brittle and an invite to merge hell and a lot of duplicate configuration spread all over. In config_network_desync_checks.h? You can #include it from just the header that defines the macro. Tweaking it will only rebuild the TUs that actually depend on that file. You can still put them in "one place" (e.g. a central directory) if you want and still retain those advantages. You don't have to rerun your project generator, wait for it to rebuild everything, click through Visual Studio prompting you to let it reload the project, watch it hang or occasionally crash as it reparses things... you can just edit, let your build system recompile a few TUs, relink as needed, and then just run.

Annatar 8y ago

If they aren’t build systems experts, they have no business programming. Seriously. That’s their job as programmers. What kind of a programmer doesn’t know build systems?

MaulingMonkey 8y ago
Plenty of webdev doesn't (or at least didn't, once upon a time) involve build systems at all - with that in mind, why would a webdev need to know? Even now, what use does a frontend developer have for C++ build rules arcana when they don't even touch the language? And how many thousands of lines of msbuild rules have you written? Are you sure you're a build systems expert? :P Granted, I'm going to be extra thorough in a code review request from a webdev dabbling in C++. Similarly, I'd hope those same webdevs would be extra thorough in reviewing my dabblings in JavaScript. Programmers have different specializations - nothing wrong with that, properly supported. Some sacrifice breadth for depth, or vicea versa, and there's nothing wrong with those choices either.