3 ms·
> no way you can do what autotools does in a Makefile Well, you're responding to something that wasn't actually said; "these things" quotes specifically the li
by zbuf 10y ago
> no way you can do what autotools does in a Makefile
Well, you're responding to something that wasn't actually said; "these things" quotes specifically the list of requirements given by the previous poster -- CFLAGS etc.
Your example is indeed valid, it's an ugly case and I agree that testing for the feature specifically (rather than arch, compiler) is always preferred. But let's look at the practicalities -- how many of these cases do I actually need in a codebase to tip the balance that would justify use of autoconf? In your example, a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. qsort_r is off limits for massively portable program anyway, so autoconf's ability to help is limited anyway.
- marcosdumay 10y ago> a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. That's equivalent to the uname trick the GP was complaining about. That means your software won't compile in a lot of platforms. On a small scale, I don't think that's a big problem. Somebody on those platforms only has to add the correct conditions to your #ifdef forest and if he sends the update back, other people on the same platform won't even have the same problem. It's not much different from software not working on untested platforms. It starts becoming a problem when done often, or on high level (at the calling stack) code.
- zbuf 10y ago> That means your software won't compile in a lot of platforms. Is won't anyway; qsort_r has already limited me to a tiny number of platforms. If I care about further portability, autotools can't do anything to help me; my next step is not autotools, it's "don't use qsort_r"