Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo

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

On Fri, Aug 26, 2016 at 11:17:52PM -0400, Doug Ledford wrote:
> > rpmbuild does stuff that needs to be checked out and validated by
> > upstream at least occasionally, or packaging becomes too hard for the
> > downstream because of broken build infra.
> 
> Given that rpmbuild is basically nothing more than a scripted build
> session, as long as the make/cmake system works well, so will
> rpmbuild.

Well, the thing that cases pain is the %configure and %cmake macros
that rpmbuild provides, and sorting out all the various distro-specific
install paths.

eg I ran into this bug with %cmake while testing 
(see https://bugzilla.redhat.com/show_bug.cgi?id=1301720)
and had to deal with it in both the spec file and the build scripts.

> The main things that cause problems for distros when upstream does it
> are things like using rpath to search alternate library locations.
> It

rpath is sorted automatically. %cmake takes care of it.

Be aware that rpath will still be set in the build output, just
stripped during 'make install'.

> > We've never been able to run the rdma stack from the build trees,
> 
> It's possible...you just have to do every step in the right order ;-)  I
> had a spreadsheet that I tracked packages, versions, build states,
> install states, and dependencies.  Made things a lot easier.

Yes, I've done that too, but the hardwired load path for the .driver
files is still a difficult problem.

I have an approach in mind to fix this too.

> shouldn't be mandatory.  However, in order to make it very explicit
> since I suspect most people want RoCE support and might not realize they
> are missing a build requirement for it to work, the tests in the
> configure script could be changed to add a new feature "RoCE Support
> (default: yes)" and make the libnl3/libnl test be part of the RoCE
> support, and if it isn't present, fail.  Then people have to turn off
> RoCE to build it without libnl3/libnl.  That would be more effective of
> a configure setup I think.

Yes, I agree. This is straightforward to do as well, I'll look at it.

Also, do you know why we have the libnl1 fallback support? I couldn't
figure out what distro needed that.

BTW, I've basically de-supported any distro that doesn't have O_CLOEXEC
and related, which probably includes anything that needed libnl1. We
can probably remove libnl1 someday too.

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