[perl #31849] [PATCH] Slightly quieter and more informative compilation
Andy Dougherty
# Please include the string: [perl #31849]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31849 >
The following patch makes compilation both slightly quieter and also
slightly more informative.
Or, with less "spin", it fixes bad advice I gave previously. Specifically,
I had previously noted that it's generally helpful if the Makefile prints
out the commands it is trying to execute so that it's easier to track down
problems when they fail. When I suggested that the '@' be removed from
the .pbc.imc rule, I suggested at the same time that the '@' also be
removed from the compilation step above it.
Alas, that wasn't quite the right place to do it. What's ultimately of
interest is the command that actually gets called. Accordingly, this
patch puts the '@' back in front of the invocation
of tools/dev/cc_flags.pl, but changes the print statement in
tools/dev/cc_flags.pl to show the actual compilation command being issued.
Again, I have found that information to be useful on numerous
occasions. Also, considering how noisy the whole ICU build is, I
think the extra clutter for parrot's sources is not a significant
additional burden.
diff -r -u parrot-current/config/gen/makefiles/root.in parrot-andy/config/gen/makefiles/root.in
--- parrot-current/config/gen/makefiles/root.in Mon Oct 4 08:39:29 2004
+++ parrot-andy/config/gen/makefiles/root.in Tue Oct 5 10:46:06 2004
@@ -441,7 +441,7 @@
# arguments (etc) injected in the middle.
# There is probably a better way to do this, but I can't work it out right now.
.c$(O) :
- $(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) "" $(CFLAGS) -I$(@D) ${cc_o_out}$@ -c $<
+ @$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) "" $(CFLAGS) -I$(@D) ${cc_o_out}$@ -c $<
%.pbc:%.imc
.${slash}$(TEST_PROG) -o $@ $<
diff -r -u parrot-current/tools/dev/cc_flags.pl parrot-andy/tools/dev/cc_flags.pl
--- parrot-current/tools/dev/cc_flags.pl Sun Jul 11 19:00:17 2004
+++ parrot-andy/tools/dev/cc_flags.pl Tue Oct 5 10:46:20 2004
@@ -107,6 +107,6 @@
}
}
-#print "@ARGV\n";
-print "$cfile\n";
+print "@ARGV\n";
+# print "$cfile\n";
exit system(@ARGV)/256;
--
Andy Dougherty doug...@lafayette.edu
Steve Fink
>
> The following patch makes compilation both slightly quieter and also
> slightly more informative.
>
> Or, with less "spin", it fixes bad advice I gave previously. Specifically,
> I had previously noted that it's generally helpful if the Makefile prints
> out the commands it is trying to execute so that it's easier to track down
> problems when they fail. When I suggested that the '@' be removed from
> the .pbc.imc rule, I suggested at the same time that the '@' also be
> removed from the compilation step above it.
>
> Alas, that wasn't quite the right place to do it. What's ultimately of
> interest is the command that actually gets called. Accordingly, this
> patch puts the '@' back in front of the invocation
> of tools/dev/cc_flags.pl, but changes the print statement in
> tools/dev/cc_flags.pl to show the actual compilation command being issued.
>
> Again, I have found that information to be useful on numerous
> occasions. Also, considering how noisy the whole ICU build is, I
> think the extra clutter for parrot's sources is not a significant
> additional burden.
Makes sense to me. Applied, thanks.
Tell me again why Andy doesn't have commit privs yet?
Leopold Toetsch
> Again, I have found that information to be useful on numerous
> occasions. Also, considering how noisy the whole ICU build is, I
> think the extra clutter for parrot's sources is not a significant
> additional burden.
I don't like the change, it just hides all warnings. Further "make -s"
just broken now.
While building ICU is noisy, it doesn't mean that building parrot should
be as noisy or even more.
But I see of course the point of beeing able to see the current build
command. What about that: cc_flags.pl prints the build command if it
changes, i.e. if there are any changes except the filename(s) involved.
leo
Andy Dougherty
> Andy Dougherty (via RT) wrote:
> I don't like the change, it just hides all warnings.
Odd. I don't see that. Hiding all warnings would certainly be
bad, but I still seem to get warnings. I'll go back and look at that more
closely.
> Further "make -s" is just broken now.
Oops. I hadn't thought of that. I didn't even know it existed -- I had
to go look it up! Good catch.
If 'make -s' is indeed useful, then I agree we oughtn't be doing an end
run around it. Hmm. It might be possible and sensible to have
tools/dev/cc_flags.pl only print the command if $ENV{MAKEFLAGS} doesn't
contain 's'. Or perhaps it's simpler and better to just retract the
patch.
> But I see of course the point of beeing able to see the current build
> command. What about that: cc_flags.pl prints the build command if it
> changes, i.e. if there are any changes except the filename(s) involved.
That's probably not that useful -- in the usual case, there are no
changes, so the 'Compiling with ....' line might be a couple of thousand
lines above the current executing command.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> On Wed, 6 Oct 2004, Leopold Toetsch via RT wrote:
>> I don't like the change, it just hides all warnings.
> Odd. I don't see that. Hiding all warnings
Hiding in the sense of: they don't stand out, they aren't really
visible.
> If 'make -s' is indeed useful, then I agree we oughtn't be doing an end
> run around it.
Well, 'make -s' is the command I'm using in 99% of compiles ;) For
warnings (or errors) I see a nice line, else just filenames ...
> tools/dev/cc_flags.pl only print the command if $ENV{MAKEFLAGS} doesn't
> contain 's'. Or perhaps it's simpler and better to just retract the
> patch.
I don't know, if $ENV{MAKEFLAGS} and "-s" is available everywhere.
>> But I see of course the point of beeing able to see the current build
>> command. What about that: cc_flags.pl prints the build command if it
>> changes, i.e. if there are any changes except the filename(s) involved.
> That's probably not that useful -- in the usual case, there are no
> changes, so the 'Compiling with ....' line might be a couple of thousand
> lines above the current executing command.
There are some changes e.g. when different CFLAGS settings are used, or
for compiling classes. When there is a problem with compiling, just type
another 'make' and you'll get again "Compiling with ...".
leo
Steve Fink
> Andy Dougherty <doug...@lafayette.edu> wrote:
>
> There are some changes e.g. when different CFLAGS settings are used, or
> for compiling classes. When there is a problem with compiling, just type
> another 'make' and you'll get again "Compiling with ...".
I think this may be gmake-specific, but in the past I have used
ifeq (,$(VERBOSE))
BREVITY=@
else
BREVITY=
endif
c.o:
$(BREVITY)$(CC) $(CFLAGS)...
To make it make version independent, we could do it as
SUPPRESS=@
c.o:
$(SUPPRESS)$(CC) $(CFLAGS)...
and then run make as 'make SUPPRESS=' when we wanted to see the
messages.
Andy Dougherty
> Andy Dougherty <doug...@lafayette.edu> wrote:
> > On Wed, 6 Oct 2004, Leopold Toetsch via RT wrote:
>
> >> I don't like the change, it just hides all warnings.
>
> > Odd. I don't see that. Hiding all warnings
>
> Hiding in the sense of: they don't stand out, they aren't really
> visible.
Ah, I understand now. In the absence of 'make -s', this particular patch
actually didn't do much in that regard, but yes, with 'make -s', I can see
how they are less visually striking.
Oh well, just retract the patch. The whole 'Makefile' system is
"temporary" anyway, so it's probably not productive to worry too much
about it.
--
Andy Dougherty doug...@lafayette.edu