Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Jun 2016 13:04:07 -0700
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        Andrey Chernov <ache@freebsd.org>, current@freebsd.org
Subject:   Re: 'make depend' or 'make' bug on recent --current
Message-ID:  <eac49ec8-4909-cbbf-6413-cd371b365e3e@FreeBSD.org>
In-Reply-To: <b5e60be6-f491-9518-a7a9-e1fce34f3590@freebsd.org>
References:  <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org> <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org> <bec48601-f6b4-6b8a-dc0d-fad47416723b@freebsd.org> <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org> <b5e60be6-f491-9518-a7a9-e1fce34f3590@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--uI4colgDmiHCGoBqnq4vHn7Fgjc1TNnnU
Content-Type: multipart/mixed; boundary="mWjNBtQCvHWjeJue6uD70R4rLuha3som4"
From: Bryan Drewery <bdrewery@FreeBSD.org>
To: Andrey Chernov <ache@freebsd.org>, current@freebsd.org
Message-ID: <eac49ec8-4909-cbbf-6413-cd371b365e3e@FreeBSD.org>
Subject: Re: 'make depend' or 'make' bug on recent --current
References: <092f5e98-dae8-dbc9-2a6e-7068b972278f@freebsd.org>
 <311f3a82-b702-d375-170f-82ae39236ab0@FreeBSD.org>
 <bec48601-f6b4-6b8a-dc0d-fad47416723b@freebsd.org>
 <7f325ac2-f722-c491-fca0-2e582773e780@FreeBSD.org>
 <b5e60be6-f491-9518-a7a9-e1fce34f3590@freebsd.org>
In-Reply-To: <b5e60be6-f491-9518-a7a9-e1fce34f3590@freebsd.org>

--mWjNBtQCvHWjeJue6uD70R4rLuha3som4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/1/16 12:58 PM, Andrey Chernov wrote:
> On 01.06.2016 22:36, Bryan Drewery wrote:
>>>> The graph in the original commit for WITH_FAST_DEPEND disagrees.
>>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290433
>>>>
>>>> We run the preprocessor once now, not twice.
>>>
>>> It sounds good, just implemented bad. You measure some spherical chic=
ken
>>> in vacuum, not what really happens. In the old times I almost never h=
ave
>>> clang libs rebuild (few files from there max when FreeBSD_version is
>>> increased), but now I got them fully rebuilt with any header change.
>>> That is the biggest slowdown and not what you try to measure.
>>> Don't ever use 'make world'. Try to rebuild the system incrementally =
and
>>> you'll see.
>>
>> I cannot argue with a lack of solid evidence.
>>
>> The old 'make depend' ran 'mkdep' which ran 'cc -E -M' which produces
>> *the same output* as 'cc foo.c -o foo.o -MD -MF .depend.foo.o -MT
>> foo.o'.  There's nothing different in the actual .depend file
>> implementation/content.  Clang rebuilds often because it is changing
>> often!  Just look at recent commit logs and you'll see r300984 which
>> will cause a rebuild of clang.  Or r301011 which modified
>> sys/sys/param.h which will rebuild just about everything.  These are
>> normal and how the old system worked as well.
>>
>> There certainly are some issues with the new system.
>> 1. Processing the split files can be slow over NFS
>> 2. make cleandepend - will cause the next build to make a lot of guess=
es
>> and not be very efficient.
>> 3. make cleandepend - There is no way to generate the .depend* files
>> again without rebuilding.
>> 4. It doesn't fix all of the missing dependencies that have been missi=
ng
>> forever such as crt, csu, libgcc, etc for static builds.
>> 5. the csu builds don't use it yet but have workarounds for it
>> 6. removing the 'make depend' tree-walk can hurt downstream builds whi=
ch
>> relied on having a multi-phase build to generate a .mk file to include=

>> (odd case I hit at work).  No such case exists in the upstream FreeBSD=
 tree.
>>
>=20
> There are two different things: pure recursive dependency (it is how
> make depends works now) and just nested include graph with dependencies=

> marked directly by Makefile's rules (it is how old system works). Now i=
t
> is enough to touch some low level include to rebuild everything, before=

> only files which include it directly or have make rules for it are rebu=
ilt.

No.  The build and how dependencies are generated and handled is still
fundamentally the same.  Open the .depend.* files and see.  It is only
simple dependencies for the target built.  There's nothing new about its
content.  If foo.c includes stdlib.h then it includes sys/_types.h which
includes sys/cdefs.h, etc.  This graph is in the old (mkdep) and new
=2Edepend* content.  This is easily provable by just comparing mkdep
output to the new versions.

Without specific evidence of a bug I cannot help.


--=20
Regards,
Bryan Drewery


--mWjNBtQCvHWjeJue6uD70R4rLuha3som4--

--uI4colgDmiHCGoBqnq4vHn7Fgjc1TNnnU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXTz+3AAoJEDXXcbtuRpfPt54H/j9GOy+5pBiutKaKev5NXCbB
B3CrdcMbHJk8PxiJyv2mVUcGDkCoxUqVpuEvX7rttuS4JfeQhQznlT8aWIMSf+Sc
Dqo/F209yJnLsDQe6urzoQUfp1MvXXbUnoNXQgKUlCStehUnP+v8FFsn8akoVp3H
csqNhXYMAT0v5PHeioaxE/7Co285cQfUCZE3ZUWbotc+f4uK8RyRXh8FMyzjQg6s
vg25jZYkCkxrgVUsLwXQBUOT5iSAxQk8HTxqiC+yJloCIBaox5DEkq2+ofxLPOmT
SiXLwcUdfQ1IQQhDBiet+2KLM9og58CODc1rtHPGydy8m3Io9V51JMuu1aEJgf0=
=0D3b
-----END PGP SIGNATURE-----

--uI4colgDmiHCGoBqnq4vHn7Fgjc1TNnnU--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eac49ec8-4909-cbbf-6413-cd371b365e3e>