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

[Bryan Drewery]

On 12/6/2017 4:53 PM, Hans Petter Selasky wrote:
> 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!
> 

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.

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

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

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.


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20171206/de926c06/attachment.sig>