Pe 27.11.2013 13:12, "Tim Murphy" <tnmur...@gmail.com> a scris: > > FWIW > > As for profiling output, this should probably go to a file (possibly > with a .PID on the end) , not stdout .....unless..... you start to > embrace the idea of structured output for everything that make > produces.
The profiling info is printed on stderr, not on stdout. I also initially thought I should isolate the information in a different file, but the problem is that for recursive make that file descriptor must be passed on every fork, which is a very intrusive change to make and very wasteful (passing an extra file descriptor, even when unnecessary). So I opted for the next best thing, prefixing the output with something a grep could anchor to. > > I have used XML before and it has advantages, not the least of which > is that it is somewhat robust in the face of corruption and that does > happen. I prefer JSON though because it's more readable and it's very > easy to parse. As I said before, I think that's the job of an external tool. > > On 27 November 2013 07:56, Eddy Petrișor <eddy.petri...@gmail.com> wrote: > > > > Pe 25.11.2013 11:09, "Reinier Post" <reinp...@win.tue.nl> a scris: > > > > > >> > > Can't this functionality be provided by a wrapper $SHELL? > >> > > Sure, it's an extra exec(), > >> > > but it will keep the make code base simpler. > >> > > >> > I'm not sure if I understand what you mean. Do you mean wrapping all > >> > target invokes in a $SHELL? > >> > >> Yes; something line /usr/bin/time. > > > > Not on Windows. > > > >> > If that's the case, you don't get the actual/real-time measurement, and > >> > that might skew your profiling information. > >> > >> True. Hnow how much of a difference does it make? > > > > Depends on how badly the build system is written. And that's what the target > > of the profiling is, finding out how bad is it. I feel that penalising the > > most exactly the build systems that need the least the slow down it's bad > > design. > > > >> > I have some build systems that can take easily over 12 hours to do a > >> > full build (several thousands of elfs in recursive > >> > make calls - I know that's bad, I am working on it), so any extra time > >> > waste just for the measurement can mean > >> > significant delays in getting the results. > >> > >> If it's 15 minutes, they are not the thing you want to optimize first. > >> The build is probably running overnight anyway. > > > > If it's a live/production system, then any unknown slow down time might not > > be acceptable. > > > > > > _______________________________________________ > > Bug-make mailing list > > Bug-make@gnu.org > > https://lists.gnu.org/mailman/listinfo/bug-make > > > > > > -- > You could help some brave and decent people to have access to > uncensored news by making a donation at: > > http://www.thezimbabwean.co.uk/friends/
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
