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

[Hans Petter Selasky]

On 12/07/17 01:38, Bryan Drewery wrote:
> 1. SUBDIR=../../somewhere else is inherently wrong.
> 2. Building a library from a directory named '2' is wrong.
> 3. Not just using proper SUBDIR_DEPEND and making all these subdirs is
> not needed and complicates things MORE by splitting them all up.
> 4. Building a library from a directory where its real bsd.lib.mk is not
> at is wrong.
> 5. Depending on an include directory in the Makefile.inc1 library
> dependencies is simply not needed - I told you that.

Try building the COMPAT 32-bit libraries with OFED and you'll see that 
this is needed!

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

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 whole thing needlessly obfuscates these libraries.
> 
> It's fine, I'm going to rewrite it all now.

It would be nice if these utilities can be built standalone, outside the 
buildworld target aswell. I've suggested adding an "all-install" variant 
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.

You can use the updated "tools/make_libdeps.sh" to figure this out.

The old approach with
_prebuild_libs+=

won't work :-(

--HPS