Build -j target tags and command output

Discussion:

Bryan Drewery

2016-02-26 22:10:48 UTC

--- all_subdir_lib/clang/libclangstaticanalyzercheckers ---
--- CastToStructChecker.o ---
--- all_subdir_lib/libmagic ---
--- readcdf.o ---
--- all_subdir_lib/clang ---
/usr/local/bin/ccache c++ -O2 -pipe -fcolor-diagnostics -I/root/git/freebsd/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include -I/root/git/freebsd/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include -I/root/git/freebsd/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyz
er/Checkers -I. -I/root/git/freebsd/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-
unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -MD -MP -MF.depend.CastToStructChecker.o -MTCastToStructChecker.o -fstack-protector-strong -Qunused-arguments -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /root/git/freebsd/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/CastToStru
ctChecker.cpp -o CastToStructChecker.o

I'm looking for opinions on whether we should keep or remove the --
lines. Recent changes to make SUBDIR_PARALLEL more wide-spread has made
these much more noticeable and spammy. There are cases where they are
recursive, if something N levels deep in a SUBDIR_PARALLEL N-make-level
build prints something, every parent make prints the target for that
subdir. I've tried to mitigate that some but it's a lost cause. bmake
purposely prints targets if they have no output so that you know it did
try to build the target. That really hurts with bsd.subdir.mk
traversals though. There's also a rare case where the --- lines get
interspersed or printed on the command line and really mess things up.

Removing them would yield potentially hard-to-debug failures since the
failed command could be anywhere. At least the 'make stopped' error
that follows would print the directory. There is an interesting feature
in the meta mode build that will keep a log and print a more detailed
error message on failures so you really know which directory failed and
what environment it had, but it can be spammy as well since it prints
the same error information on the 'another make hit an error, dying' cases.

Longterm, I think a merge between DIRDEPS_BUILD output and the NetBSD
build output makes sense and removes these --- lines entirely. It would
hide the command output but we could optionally show it with a VERBOSE
flag, or using meta mode (the very light version which only requires the
CMD ran in a .meta file) we could use the meta file to see what command
failed.

~/git/freebsd/bin/sh # NO_SUBDIR=yes make MAKEVERBOSE=1
compile sh/mknodes.o
compile sh/mksyntax.o
compile sh/alias.o
compile sh/arith_yacc.o
compile sh/arith_yylex.o
compile sh/cd.o
compile sh/echo.o
compile sh/error.o
compile sh/eval.o
compile sh/exec.o
compile sh/expand.o
compile sh/histedit.o
compile sh/input.o
compile sh/jobs.o
compile sh/kill.o
compile sh/mail.o
compile sh/main.o
compile sh/memalloc.o
compile sh/miscbltin.o
compile sh/mystring.o
compile sh/options.o
compile sh/output.o
compile sh/parser.o
compile sh/printf.o
compile sh/redir.o
compile sh/show.o
compile sh/test.o
compile sh/trap.o
compile sh/var.o
compile sh/builtins.o
compile sh/nodes.o
compile sh/syntax.o
link sh/sh.full
create sh/sh.debug
create sh/sh
~/git/freebsd # WITH_DIRDEPS_BUILD=yes make -C bin/sh -j15

...

--- /root/git/freebsd/bin/sh.amd64,amd64 1334 ---
@ 1456524548 [2016-02-26 14:09:08] Checking /root/git/freebsd/bin/sh for amd64,amd64 ...
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/.dirdep
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/builtins.c
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mknodes.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mksyntax.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/token.h
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_incs
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mksyntax
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mknodes
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/syntax.c
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/nodes.c
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/alias.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/arith_yacc.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/arith_yylex.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/cd.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/echo.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/error.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/eval.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/exec.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/expand.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/histedit.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/input.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/jobs.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/kill.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mail.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/main.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/memalloc.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/miscbltin.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mystring.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/options.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/output.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/parser.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/printf.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/redir.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/show.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/test.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/trap.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/var.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/builtins.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/nodes.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/syntax.o
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh.1.gz
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh.full
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh.debug
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_files.man1
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_as.prog
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_libs
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_symlinks.man1
Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_links.man1
Checking /root/git/freebsd/bin/sh/Makefile.depend: .dirdep.meta builtins.c.meta mknodes.o.meta mksyntax.o.meta token.h.meta stage_incs.meta mksyntax.meta mknodes.meta
@ 1456524550 [2016-02-26 14:09:10] Finished bin/sh.amd64,amd64 seconds=2 meta=49 created=49

