On 8/29/2016 2:29 AM, Leon Romanovsky wrote: > On Sun, Aug 28, 2016 at 12:36:27PM -0600, Jason Gunthorpe wrote: > I'm doing that by running number of one liners [1], it builds me > development setup in shared folder, so my base image is continuing > to be clean. > > It is not final version, I didn't upload it yet. > > Libraries: > @echo "Build libibverbs" > @cd $(LIBIBVERBS_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install > @echo "Build libmlx5" > @cd $(LIBMLX5_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install So, with the changes Jason is proposing, nothing in the above changes drastically except you can skip all of the "make install" commands between builds of things like libibverbs and libmlx5 and the libmlx5 build will still be built against the right code, all the time. This is an improvement in the process from what it is today. Regardless of distro issues. It's just an improvement period. >> Doug is also adressing a larger issue with packaging and getting >> everything to build correctly as the distro - he talked about it here: >> >> https://www.spinics.net/lists/linux-rdma/msg37855.html > > I read that thread and think that it is related to unoptimized build > process of one distro who for any reason decided do not use repo tool > [2] I'm pretty sure the repo tool didn't exist when Red Hat created their build process. > for managing complex build dependencies between different git trees, We do this on a regular basis. It actually isn't hard for almost anything besides the RDMA stack. > but used excel file and manual download of source tarballs. Just to be clear, *I* used a spreadsheet in tracking my work, that's not part of the standard workflow inside Red Hat. But when you have a deadline looming, and 30+ packages to build, and a complex web of interrelated dependencies, and an overloaded build system because everyone else is building packages too, it just helps to avoid mistakes and blown builds if you track your work accurately. As for source tarballs, this is because when rpm was invented (back in 1994 or so), that's all there was. That was the standard. An argument could be made that rpm should be updated to work with git repos. I've made that argument myself, and in some ways it has. But the gold standard is still source tarballs. Every project has them, they are easy to verify, and they are constant. According to Fedora's packagedb, Fedora now has upwards of 20,000 different source packages in total. Many of these use alternate SCMs, like mercurial, subversion, there might even be a few still on crusty old CVS. So tarballs are still the only universal you can get from every project. > We used such tool for our 100+ git trees project and it worked like a charm. > There is worth to invest time and revise internal process of releasing > RDMA stack in that specific distro and no need to invent new beast > (rdma-plumbers). Unfortunataely, what you speak of is not really realistic, both for the reasons I've cited and a whole litany of other reasons I didn't mention. But I don't think Jason jumped in to work on this because of the goal of making Red Hat's life easier in packaging up the separate code. He did it for upstream related reasons: 1) Put all of the providers and libibverbs in one place so that they can be kept in sync. This allows us to do the exact same thing we do with the kernel in user space. Namely, if someone makes an incompatible change in the libibverbs core, we can require that they fix up all providers in the same patch series. This works rather well for the kernel, and it would be good to bring that policy to user space too. 2) Put all of the kernel interacting libraries in one place. This makes it easier to perform the write->ioctl conversion we've been discussing as there would be only one larger package that needs to be updated for any given kernel ioctl update. 3) Bring librdmacm and libibverbs together so that the occasional incompatible update between the two is not an issue any more. 4) Create an easier to build/install package for developers to use. Those are the issues we should be discussing the relative merits of in order to determine whether this work should be adopted. > [1] https://github.com/rleon/dev-scripts/blob/master/Makefile#L89 > [2] https://source.android.com/source/developing.html > >> >> Jason -- Doug Ledford <dledford@xxxxxxxxxx> GPG Key ID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
