Date: Thu, 7 Dec 2017 09:59:30 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Bryan Drewery <bdrewery@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org 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/... Message-ID: <b55b8002-e326-8327-0827-801bbea749b7@selasky.org> In-Reply-To: <20f66fc2-5812-1c0d-ceed-1171d918568d@FreeBSD.org> References: <201711241450.vAOEoSFW056744@repo.freebsd.org> <ea6c8eb5-f849-df2a-ab80-75d8ebc1edb8@FreeBSD.org> <0fec20d5-cb8f-4937-5dd0-54b8b7461772@selasky.org> <cec48299-e075-fe51-1297-4eb10a4f7619@FreeBSD.org> <19abac3b-8407-abd8-4fe9-c23d6bd7121f@selasky.org> <20f66fc2-5812-1c0d-ceed-1171d918568d@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b55b8002-e326-8327-0827-801bbea749b7>