bsd.lib.mk @'s
Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Mon, 7 Jun 1999, Chuck Robey wrote: Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. How often do your calls to ld, mv and rm fail? David To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Mon, 7 Jun 1999, David Scheidt wrote: On Mon, 7 Jun 1999, Chuck Robey wrote: Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. How often do your calls to ld, mv and rm fail? That's not the point, the point is that current is a bleeding edge thing, not production, and the details should not be hidden, there's no possible justification for that. Besides, calls to ld *do* fail, in the build, except the way it is now, it's harder to figure out. David +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. How often do your calls to ld, mv and rm fail? That's not the point, the point is that current is a bleeding edge thing, not production, and the details should not be hidden, there's no possible justification for that. Sure there is, in the same manner that we don't use 'cc -v' as the command line parameters to see *all* the excruciating details of how a program is compiled. The '@' calls are not considered important details, and as such are hidden. If we include *EVERYTHING* then finding the actual problem is often much harder due to trying to wade through the noise. The '@' commands help to reduce the noise, giving us a better signal/noise ratio. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
David Scheidt once wrote: Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. How often do your calls to ld, mv and rm fail? As one who has also tripped over this in the past, I'll second Chuck's vote. A call to ld fails more often then that to mv, but I often found myself going through the bsd.*.mk and removing the ``@''. Mostly so that I can see the exact ld-line, but not only... I remember, in the past, when people were wondering about The Right Ways to link on FreeBSD they were refered to the bsd.lib.mk. If the bsd.lib.mk was exposing the actual link commands a little better, this reference would have been easier to follow. -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Mon, 7 Jun 1999, Nate Williams wrote: Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. How often do your calls to ld, mv and rm fail? That's not the point, the point is that current is a bleeding edge thing, not production, and the details should not be hidden, there's no possible justification for that. Sure there is, in the same manner that we don't use 'cc -v' as the command line parameters to see *all* the excruciating details of how a program is compiled. The '@' calls are not considered important details, and as such are hidden. If we include *EVERYTHING* then finding the actual problem is often much harder due to trying to wade through the noise. The '@' commands help to reduce the noise, giving us a better signal/noise ratio. On a buildworld, Nate? Who's worried about signal to noise there? I could understand if you were talking about boot issues, but this is the listing of a build that breaks on a regular basis. Why are you worried about keeping that listing clean? What possible use is that? Being clean comes into play when you're seeing the same damn thing, day in and day out. When it comes to troubleshooting, and that's the only reason to look at that listing, I want as much detail as I can get. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. How often do your calls to ld, mv and rm fail? That's not the point, the point is that current is a bleeding edge thing, not production, and the details should not be hidden, there's no possible justification for that. Sure there is, in the same manner that we don't use 'cc -v' as the command line parameters to see *all* the excruciating details of how a program is compiled. The '@' calls are not considered important details, and as such are hidden. If we include *EVERYTHING* then finding the actual problem is often much harder due to trying to wade through the noise. The '@' commands help to reduce the noise, giving us a better signal/noise ratio. On a buildworld, Nate? bsd.lib.mk is used in all 'builds', not just buildworld. When I do the following sets of commands: # cd /usr/src/lib/libc # make I also use bsd.lib.mk. I don't *care* about the '@' commands. Who's worried about signal to noise there? I am, if I'm the developer trying to debug a user's problem. Wading through 1-2M of logfiles to find a problem is much less likely than me wading through 100-200K of logfiles. Being clean comes into play when you're seeing the same damn thing, day in and day out. When it comes to troubleshooting, and that's the only reason to look at that listing, I want as much detail as I can get. It's only useful information if it can *HELP* you debug the problem, and I'll argue that 99/100 times, that information is rarely helpful. Engineering practice suggests optimizing your solution for the 'normal' case, not the boundary case. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Mon, 7 Jun 1999, Nate Williams wrote: Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. How often do your calls to ld, mv and rm fail? That's not the point, the point is that current is a bleeding edge thing, not production, and the details should not be hidden, there's no possible justification for that. Sure there is, in the same manner that we don't use 'cc -v' as the command line parameters to see *all* the excruciating details of how a program is compiled. The '@' calls are not considered important details, and as such are hidden. If we include *EVERYTHING* then finding the actual problem is often much harder due to trying to wade through the noise. The '@' commands help to reduce the noise, giving us a better signal/noise ratio. On a buildworld, Nate? bsd.lib.mk is used in all 'builds', not just buildworld. When I do the following sets of commands: # cd /usr/src/lib/libc # make I also use bsd.lib.mk. I don't *care* about the '@' commands. Who's worried about signal to noise there? I am, if I'm the developer trying to debug a user's problem. Wading through 1-2M of logfiles to find a problem is much less likely than me wading through 100-200K of logfiles. Wait a second. bsd.lib.mk is for our buildworld, right? If you're hijacking it for customers, that's fine, but it's for buildworld for FreeBSD, not for everyone's customers. If it's a customer's thing, then it doesn't change all the time, and you can very easily stick in all those @ signs, but not so for the guy doing a buildworld, who gets his stuff put back with every cvsup. When the buildworld breaks, the info is at the end of the listing nearly all of the time, so there isn't any searching time. You refer to logfiles, but I'm talking about bsd.lib.mk, and not your application that must be bending bsd.lib.mk to produce logfiles. This is for buildworld listings. When you get to the problem, you want to know why it broke. If you use this makefile for your customer's, fine, you can stick all the @ signs in you want, because your customer isn't always regenning new bsd.lib.mk's like we all are. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
Who's worried about signal to noise there? I am, if I'm the developer trying to debug a user's problem. Wading through 1-2M of logfiles to find a problem is much less likely than me wading through 100-200K of logfiles. Wait a second. bsd.lib.mk is for our buildworld, right? It's for building source files in the source tree. Buildworld is *ONE* time that we build sources, but certainly not the only time it's used. If you're hijacking it for customers, that's fine, but it's for buildworld for FreeBSD, not for everyone's customers. What *are* you talking about? 'buildworld' is a FreeBSD'izm, and bsd.lib.mk predates it. bsd.lib.mk is part of all of the *BSD's, so equating /usr/share/mk/*.mk as only needed for 'world' building is an incorrect assumption. I have no 'FreeBSD' customers, so any assumptions you want to make about me using FreeBSD as a platform other than as a personal development platform are incorrect. When you get to the problem, you want to know why it broke. And 99/100 (heck, I'd go 99.99/100) the problem will not require the output of the '@' commands, so adding their output to the logfile only serves to create un-necessary noise and potentially confuse the users. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Mon, 7 Jun 1999, Colin Jensen wrote:
Why not just define a macro like SILENT_RUN=@ and replace
all the @ with ${SILENT}? Then both sides of can get what they
want :-)
A compromise. I *love* compromises. How about this, Nate?
+---
Chuck Robey | Interests include any kind of voice or data
chu...@picnic.mat.net | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1 |
Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current.
(301) 220-2114 |
+---
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Mon, Jun 07, 1999 at 03:29:18PM -0400, Chuck Robey wrote: Wait a second. bsd.lib.mk is for our buildworld, right? If you're hijacking it for customers, that's fine, but it's for buildworld for I always thought it was for anyone to use. Just one of those things that makes developing for FreeBSD so nice... Many ports use bsd.lib.mk, too. Surely bsd.prog.mk as well. -- Matthew Hunt m...@astro.caltech.edu * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
Chuck Robey chu...@picnic.mat.net wrote:
On Mon, 7 Jun 1999, Colin Jensen wrote:
Why not just define a macro like SILENT_RUN=@ and replace
all the @ with ${SILENT}? Then both sides of can get what they
want :-)
A compromise. I *love* compromises. How about this, Nate?
I have an alternative compromise - add an option to make(1) so it
will ignore the `@' symbol. The following adds a `-@' option (the
option letter could be easily changed). I haven't updated make.1,
but will if the following is acceptable.
Index: compat.c
===
RCS file: /home/CVSROOT/./src/usr.bin/make/compat.c,v
retrieving revision 1.12
diff -u -r1.12 compat.c
--- compat.c1998/09/09 05:15:38 1.12
+++ compat.c1999/06/07 22:12:24
@@ -239,7 +239,8 @@
while ((*cmd == '@') || (*cmd == '-')) {
if (*cmd == '@') {
- silent = TRUE;
+ if (!notSilent)
+ silent = TRUE;
} else {
errCheck = FALSE;
}
Index: job.c
===
RCS file: /home/CVSROOT/./src/usr.bin/make/job.c,v
retrieving revision 1.12
diff -u -r1.12 job.c
--- job.c 1999/02/14 22:22:42 1.12
+++ job.c 1999/06/07 22:11:41
@@ -483,7 +483,7 @@
* JobPrintCommand --
* Put out another command for the given job. If the command starts
* with an @ or a - we process it specially. In the former case,
- * so long as the -s and -n flags weren't given to make, we stick
+ * so long as the -@, -s and -n flags weren't given to make, we stick
* a shell-specific echoOff command in the script. In the latter,
* we ignore errors for the entire job, unless the shell has error
* control.
@@ -561,7 +561,8 @@
*/
while (*cmd == '@' || *cmd == '-') {
if (*cmd == '@') {
- shutUp = TRUE;
+ if (!notSilent)
+ shutUp = TRUE;
} else {
errOff = TRUE;
}
Index: main.c
===
RCS file: /home/CVSROOT/./src/usr.bin/make/main.c,v
retrieving revision 1.30
diff -u -r1.30 main.c
--- main.c 1999/03/01 06:01:05 1.30
+++ main.c 1999/06/07 22:17:43
@@ -133,6 +133,7 @@
BooleanusePipes; /* !-P flag */
BooleanignoreErrors; /* -i flag */
BooleanbeSilent; /* -s flag */
+BooleannotSilent; /* -@ flag */
BooleanbeVerbose; /* -v flag */
BooleanoldVars;/* variable substitution style
*/
BooleancheckEnvFirst; /* -e flag */
@@ -172,12 +173,16 @@
optind = 1; /* since we're called more than once */
#ifdef REMOTE
-# define OPTFLAGS BD:I:L:PSV:d:ef:ij:km:nqrstv
+# define OPTFLAGS @BD:I:L:PSV:d:ef:ij:km:nqrstv
#else
-# define OPTFLAGS BD:I:PSV:d:ef:ij:km:nqrstv
+# define OPTFLAGS @BD:I:PSV:d:ef:ij:km:nqrstv
#endif
rearg: while((c = getopt(argc, argv, OPTFLAGS)) != -1) {
switch(c) {
+ case '@':
+ notSilent = TRUE;
+ Var_Append(MAKEFLAGS, -@, VAR_GLOBAL);
+ break;
case 'D':
Var_Set(optarg, 1, VAR_GLOBAL);
Var_Append(MAKEFLAGS, -D, VAR_GLOBAL);
@@ -1280,7 +1285,7 @@
usage()
{
(void)fprintf(stderr, %s\n%s\n%s\n,
-usage: make [-Beiknqrstv] [-D variable] [-d flags] [-f makefile],
+usage: make [...@beiknqrstv] [-D variable] [-d flags] [-f makefile],
[-I directory] [-j max_jobs] [-m directory] [-V variable],
[variable=value] [target ...]);
exit(2);
Index: make.h
===
RCS file: /home/CVSROOT/./src/usr.bin/make/make.h,v
retrieving revision 1.8
diff -u -r1.8 make.h
--- make.h 1998/11/14 16:15:04 1.8
+++ make.h 1999/06/07 22:12:25
@@ -294,6 +294,7 @@
extern Boolean compatMake; /* True if we are make compatible */
extern Boolean ignoreErrors; /* True if should ignore all errors */
extern Boolean beSilent; /* True if should print no commands */
+extern Boolean notSilent; /* True if should print `@' commands */
extern Boolean beVerbose; /* True if should print extra cruft */
extern Boolean noExecute; /* True if should execute nothing */
extern Boolean allPrecious; /* True if every target is precious */
Peter
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
Why are many of the build lines in bsd.lib.mk hidden with leading @'s, so that they don't display in the build? This is useless, it hides things that go wrong, and hardly belongs here, it seems to me. I like extreme verbosity too, but some don't :-) PMake is supposed to have a .SHELL: pseudo-target that allows one to specify how to make shell commands quiet. If one could figure out how to use that, it would be trivial to provide a knob for this. I couldn't make .SHELL work though; consult /usr/src/usr.bin/make/job.c if you're interested. I'd like to know how to disable quiet commands too... Cheers, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Tue, 8 Jun 1999, Peter Jeremy wrote:
Chuck Robey chu...@picnic.mat.net wrote:
On Mon, 7 Jun 1999, Colin Jensen wrote:
Why not just define a macro like SILENT_RUN=@ and replace
all the @ with ${SILENT}? Then both sides of can get what they
want :-)
A compromise. I *love* compromises. How about this, Nate?
I have an alternative compromise - add an option to make(1) so it
will ignore the `@' symbol. The following adds a `-@' option (the
option letter could be easily changed). I haven't updated make.1,
but will if the following is acceptable.
That won't work on buildworld, where it takes full control of the make
environment. You'll need to have *something* in the makefiles to allow
for it.
Index: compat.c
===
RCS file: /home/CVSROOT/./src/usr.bin/make/compat.c,v
retrieving revision 1.12
diff -u -r1.12 compat.c
--- compat.c 1998/09/09 05:15:38 1.12
+++ compat.c 1999/06/07 22:12:24
@@ -239,7 +239,8 @@
while ((*cmd == '@') || (*cmd == '-')) {
if (*cmd == '@') {
- silent = TRUE;
+ if (!notSilent)
+ silent = TRUE;
} else {
errCheck = FALSE;
}
Index: job.c
===
RCS file: /home/CVSROOT/./src/usr.bin/make/job.c,v
retrieving revision 1.12
diff -u -r1.12 job.c
--- job.c 1999/02/14 22:22:42 1.12
+++ job.c 1999/06/07 22:11:41
@@ -483,7 +483,7 @@
* JobPrintCommand --
* Put out another command for the given job. If the command starts
* with an @ or a - we process it specially. In the former case,
- * so long as the -s and -n flags weren't given to make, we stick
+ * so long as the -@, -s and -n flags weren't given to make, we stick
* a shell-specific echoOff command in the script. In the latter,
* we ignore errors for the entire job, unless the shell has error
* control.
@@ -561,7 +561,8 @@
*/
while (*cmd == '@' || *cmd == '-') {
if (*cmd == '@') {
- shutUp = TRUE;
+ if (!notSilent)
+ shutUp = TRUE;
} else {
errOff = TRUE;
}
Index: main.c
===
RCS file: /home/CVSROOT/./src/usr.bin/make/main.c,v
retrieving revision 1.30
diff -u -r1.30 main.c
--- main.c1999/03/01 06:01:05 1.30
+++ main.c1999/06/07 22:17:43
@@ -133,6 +133,7 @@
Boolean usePipes; /* !-P flag */
Boolean ignoreErrors; /* -i flag */
Boolean beSilent; /* -s flag */
+Boolean notSilent; /* -@ flag */
Boolean beVerbose; /* -v flag */
Boolean oldVars;/* variable substitution style
*/
Boolean checkEnvFirst; /* -e flag */
@@ -172,12 +173,16 @@
optind = 1; /* since we're called more than once */
#ifdef REMOTE
-# define OPTFLAGS BD:I:L:PSV:d:ef:ij:km:nqrstv
+# define OPTFLAGS @BD:I:L:PSV:d:ef:ij:km:nqrstv
#else
-# define OPTFLAGS BD:I:PSV:d:ef:ij:km:nqrstv
+# define OPTFLAGS @BD:I:PSV:d:ef:ij:km:nqrstv
#endif
rearg: while((c = getopt(argc, argv, OPTFLAGS)) != -1) {
switch(c) {
+ case '@':
+ notSilent = TRUE;
+ Var_Append(MAKEFLAGS, -@, VAR_GLOBAL);
+ break;
case 'D':
Var_Set(optarg, 1, VAR_GLOBAL);
Var_Append(MAKEFLAGS, -D, VAR_GLOBAL);
@@ -1280,7 +1285,7 @@
usage()
{
(void)fprintf(stderr, %s\n%s\n%s\n,
-usage: make [-Beiknqrstv] [-D variable] [-d flags] [-f makefile],
+usage: make [...@beiknqrstv] [-D variable] [-d flags] [-f makefile],
[-I directory] [-j max_jobs] [-m directory] [-V variable],
[variable=value] [target ...]);
exit(2);
Index: make.h
===
RCS file: /home/CVSROOT/./src/usr.bin/make/make.h,v
retrieving revision 1.8
diff -u -r1.8 make.h
--- make.h1998/11/14 16:15:04 1.8
+++ make.h1999/06/07 22:12:25
@@ -294,6 +294,7 @@
extern Boolean compatMake; /* True if we are make compatible */
extern Boolean ignoreErrors; /* True if should ignore all errors */
extern Boolean beSilent;/* True if should print no commands */
+extern Boolean notSilent; /* True if should print `@' commands */
extern Boolean beVerbose; /* True if should print extra cruft */
extern Boolean noExecute; /* True if should execute nothing */
extern Boolean allPrecious; /* True if every target is precious */
Peter
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: bsd.lib.mk @'s
On Mon, 7 Jun 1999, Chuck Robey wrote:
On Tue, 8 Jun 1999, Peter Jeremy wrote:
I have an alternative compromise - add an option to make(1) so it
will ignore the `@' symbol. The following adds a `-@' option (the
option letter could be easily changed). I haven't updated make.1,
but will if the following is acceptable.
That won't work on buildworld, where it takes full control of the make
environment. You'll need to have *something* in the makefiles to allow
for it.
Anyway, it seems much more drastic to change the user interface to
make(1) than to change a makefile. No?
I don't see what's wrong with the ${SILENT} suggestion.
--
Ben
UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
