3 ms·

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization.

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.

gpderetta 1y ago
> It's bespoke Makefile nonsense with zero hope of standardization technically Makefile is standardized (by POSIX), contrary to most alternatives. /extremely pedantic
pjmlp 1y ago
I would rather deal with Makefiles than Gradle.
- saghm 1y ago
  I think we can afford to strive for more than just "not quite the absolute worst" (for however we decide to measure quality).
einpoklum 1y ago
> I used to write a lot of C++ in 2017... It's bespoke Makefile nonsense 1. Makefiles are for build systems; they are not C++. 2. Even for building C++ - in 2017, there was no need to write bespoke Makefiles, or any Makefiles. You could, and should, have written CMake; and your CMake files would be usable and relevant today. > Meanwhile my gradle setups have been almost unchanged since that time ... but, typically, with far narrower applicability.
- feffe 1y ago
  CMake has become the defacto standard in many ways, but I don't think it's that easy to deal with. There's often some custom support code in a project (just as with make files) that you need to learn the intricacies of, and also external 3pp modules that solve particular integration issues with building software that you also need to learn. For me, base CMake is pretty easy by now, but I'd rather troubleshoot a makefile than some obscure 3pp CMake module that doesn't do what I want. Plain old makefiles are very hackable for better or worse [1]. It's easy to solve problems with make (in bespoke ways), and at the same time this is the big issue, causing lots of custom solutions of varying correctness. [1]: Make is easy the same way C is easy.
  - einpoklum 1y ago
    I didn't say "easy to deal with", I said it's not bespoke nonsense, and that you could keep it mostly unchanged today, 8 years later. Plus - the "obscure third party modules" have been getting less obscure and more standard-ish. In 2017 it was already not bad, today it's better.

gpderetta 1y ago

> It's bespoke Makefile nonsense with zero hope of standardization technically Makefile is standardized (by POSIX), contrary to most alternatives. /extremely pedantic

pjmlp 1y ago

I would rather deal with Makefiles than Gradle.

saghm 1y ago
I think we can afford to strive for more than just "not quite the absolute worst" (for however we decide to measure quality).

einpoklum 1y ago

> I used to write a lot of C++ in 2017... It's bespoke Makefile nonsense 1. Makefiles are for build systems; they are not C++. 2. Even for building C++ - in 2017, there was no need to write bespoke Makefiles, or any Makefiles. You could, and should, have written CMake; and your CMake files would be usable and relevant today. > Meanwhile my gradle setups have been almost unchanged since that time ... but, typically, with far narrower applicability.

feffe 1y ago
CMake has become the defacto standard in many ways, but I don't think it's that easy to deal with. There's often some custom support code in a project (just as with make files) that you need to learn the intricacies of, and also external 3pp modules that solve particular integration issues with building software that you also need to learn. For me, base CMake is pretty easy by now, but I'd rather troubleshoot a makefile than some obscure 3pp CMake module that doesn't do what I want. Plain old makefiles are very hackable for better or worse [1]. It's easy to solve problems with make (in bespoke ways), and at the same time this is the big issue, causing lots of custom solutions of varying correctness. [1]: Make is easy the same way C is easy.
- einpoklum 1y ago
  I didn't say "easy to deal with", I said it's not bespoke nonsense, and that you could keep it mostly unchanged today, 8 years later. Plus - the "obscure third party modules" have been getting less obscure and more standard-ish. In 2017 it was already not bad, today it's better.