Testing for features is the right way to go. If you add support for a new platform, there is no guarantee that the tests will all magically work. But a lot of them, in fact will. That reduces the amount of remaining work.
You could have a canned set of files, one per platform, containing some canned settings of variables. (The Pine e-mail program was a good example of this; its Alpine successor uses Autoconf.)
If you are porting to a new system, you have to guess which of the existing canned configurations is the closest one that will work and use it as a template.
Since there is no logic to detect if any of the features related to the configuration variables is actually present and in what form, it's just guesswork. Okay, it doesn't build. Now which of the relevant variables in the canned config is related to that breakage?
Only test for the features you actually care about, though. And at this point, it's perfectly fine for a new project to assume some baselines like POSIX-1996 and even C99 (unless you're targeting Windows...).