Skip site navigation (1)Skip section navigation (2)
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>