--
Regards,
Bryan Drewery

Simon J. Gerraty

2016-02-26 23:20:08 UTC

Permalink

Post by Bryan Drewery
I'm looking for opinions on whether we should keep or remove the --

Keep.

Without them it is virtually impossible to identify which job produced
certain output.

Even with them, the log from a parallel hirerarchical build can get
confusing - especially when multiple makes are writing at the same time.
But you are still better off with some clues.

Post by Bryan Drewery
Removing them would yield potentially hard-to-debug failures since the

Yes, pls don't do that.

Post by Bryan Drewery
failed command could be anywhere. At least the 'make stopped' error
that follows would print the directory. There is an interesting feature

Yes, but generally the exciting stuff that caused the stoppage is
earlier in the log.
The --- lines allow use of scripts to demux the output.

Post by Bryan Drewery
in the meta mode build that will keep a log and print a more detailed
error message on failures so you really know which directory failed and
what environment it had, but it can be spammy as well since it prints
the same error information on the 'another make hit an error, dying' cases.

Yes, the issue is largely moot with dirdeps/meta mode build.
As your example clearly demonstrates.

Not all targets produce a .meta file, and for these you may still get
--- job lines, but they can hardly be considered an issue.

All the gory details - that you need to debug issues saved in
in the .meta file with no contamination from other jobs

Post by Bryan Drewery
Longterm, I think a merge between DIRDEPS_BUILD output and the NetBSD
build output makes sense and removes these --- lines entirely. It would

With dirdeps build the noise that NetBSD outputs is just noise:

Checking /tank/home/sjg/work/NetBSD/current/src/lib/csu for i386 ...
Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/gcrt0.o
Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/sysident_assym.h
Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/crtn.o
--- gcrt0.o ---
# compile csu/gcrt0.o
--- sysident_assym.h ---
# create csu/sysident_assym.h
--- crtn.o ---
# compile csu/crtn.o

Post by Bryan Drewery

~/git/freebsd # WITH_DIRDEPS_BUILD=yes make -C bin/sh -j15

...

Bryan Drewery

2016-02-26 23:30:31 UTC

Permalink

Post by Simon J. Gerraty

Post by Bryan Drewery
I'm looking for opinions on whether we should keep or remove the --

Keep.
Without them it is virtually impossible to identify which job produced
certain output.
Even with them, the log from a parallel hirerarchical build can get
confusing - especially when multiple makes are writing at the same time.
But you are still better off with some clues.

Post by Bryan Drewery
Removing them would yield potentially hard-to-debug failures since the

Yes, pls don't do that.

Post by Bryan Drewery
failed command could be anywhere. At least the 'make stopped' error
that follows would print the directory. There is an interesting feature

Yes, but generally the exciting stuff that caused the stoppage is
earlier in the log.
The --- lines allow use of scripts to demux the output.

Yes, the issue is largely moot with dirdeps/meta mode build.
As your example clearly demonstrates.

Yes, though I would still suggest disabling .MAKE.MODE.PREFIX in that
mode since it is not needed when a meta file is created due to the full
path to object. Though we would need to resolve the non-meta targets
not printing the 'Building' line somehow.

Perhaps a way to make .MAKE.JOB.PREFIX fully changeable (not forcing the
--- on the end) and supporting ${.TARGET} like .MAKE.META.PREFIX and
then only showing it when not creating a meta file when in meta mode.
But *still* show the command output since there is no .meta file to
track the command for debugging. The point is we could get

Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/clean
rm -f *.o

vs

--- all_subdir ---
--- all_subdir_bin ---
--- all_subdir_bin/sh_clean ---
--- clean ---
rm -f *.o

Of course the recursive printing by sub-makes would have to be disabled
somehow in this mode.

Backing up to simpler changes now though...

