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.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
