From owner-svn-src-head@freebsd.org Thu Dec 7 09:02:18 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DC43E80DA5; Thu, 7 Dec 2017 09:02:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0B367D5F9; Thu, 7 Dec 2017 09:02:17 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D060B2603A1; Thu, 7 Dec 2017 10:02:15 +0100 (CET) Subject: Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys/... To: Bryan Drewery , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201711241450.vAOEoSFW056744@repo.freebsd.org> <0fec20d5-cb8f-4937-5dd0-54b8b7461772@selasky.org> <19abac3b-8407-abd8-4fe9-c23d6bd7121f@selasky.org> <20f66fc2-5812-1c0d-ceed-1171d918568d@FreeBSD.org> From: Hans Petter Selasky Message-ID: Date: Thu, 7 Dec 2017 09:59:30 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20f66fc2-5812-1c0d-ceed-1171d918568d@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 09:02:18 -0000 On 12/07/17 02:02, Bryan Drewery wrote: > On 12/6/2017 4:53 PM, Hans Petter Selasky wrote: >> On 12/07/17 01:38, Bryan Drewery wrote: >> >> Try building the COMPAT 32-bit libraries with OFED and you'll see that >> this is needed! >> > > No. The proper fix is to add contrib/ofed/include to the > _LC_INCDIRS.${MK_OFED:tl} list in Makefile.libcompat. Just looking at > the lib32 build you can see 'includes' is only called on a subset of > directories via _LC_INCDIRS. The OFED includes were not there before. How does this make any difference over depending on the include directory like I currently do? I see Makefile.libcompat as yet another way to scatter the build details of OFED. I would like all the build details of OFED to stay in one place, contrib/ofed/xxx so that future generations will understand what needs to be updated. And then if any, Makefile.inc1 Makefile should pull / include from there. > >>> 6. Using these /0 /1 /2 /3 directories actually hurts the 'make >>> libraries' parallelism/dependency graph. It ends up building /1 rather >>> than building libibcm and libibumad directly in its graph.  It creates >>> an indirection which adds more unneeded submake recursion. Please understand that /0 /1 /2 /3 is a best effort compromise, versus parallelism and an ordered build, not having a bunch a manual and not at least undocumented steps. I see no problem if OFED should build a little bit slower due to this. There are plenty of libraries to build during buildworld and the compiler should be saturated all the time, and I don't see a real problem here. >> >> I think this is no argument over having to maintain and update >> Makefile.inc1 with all the dependencies every time there is a change or >> new driver library added to OFED. > > The argument is that it's how things are done. If you come up with a > brilliant solution to make Makefile.inc1 library dependencies simpler, > GREAT! But the one you have put in here is totally bogus. Why can't you use the existing DPADD='s in the Makefiles? The only problem I see is you need a tool to grok the location of the Makefiles for those libraries in order to build the dependency graph? >>> >>> It's fine, I'm going to rewrite it all now. Please add me as a reviewer. >> >> It would be nice if these utilities can be built standalone, outside the >> buildworld target aswell. I've suggested adding an "all-install" variant > > They mostly can, but building things directly with the current build > system simply won't create a SYSROOT or do cross-directory dependencies > properly. That's what DIRDEPS_BUILD does. Again, if you had invented > some great solution to make this simpler that would be good, but that's > not what you have here. You have simply made changes to simply build > ordering in contrib/ofed when not in buildworld, but that's not even > needed if you use the proper SUBDIR and SUBDIR_DEPEND. > >> to make. Having to kick a buildworld to test-build contrib/ofed is quite >> overkill, and that is some of reasoning behind the current Makefile layout. >> >> 6: When a set of libraries should be built in order, it is more clean to >> have 4 dependencies, than a bunch of them in my opinion. > > Creating rats nest dependency lists is not proper or easier to maintain > or cleaner at all. It's wrong. > >> >> You can use the updated "tools/make_libdeps.sh" to figure this out. >> >> The old approach with >> _prebuild_libs+= >> >> won't work :-( >> > > I told you before how to make it work. > >