3 ms·
There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself. How do you check for headers? How do you check for
by zuzun 10y ago
There's no way you can do what autotools does in a Makefile without implementing
half of autotools yourself. How do you check for headers? How do you check for functions?
How do you test if qsort_r expects
(*)(void*, const void*, const void*)
or
(*)(const void*, const void*, void*)
as function pointer? If people are forced to detect that kind of stuff in Makefiles, they get the urge to match `uname` against some hard-coded platforms and that's a terrible
solution.
- coldtea 10y ago>There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself. That's part of the argument: with standards compliant code, you don't need to do "what autotools does".
- zuzun 10y agoENOTSUP is part of the standard and I do have autotools macros checking if some function calls produce that error value on the host system.
- 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"
- maxlybbert 10y ago> How do you test if qsort_r expects > (*)(void*, const void*, const void*) > or > (*)(const void*, const void*, void*) You can write C++ code that uses templates and SFINAE to do it. I have. I will admit, it looks like garbage. But it is possible.
- jandrese 10y agoWho uses the latter form? I don't think I've ever seen that before. Also, isn't the first supposed to be: void*, size_t, size_t, int (*cmp)(const void*, const void*) Or are you using some wtf version that hides the element size and count behind a void*?
- maxlybbert 10y agoThe signatures came from another answer. I have no idea what the signatures are, or should be, or why there's a difference. My SFINAE code was to handle a similar problem picking between a GNU-specific strerror_r and a POSIX strerror_r that have different signatures (both are available on Linux, determined by whether certain macros are set: https://linux.die.net/man/3/strerror_r https://linux.die.net/man/3/strerror_r , I couldn't just rely on those macros because I wanted my code to compile on any POSIX platform).
- zbuf 10y agoYou're commenting on the prototype for qsort() itself, whereas the original point was about the function pointer that is an argument to qsort_r(). Both Linux and BSD chose to add a non-standard qsort_r(), each choosing different ways to do it.