[throwaway9d0291]

Sure, it can be simple.

To give you a less clear example, think about writing a library that sends telemetry to some cloud service. The telemetry could be readings from a sensor attached to a microcontroller with 512K of RAM or it could be readings from a server sitting in a datacenter with 256GB of RAM.

You need some helper library to handle the protocol and there's a really nice full-featured library that comes with a bunch of handy debugging tools but it's too memory-hungry for that tiny microcontroller.

Another option is a minimalist library that uses very little memory but also has less flexibility in say TLS.

If you pick just one, one of your platforms ends up suffering needlessly.

Adding the options allows the user to decide what's best for them.

[enriquto]

Sure, you can have different make targets if you really need to. Or Makefile.linux and Makefile.embedded everybody understands what to do in that case.

I simply don't understand the explosion of complexity associated to autotools, cmake, and the like.

[rcxdude]

Because the cartesian product of options quickly explodes and you're suddenly managing 256 targets or makefiles (though even in Make there's a better way to handle this, though it's made painful by the syntax). It's very common for larger pieces of software to have 30-50 different configuration options for building.

[rualca]

> I simply don't understand the explosion of complexity associated to autotools, cmake, and the like.

If you refer to tools like cmake as "explosion of complexity" then I have to say that you are using them entirely wrong, and you should review your practice thoroughly.

I mean, cmake is a makefile generator. You specify a high-level description of your project, and then you run cmake for it to generate your Makefile that performs the whole build.

With cmake you don't even care which compiler you use. You can simply state you require, say, c++ 14 with constexpr support and you're done for all platforms and all compiler picks.

If you believe cmake is more complex than a makefile then either you only work on single-foot projects or you have been cursed with hideously managed cmake projects.

[db48x]

It's not just about libraries.

Autoconf for example can abstract across different compilers from different vendors, with all their various incompatible command–line arguments. And it does that for a dozen or so different languages, not just C.

It can abstract across different function signatures in the libraries you're using. For example if you're calling a libc function where the arguments have changed, you can detect which version of the function you have and make your code work with either one.

It can do the same for structs and types as well.

It can test for system services, such as X Windows or the ability to run Perl scripts.

It can abstract over the differences between different implementations of common utility commands such as awk, grep, install, mkdir, and so on.

It does a lot of stuff!

[enriquto]

> It does a lot of stuff!

Of course it does. My point was that I've never found it did anything that I was interested in.

[db48x]

Then it wasn't written for you. It was written for people who want to distribute software to users who do not all run the same Unix operating system (not to mention the radically incompatible hardware of the day), and whose Unix vendors are all mutually hostile to any form of cooperation with each other. If all you ever install your software on is Ubuntu running in a VM at your cloud provider, then of course this will all be irrelevant to you.