A last piece of the hack to work around config.h in public headers.
This is sick. I should have just reorg'd the headers. This should be baked out ASAP. It elides the core libcap_config.h conflicts to allow multi-package-config.h includes. autofoo doesn't help at all with this, but why should they? Shouldn't include config.h in public stuff. This is the same commit as I did for openmul. That one was defensible (way too much code to reorg the headers); this one, not so much... but I don't have time to reorganize the headers. Here's basically the same commit msg to explain things: Every time you think you've reached a new low with autotools, you're wrong. This is my way to get around the standard installable config.h problem. Basically, libcap wants you to include headers that require config.h, but of course things that use libcap have config.h of their own. So -- we take the hacky approach and remove the things that will obviously conflict and stick them in mul_config_internal.h . I'm sure my way of doing this will be missed if config.status include/libcap_config.h is ever run to regen libcap_config.h, but I can't solve that one right now.
Showing with 5 additions and 0 deletions