On Thu, Aug 03, 2017 at 08:48:50AM -0500, Steve Wise wrote: > > I 'm not sure I see the issue here (or at least nothing easily > > fixed). If the standard spec produces an extra > > rdma-core-provider-devel with those headers, it's just a matter of > > rebuilding the out-of-tree provider against the right > > distro/package. > > After thinking about this more, I agree: If rdma-core is built into > binary platform and distro-specific rpms, then these header files > are definitely available to export as a -devel rpm for that same > platform/distro. The issue is where do you put headers like stdatomic.h, config.h, etc. These headers will collide with normal headers in various cases.. It is designed to be built with a private include/ that relies on #include_next to make everything work out, you cannot just dump the headers in /usr/include. If instead you do something like /usr/share/rdma-core/include then you still have the problem of conflicting with common user header names like config.h, and the problem of being matched exactly to the compiler that cmake was using when it made the headers. Overall it is a very fragile approach.. There are also minor issues like actually building and linking the provider correctly, there were many issues there pre-rdma-core, building it outside the existing cmake framework means someone else has to actually understand how to do this properly :) Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
