svn commit: r334320 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys i386/include

[Warner Losh]

On Tue, May 29, 2018 at 8:16 AM, Hans Petter Selasky <hps at selasky.org>
wrote:

> On 05/29/18 16:00, Ed Maste wrote:
>
>> On IRC the suggestion was made to run buildworld for any header
>> change, and I think this seems like a reasonable standard.
>>
>> Our full buildworld times are admittedly quite long, so if you have a
>> suitably up-to-date toolchain on the build host you can skip building
>> toolchain components with something like:
>>
>> make -DWITHOUT_TOOLCHAIN -DWITHOUT_CLANG_BOOTSTRAP
>> -DWITHOUT_LLD_BOOTSTRAP buildworld
>>
>
> Hi,
>
> Thanks for the tip w.r.t. getting clang out of the buildworld.
>
> Maybe this can be written down on some Wikipage . freebsd . org ?
>
> The title could be "Who are my dependencies when changing code?", and it
> should answer the following questions like some kind of flow graph:
>
> - Shortcuts for kernel builds.
>

-DNO_CLEAN is the safest. KERNFAST=config will skip some steps when doing
iterative development (like config and depend), so it's more dangerous, but
often suffices.


> - Shortcuts for user-space builds.
>

For non-major stuff, I do a -DNO_CLEAN build as a sanity check. I hesitate
to enshrine too many shortcuts here because we want the buildworld path
well tested because that's the path users take. Anything beyond -DNO_CLEAN
likely is too risky.


> - Shortcuts for ports interactions.
>

There are no shortcuts here. Only driving fast and taking chances.


> - When do I only need to build a kernel module.
>

When you only changed .c or .s files that are used by the module. Even
then, there are some build failure that can happen in the kernel and not
the module and vice-versa.


> - When do I only need to build a single utility.
>

Only changed .c files and those .c files aren't used elsewhere in the tree.


> - When do I do a full kernel build.
>

Changing config and/or any .h file.


> - When do I do a full user-space build.
>

Changing any .h file, or altering anything in a library.


> - When do I do a universe build.
>

Any change to any printf :). Any time you change the MI/MD interface in the
kernel. Any time you have code that might be architecturally different
(this is hard to know)


> - When do I ask ports guys for help.


Anytime you change the userland API :).

The advice in the developer's handbook has grown stale. We should update
that. But machines are fast these days, and too many short-cuts has
historically caused problems. There's rarely a need to rush things in so
fast you can't build the system. I amortize the build times over several
changes at once using git svn to curate / manage the changes until they are
good. Also, you really should be running the changes you make. Ideally,
you'd test boot the whole system, but that's overkill if you fixed a
smelling error in ls.

Warner