Re: rdma-core build environment enabling out-of-core providers

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html