make silent ;)

Leander · Apr 30, 2014

Hi

I try to get my make(1) a little more silent. The aim is to let make(1) work and suppress warnings. With gcc(1) there is the option -w in order to achieve this. Is there something equivalent for make(1)?

env BATCH=YES make install clean > /dev/null

Error messages should be displayed though.

Thanks.

fonz · Apr 30, 2014

Suppressing warnings is the compiler's job, not Make's. Make itself doesn't produce a whole lot of warnings.

Leander · Apr 30, 2014

All right, and how do I hand this over to the compiler if I e.g. compile a port like:

cd /usr/ports/archivers/zip
env BATCH=YES make install clean > /dev/null
cd ~

Isn't there something global - or could I e.g. set a environment variable?

Thanks.

fonz · Apr 30, 2014

Leander said:
Isn't there something global - or could I e.g. set a environment variable?

Set CFLAGS to contain the -w option?

In fact, if you wish to do this for all ports, you can put the following in(to) /etc/make.conf:

Code:

.if ${.CURDIR:M/usr/ports*}
CFLAGS+=-w
.endif

Leander · Apr 30, 2014

Awsome - thanks a lot! Unfortunately I wasn't able to combine it with the BATCH=yes
env BATCH=YES CFLAGS+=-w make install clean > /dev/null
What am I missing out here?

fonz · Apr 30, 2014

Leander said:
What am I missing out here?

The += syntax works with make, but I doubt it works with env. You might be setting a variable called CFLAGS+

Try doing env BATCH=YES CFLAGS=-w make bla bla bla and see if CFLAGS doesn't get overwritten by the port Makefile.

Leander · Apr 30, 2014

Nice this worked out. Again, thanks a lot

Leander · Apr 30, 2014

Although this is not entirely solved. When I install www/varnish then I still get all the warnings. Is there another switch I'm still missing?

fonz · May 1, 2014

Leander said:
Although this is not entirely solved. When I install www/varnish then I still get all the warnings. Is there another switch I'm still missing?

Are you getting compiler warnings? If I try a make stage most of the warnings I get are from automake and libtool. The latter has a flag --no-warn and some digging(*) in /usr/ports/Mk/ reveals there is a variable LIBTOOLFLAGS you can use. For Automake there's apparently AUTOMAKE_ARGS but I don't have the Automake man page here, so I wouldn't know which option suppresses warnings, if there is one.

Ad (*): I'll probably get some stick for this, but I often find find /usr/ports/Mk -exec grep -H Yabbadabbadoo {} \; (or some variant thereof) helpful when trying to find out some of the more intimate details of the ports system.

Leander · May 1, 2014

I found this website: http://www.gnu.org/software/automake/manual/automake.html where they write about --warnings=category. I also found another website http://www.manpagez.com/man/1/libtool/ where they mention --no-warn. So I assume my command should now look like this:
env BATCH=YES CFLAGS=-w AUTOMAKE_ARGS='--warnings=none' LIBTOOLFLAGS=--no-warn make install clean > /dev/null
But the warnings still keep popping like before - so it looks to me like I didn't set the variables correctly?!

BTW. is there a difference?

fonz said:
find /usr/ports/Mk -exec grep -H Yabbadabbadoo {} \;

grep -r "Yabbadabbadoo" /usr/ports/Mk

fonz · May 1, 2014

Leander said:
env BATCH=YES CFLAGS=-w AUTOMAKE_ARGS=--warnings[b]=[/b]none LIBTOOLFLAGS=--no-warn make install clean > /dev/null
But the warnings still keep popping like before - so it looks to me like I didn't set the variables correctly?!

As it turns out, both LIBTOOLFLAGS and AUTOMAKE_ARGS are being set (=) rather than expanded upon (+=) in that port's Makefile, so your values are overridden. You could edit the Makefile, but the next time you do portsnap fetch update the changes will be lost again, so that's not exactly a permanent fix.

Moreover: I noticed that www/varnish also produces Autoconf and aclocal warnings, that's two more holes to plug if you really want this port to STFU.

Leander · May 1, 2014

Well I would love to make the entire ports installation to STFU

Yes, manipulating each port would be beyond efficiency, plus definitely not a healthy way.

This would also do what I want - on a global matter - but it also kills the error messages (not good): env BATCH=YES make install clean > /dev/null 2>&1. Is there maybe another trick with diverts like > /dev/null 2>&1 in order to filter for errors only?

