Commit bfea6263 authored by David Johnson's avatar David Johnson

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
parent 7a890bce
Pipeline #404 passed with stage
......@@ -113,6 +113,11 @@ if test ${ENABLE_KERNEL} -eq 1 ; then
[egrep 'define (PACKAGE|VERSION)' include/libcap_config.h > include/libcap_config_internal.h
egrep -v 'define (PACKAGE|VERSION)' include/libcap_config.h > include/libcap_config.h.tmp
mv include/libcap_config.h.tmp include/libcap_config.h],[])
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment