When I did something similar (which I am not allowed to post) I made a new file for each submake and the output filename "base" was in an environment variable. I realise that nobody ever wants to change the way they implemented something but I thought I'd mention it.
Also, having written a few external tools, I always appreciate it when the creator of some information source makes it easy for me to recover data and the relationships between each item. I also like it when there's not really any way for my parser to potentially make some mistake just because a tool prints out something similar to what I'm looking for. I also like it when the format is such that it can change a bit without necessarily forcing me to rewrite my parser. Again, this is only an opinion - it carries no weight. Regards, Tim On 29 November 2013 02:43, Eddy Petrișor <eddy.petri...@gmail.com> wrote: > > 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/ -- 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