fonz · May 1, 2014

Leander said:
BTW. is there a difference?

fonz said:

find /usr/ports/Mk -exec grep -H Yabbadabbadoo {} \;

Click to expand...

grep -r "Yabbadabbadoo" /usr/ports/Mk

Not in this case. But the advantage of the find method is that you can add options such as -name, -type, etc. so grep will only be invoked on files meeting certain criteria.

For example, consider the task of obtaining a list of all ports that have not been stagified yet. That means finding all ports of which the Makefile contains a line

Code:

NO_STAGE=   yes

You can probably imagine that find /usr/ports -name Makefile -exec grep -H NO_STAGE=\.\*yes {} \; is considerably faster than grep -Hr NO_STAGE=\.\*yes /usr/ports because the former only invokes grep on Makefiles whereas the latter greps life, the universe and everything.

Edit: and no, grep -H NO_STAGE=\.\*yes /usr/ports/*/*/Makefile won't work, because the list of arguments will get too long to handle.

Leander · May 1, 2014

fonz said:
You can probably imagine that find /usr/ports -name Makefile -exec grep -H NO_STAGE=\.\*yes {} \; is considerably faster than grep -Hr NO_STAGE=\.\*yes /usr/ports because the former only invokes grep on Makefiles whereas the latter greps life, the universe and everything.

I definitely agree. I just use grep(1) in cases where I'm too lazy to type the entire find(1) command and its fine tuned conditions. For the sake of performance, I definitely also use find(1) in my scripts, since I want to leave life, the universe and everything else where it belongs.

Anyways - back to the topic

Do you have any idea how to twist this with regular diverts like e.g.: "> /dev/null 2>&1"?

fonz · May 1, 2014

Leander said:
Do you have any idea how to twist this with regular diverts like e.g.: "> /dev/null 2>&1"?

I'm afraid I don't think that's going to fly

As far as I can think of, there really is no reliably uniform way to distinguish errors, warnings or actually any kind of output once it has been emitted.

Filtering stdout and passing the -W flag to the compiler should silence a well-behaved port, but short of redirecting everything to /dev/null, which as you said would be throwing the baby (errors) out with the bathwater (warnings and other noise), I think there's only so much one can do.

Leander · May 1, 2014

All right then - anyway - thanks a lot for your time and help!

Leander · May 3, 2014

It turns out it breaks some ports, or at least seems to overwrite some individual CHFLAGS. I experienced the following errors while compiling PHP-Extensions and NUT from ports - both with SNMP support enabled in make.conf as well as CFLAGS=-w via environment.

env BATCH=YES CFLAGS=-w make install clean > /dev/null

Code:

# NUT
./.libs/libnetsnmpagent.so: undefined reference to `netsnmp_subtree_change_prev'
./.libs/libnetsnmpagent.so: undefined reference to `netsnmp_table_dataset_delete_data'
./.libs/libnetsnmpagent.so: undefined reference to `netsnmp_subtree_change_next'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

# PHP
net-snmp-5.7.2.tar.gz                         100% of 6134 kB 1674 kBps 00m03s
./.libs/libnetsnmpagent.so: undefined reference to `netsnmp_subtree_change_prev'
./.libs/libnetsnmpagent.so: undefined reference to `netsnmp_table_dataset_delete_data'
./.libs/libnetsnmpagent.so: undefined reference to `netsnmp_subtree_change_next'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Compilation for lang/php55-extensions failed

After some investigation it turns out, there was once someone who experienced kind of the same error I got - see here: http://www.freebsd.org/cgi/query-pr.cgi?pr=176678

Fix: makefile should be changed, so CONFIGURE_ENV would look like this
CONFIGURE_ENV+= PERLPROG="${PERL}" PSPROG="${PS_CMD}" SED="${SED}"
CFLAGS="-DNETSNMP_BROKEN_INLINE"

So according to my understanding it looks like CFLAGS is potentially being overwritten here?!

fonz · May 3, 2014

Leander said:
So according to my understanding it looks like CFLAGS is potentially being overwritten here?!

It looks like that, yes. And it's usually wrong. A port's Makefile is only supposed to modify (typically by appending to) CFLAGS and NOT to clobber what was already in there from /etc/make.conf unless there's a very good reason to do so. Exactly which port is it that does that?

Come to think of it, www/varnish probably shouldn't be clobbering LIBTOOLFLAGS and AUTOMAKE_ARGS either. Some PRs might be in order.