# 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:

```
.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?
> 
> 
> 
> ...


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

```
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`

```
# 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.


----------

