svn commit: r289384 - head/lib
Bryan Drewery
bdrewery at FreeBSD.org
Thu Oct 15 22:41:03 UTC 2015
On 10/15/2015 2:18 PM, Bryan Drewery wrote:
> On 10/15/2015 2:00 PM, Ian Lepore wrote:
>> On Thu, 2015-10-15 at 13:54 -0700, Bryan Drewery wrote:
>>> On 10/15/2015 1:27 PM, Bryan Drewery wrote:
>>>> Author: bdrewery
>>>> Date: Thu Oct 15 20:27:15 2015
>>>> New Revision: 289384
>>>> URL: https://svnweb.freebsd.org/changeset/base/289384
>>>>
>>>> Log:
>>>> Let the SUBDIR_DEPEND*c++ variables actually work rather than
>>>> being parsed
>>>> as a +=. These were safe due to a .WAIT very early on.
>>>>
>>>
>>> My analysis was wrong. The libc++ dependency on libcxxrt was actually
>>> broken here and would not have built if you went directly into lib
>>> and
>>> built in parallel. It was hidden by the fact that a proper dependency
>>> is
>>> in Makefile.inc1 via an __L target. The power of redundancy!
>>>
>>> This too allows kerberos5/lib to work with SUBDIR_PARALLEL= since
>>> it's
>>> so greatly defined in Makefile.inc1.
>>>
>>>
>>
>> But don't both sets of dependencies have to be correct? As I vaguely
>> recall, the ones in Makefile.inc1 are used during bootstrapping and
>> tool building, and the ones in lib/Makefile are used when world
>> -building. It may be that when MACHINE_ARCH == TARGET_ARCH some of
>> them are the same libraries and the Makefile.inc1 dependencies take
>> care of everything.
>
> It's complicated, my words may seem to contradict but it's just the
> nature of the convoluted process that we bootstrap the build by.
>
> Libraries, and anything else we list in the bootstrap phases, are
> special. Their SUBDIR_depend are less needed in the context of
> buildworld since they will already be built by the time the 'make
> libraries' builds all of lib/ with a subdir build or the 'make all' is
> ran on the tree, because of the __L dependencies. The special bootstrap
> phase stuff and special libraries need to have all of the proper __L
> targets to order them as they are built directly, not via bsd.subdir.mk
> recursing. One of the last steps of 'make libraries' does do a subdir
> build in lib/ since _generic_libs contains 'lib'. So yes the
> SUBDIR_depend are relevant for buildworld, but getting it wrong can be
> fine in cases where the library was built early with proper __L deps listed.
>
> The SUBDIR_depend are needed for manual direct subdir builds outside of
> buildworld and the builds 'make libraries' and 'make all' phases which
> use subdir builds to build things lacking a __L list.
>
> I've noticed that when people add new libraries into the early phases
> they usually follow-up with multiple commits trying to get it all right
> and update all of the proper places.
>
> Note that we actually have a 3rd dependency list in the tree now which
> is in the scattered Makefile.depend files. These are used for "meta
> mode" which I do think is more on the right track as it lets a clean
> build start from any directory. It doesn't use the SUBDIR_depend or the
> __L lists at all. The problem with it is the auto-generated nature of
> it can lead to problems with optional dependencies and adding new
> directories.
>
Here's an example of how weird buildworld is with libraries. This is
during the 'make all' phase.
0:00.32 make all DIRPRFX=usr.bin/svn/lib/libsvn_client/
0:09.27 make all DIRPRFX=lib/libc/
0:00.49 make all DIRPRFX=usr.sbin/wpa/wpa_supplicant/
0:00.05 make all DIRPRFX=usr.bin/svn/
0:00.03 make all DIRPRFX=usr.bin/svn/lib/
0:00.12 make all DIRPRFX=usr.sbin/wpa/
0:14.68 make -f Makefile.inc1 DESTDIR=/usr/obj/root/svn/base/tmp par-all
0:06.35 make all DIRPRFX=lib/
0:12.63 make all DIRPRFX=usr.bin/
0:13.22 make all DIRPRFX=usr.sbin/
0:07.16 make -j15 buildworld
It's building lib/ a 2nd time while also building things depending on
libraries, so really at this point the SUBDIR_depend in lib/ and
elsewhere are not too important since they were already built by 'make
libraries' which had the __L targets.
We probably don't need to run 'make all' in the library directories a
2nd time, just 'install'.
Also interestingly they are building in parallel without actually using
the SUBDIR_PARALLEL mechanism as it was made to be parallel in a similar
way in r30113. This is likely redundant now as well.
I'll look into those more.
--
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-all/attachments/20151015/9f5cfee7/attachment.bin>
More information about the svn-src-all
mailing list