Example of usage: https://reviews.freebsd.org/D8754

Why do we need a separate library for this? Why not just turn MK_CASPER=no into the equivalent of cap_enable() -> false?

The behavior of few functions are a little bit different libcasper and libcaspermock but this still could be merged somehow.
The only situation I can think of where you would like to have two libraries is when you would install something from ports which you don't want to use Casper and your base system is using Casper.

In D8753#181465, @oshogbo wrote:

The only situation I can think of where you would like to have two libraries is when you would install something from ports which you don't want to use Casper and your base system is using Casper.

That feels a little contrived :-).

I don't really much like this approach, plus there is a high risk to have libcaspermock and libcasper out of sync

Maybe what I'm about to say is blasphemy in our circles, but it looks like this tries to solve a problem that an object oriented programming language with virtual functions (C++) could easily solve. libcasper's header file would provide declarations for abstract base classes for all sorts of handles. Then there are two implementations of these classes: one that acts as a no-op and one that is actually built on top of Capsicum. That way there is no need to resort to linker tricks.

Would you please upload a diff with full context (-U9999)? Thanks.

From in-person working group session, a suggestion to rename libcasper.h to libcasper.h.in and run unifdef on it during install.

% cat example.h.in
// example header file
#ifdef WITH_CASPER
// casper version
#else
// non-casper version
#endif

% unifdef -UWITH_CASPER -o example.h example.h.in
% cat example.h                                  
// example header file
// non-casper version

% unifdef -DWITH_CASPER -o example.h example.h.in
% cat example.h                                  
// example header file
// casper version

In D8753#258283, @emaste wrote:

From in-person working group session, a suggestion to rename libcasper.h to libcasper.h.in and run unifdef on it during install.

% cat example.h.in
// example header file
#ifdef WITH_CASPER
// casper version
#else
// non-casper version
#endif

% unifdef -UWITH_CASPER -o example.h example.h.in
% cat example.h                                  
// example header file
// non-casper version

% unifdef -DWITH_CASPER -o example.h example.h.in
% cat example.h                                  
// example header file
// casper version

This works for the general build but has a few problems:

• If a user changes from WITH_CASPER to WITHOUT_CASPER, the headers will not be rebuilt automatically. Doing so would require META_MODE to be enabled to rebuild when the command changes (-DWITHOUT_CASPER vs -DWITH_CASPER). Granted this problem sort of exists if we dont' use unifdef since all objects would need to be rebuilt if the command changes too.
• The build silently passes regardless of WITH_CASPER or WITHOUT_CASPER or any discrepancy between what is being built and what may already be built. There's probably no way to solve this.
• This is difficult to solve for the _rescue/_ build to disable casper in them since we need to generate new headers rather than just check in the headers for #if defined(RESCUE) || defined(WITHOUT_CASPER) at compile-time.

I know I'm rehashing an argument here but IMHO we don't gain much from all of this optional logic. Perhaps the reasoning for it needs to be explained here better. Why do we care about a MK_CASPER option? It does not look like a reasonable size argument from the sizes I'm seeing. The first implementation (https://reviews.freebsd.org/D8753?id=22822) of checking function cap_foo() { if (!cap_enable()) return (foo()); ... } seemed much more reasonable and easy to maintain. Perhaps the initial implementation could be improved with better feedback rather than dropping the approach entirely (the multi-lib issue was the biggest concern I saw and not the wrapper behavior). We can place any master override logic in cap_enable for people who don't want the complexity. If we really want these ifdefs I would rather just have something simple (not using unifdef) and just support #if defined(RESCUE) || defined(WITHOUT_CASPER) for the rare cases it is actually needed to be trimmed out and not bother with a default -DWITH_CASPER in the global CFLAGS...