I thought I asked you this before but I couldn't find the mail. Just
having a '.JOBSILENT' on a target would be nice to hide subdir printing
but not hide the command output (requiring .SILENT on clean: obj:, etc),
and then also allowing ${.TARGET} to work in .MAKE.JOB.PREFIX so that we
can get something like the following, where the job is only the final
one and not any of the subdir ones.

--- /usr/obj/root/git/freebsd/amd64.amd64/bin/sh (clean) ---
rm -f *.o

Post by Simon J. Gerraty
Not all targets produce a .meta file, and for these you may still get
--- job lines, but they can hardly be considered an issue.
All the gory details - that you need to debug issues saved in
in the .meta file with no contamination from other jobs

Post by Bryan Drewery
Longterm, I think a merge between DIRDEPS_BUILD output and the NetBSD
build output makes sense and removes these --- lines entirely. It would

Checking /tank/home/sjg/work/NetBSD/current/src/lib/csu for i386 ...
Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/gcrt0.o
Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/sysident_assym.h
Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/crtn.o
--- gcrt0.o ---
# compile csu/gcrt0.o
--- sysident_assym.h ---
# create csu/sysident_assym.h
--- crtn.o ---
# compile csu/crtn.o

Well I didn't mean literally a merge, I meant more picking from both.
Granted, the NetBSD method is very hard to implement fully and won't
work for custom build targets and downstream build changes since it
requires adding an echo into every target.

Post by Simon J. Gerraty

Post by Bryan Drewery

~/git/freebsd # WITH_DIRDEPS_BUILD=yes make -C bin/sh -j15

...

--
Regards,
Bryan Drewery

Simon J. Gerraty

2016-02-26 23:47:06 UTC

Permalink

Post by Bryan Drewery
Yes, though I would still suggest disabling .MAKE.MODE.PREFIX in that
mode since it is not needed when a meta file is created due to the full
path to object. Though we would need to resolve the non-meta targets
not printing the 'Building' line somehow.
Perhaps a way to make .MAKE.JOB.PREFIX fully changeable (not forcing the
--- on the end) and supporting ${.TARGET} like .MAKE.META.PREFIX and
then only showing it when not creating a meta file when in meta mode.

That already happens when .MAKE.MODE includes "meta" and "silent=yes"

Frankly I would prefer to *not* make the non-meta targets look exactly
like meta targets in the log - since then people will waste time looking
for and filing bug reports about missing .meta files.

The difference does not need to be significant - just distinguishable.

Post by Bryan Drewery
I thought I asked you this before but I couldn't find the mail. Just
having a '.JOBSILENT' on a target would be nice to hide subdir printing
but not hide the command output (requiring .SILENT on clean: obj:, etc),
and then also allowing ${.TARGET} to work in .MAKE.JOB.PREFIX so that we
can get something like the following, where the job is only the final
one and not any of the subdir ones.
--- /usr/obj/root/git/freebsd/amd64.amd64/bin/sh (clean) ---
rm -f *.o

My solution to that is to eliminate the recursion ;-)
But I'll give the above some thought.

Ian Lepore

2016-05-21 02:29:36 UTC

Permalink

Post by Simon J. Gerraty

Post by Bryan Drewery
I'm looking for opinions on whether we should keep or remove the --

Keep.
Without them it is virtually impossible to identify which job
produced
certain output.
Even with them, the log from a parallel hirerarchical build can get
confusing - especially when multiple makes are writing at the same time.
But you are still better off with some clues.

Post by Bryan Drewery
Removing them would yield potentially hard-to-debug failures since the

Yes, pls don't do that.

Post by Bryan Drewery
failed command could be anywhere. At least the 'make stopped' error
that follows would print the directory. There is an interesting feature

Yes, but generally the exciting stuff that caused the stoppage is
earlier in the log.
The --- lines allow use of scripts to demux the output.

Are any such scripts available?

-- Ian (catching up on really old mail)

Simon J. Gerraty

2016-05-21 18:52:55 UTC

Permalink

Post by Ian Lepore

Post by Simon J. Gerraty
Yes, but generally the exciting stuff that caused the stoppage is
earlier in the log.
The --- lines allow use of scripts to demux the output.

Are any such scripts available?

Not right now but I'm sure that can be fixed...
the one we used to use was 23 lines of perl not counting comments.