Jonny Grant writes: > > If you do it that way, now you've got two different formats for the > > same message. This can be confusing to users, and certainly > > complicates factors if there is software sitting on top of Make and > > operating on the messages (continuous integration / automatic failure > > triage). > > CI uses program return codes in my experience. > EXIT_SUCCESS is 0
On failure, CI may operate on the output text to determine the locus of the actual failure, and automatically file defects. > > > Consider the following other special cases: > > > > o Gnu Make has $(eval), and it's possible to generate rules that > > don't correspond to actual Makefile lines. > > I thought the message only related to targets. > Do you mean if targets are generated by $(eval) ? Yes. > > > o What if there are multiple targets that refer to 'test.o'? > > Should all be reported, or just the one that failed? > > Often compilation only reports the first occurrence of the error. Make > could behave in a similar way. A more advanced solution would > report more. Sure, it's software; it could do lots of things. The point I'm trying to get across is that requesting a feature in a mature product means that many scenarios must be explored, including not breaking existing uses. -- There's not enough Naugahyde in the world today. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
