On Thursday March 31 2016 12:02:53 Mojca Miklavec wrote: > It might make more sense if we would solve this "globally", even > though I'm not exactly sure how. We are constantly getting
I'd agree. In that case, I'd argue for something like an internal post-post-phase which simply copies everything related to the phase just executed from main.log to a specific file in the work dir. That could even be under control of some kind of setting. Of course that would still overwrite the copy when a failing phase is executed again, but that may be less of an issue for bug reports. I usually prefer to take a look (on trac!) at a log showing only the (compile) command that raises the error, rather than having to download and dig through a potentially huge file (and I vastly prefer it when a submitted log is from a serial build, btw). > try building again, resubmit main.log". Perhaps appending to main.log > would help in some way assuming it wouldn't just make things worse and > more confusing. The log would still be deleted at every "clean" and In that case it'd be good to maintain some kind of attempt counter which is stored in the header of each log line, or prominently where the append starts, to facilitate navigation and filtering. > every time the "port" detects a change in Portfile (without the `-o` Yeah, that'd create huge files for me because I rarely skip the -o in my workflow, nowadays. > keep all the relevant information. And you wouldn't have to worry > about deleted logs and implement super weird hacks in Portfiles. "base" could also provide a procedure that developers can call from Portfiles where the feature makes more sense. R. PS: as a (former) violinist I can assure you that broken string instruments don't repeat themselves. Vinyl records could, when "broken" just the right way, and that's what the English expression refers to ;) _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
