Hi Erik, Thanks for the explanations, comments below:
On 08/21/2014 07:39 PM, Erik Joelsson wrote: > As I have tried to explain a couple of times now: The jdk8 build built > each repository in sequence (much like the jdk7 build did). Because of > this it made sense to add messages about which repository was being > built and measure the time each took. I'm glad to see I am not lonely in questioning this? :) > The new jdk9 build is not repository oriented, but instead builds > modules. To increase concurrency, I dropped the sequential, non > parallel, execution model at the top level so there are a larger > number of build targets being built at the same time, based on finer > grained dependencies. What I'm trying to say here is that those > Starting/Finished messages simply do not exist anymore. I think this conflates two separate concerns: a) running sequential vs. parallel; and b) printing what build actually does, even if it figured it does not need to do anything. We can even scratch the (a) with JOBS=1. In this case, the build is just silent about what it does, which is alarming at least for me. See e.g. how Make prints "Nothing to do" messages. See e.g. how Maven treats parallel builds: no matter what is the parallelism you ask for, it will print the build log from each of those parallel-running modules, and that output, while interleaved, still be the same output you got in purely sequential builds, which is helpful to gain the trust into the build. And yes, it also faces dependencies. > I can understand people wanting more details on what took how much time > to build, but the timings need to make sense to be useful. If target A > starts executing, and then the last recipe of that target gets to wait > while all of target B gets executed, then the time for target A will > look much longer than it actually was. Perhaps this information would > still be useful, I doubt it, but could perhaps be swayed by good > arguments. We would also need to figure out a proper granularity for > grouping timings, and if it should be grouped by modules or by tasks. It was my mistake for not being clear about my UX concerns, so this winded down to timings. Timings are not of my interest, but what modules the build had considered to build, and what was the result of that consideration, is important to me. > I think that verbosity at the default warn level is correct in not > printing more than it currently does. If something was recompiled, you > would see messages about it. I can't help but wonder why you need more > text to say "nothing happened"? This sounds like an issue with not > trusting the build (which I can identify with, it's new so is likely to > be buggy). Case in point: way too frequently I was changing something in IDE, then shooting the build from CLI, and then realizing than nothing is rebuilt in Hotspot, because I was editing the wrong workspace! You can argue that completely silent build output is the marker of nothing happened, but given my general mistrust in computers and especially Make/*sh scripts, I would rather see the explicit "Finished hotspot in 00:00:01" / "Nothing to do in hotspot" message. In Unix world, silence seems to indicate the operation completed successfully. Which means, if I observe the silent output, I have to wonder if this thing is telling me my code changes are OK, and there is nothing to worry about; or the build just haven't considered them at all, which is something I need to worry very much about, and have an early warning about. Failing to visually distinguish these two cases *is* an UX gone bad. See again how Maven handles the multi-module builds: it would print the order in which the modules are built, and it will print the summary table of what modules were actually built in the end. Do not underestimate how useful that output is to understand what just happened after I requested the build, this saved me more than once. > When setting LOG=info, I agree that there should be more > status messages about which targets were actually considered. The step > up to LOG=debug prints far too much to be useful in that regard. Again, > we need to think about the granularity of the targets we would want to > print info about here, and if it should be module or task oriented. This. I argue that printing the start/finish messages on the basic LOG level is a good thing for otherwise oblivious users. Thanks, -Aleksey.
