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

On Fri, Aug 26, 2016 at 11:17:52PM -0400, Doug Ledford wrote:

quoted

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'.

quoted

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