Community
Participate
Working Groups
The builder emits the entire build command for each compilation unit. This includes for instance, all of the additional include paths (with switch /I). If the path to each of these is long, and you have a few such paths, the entire command can fill up about 10 lines in the build output console. This is unnecessary because these paths are the same for ALL the compilation units. Moreover it makes it difficult to see the most important information - at a glance - that is the name of the file being compiled. The requested fix is to replace this output with one line for each compilation unit including the name of the file as its path relative to the project directory.
The idea is that the build console should show you exactly what is being sent to the compiler. We cannot replace the output with just a listing of the files being compiled, as that would break the scanner discovery and error parsing mechanisms, which look for compiler invocations in the output. They may need to see all the options (scanner discovery especially).
Hey Chris, (In reply to comment #1) > We cannot replace the output with just a listing of the files being compiled, > as that would break the scanner discovery and error parsing mechanisms, which > look for compiler invocations in the output. They may need to see all the > options (scanner discovery especially). I think this is valid enhancement. The existing build output is very verbose. For managedbuild we don't do scanner discovery (only builtins), for non-MBS integrators may have scanner discovery which isn't from build output parsing. Error parsing for managedbuild is also easier as all commands are run from the root of the build directory. Because of the above I think we could trim the managedbuild output without affecting the quality of the integration.
I also think that this is valid. There could be cases when one want to see how compiler is invoked exactly but managed build is supposed to take care of options itself. MBS knows own options so it should supply them directly. I believe there are cases when it does not, i.e. if you put -I in "Other flags". For this case or if user really wants to see the output we could consider introducing "verbose" property but I think for MBS printing the command line is unnecessary and for big projects undesirable. I also think such "verbose" mode should be turned off by default.
Actually, we do scanner discovery on managed build. That's how anything you put in the "other options" boxes gets found.
(In reply to comment #3) > For this case or if user really wants to see the output we could consider > introducing "verbose" property but I think for MBS printing the command line is > unnecessary and for big projects undesirable. I also think such "verbose" mode > should be turned off by default. I can live with it if you want an option for this, but I think you need to have it preserve the existing behaviour by default, i.e. this new option would be off by default. I still have concerns that this would possibly break some error parsers, but if the user wants to take the risk and turn off the output, that can be their problem I guess.
(In reply to comment #4) > Actually, we do scanner discovery on managed build. That's how anything you > put in the "other options" boxes gets found. Who's we ;). I know that doesn't happen here. Scanner discovery is only used for built-ins and everything else is provided by our SDK integration and project references.
(In reply to comment #6) > Who's we ;). I know that doesn't happen here. Scanner discovery is only used > for built-ins and everything else is provided by our SDK integration and > project references. We = CDT GNU toolchain integration
(In reply to comment #4) > Actually, we do scanner discovery on managed build. That's how anything you put > in the "other options" boxes gets found. Is there actually a good reason to prefer adding that in "other options" rather than in "Includes" or "Defined symbols" or it's just because UI gives the user that option?
(In reply to comment #8) > (In reply to comment #4) > > Actually, we do scanner discovery on managed build. That's how anything you put > > in the "other options" boxes gets found. > Is there actually a good reason to prefer adding that in "other options" rather > than in "Includes" or "Defined symbols" or it's just because UI gives the user > that option? Generally speaking the user doesnt need to. I suppose it's possibe that they may do some crazy stuff like undefine macros and then define them again. Really I would think they ought not to put any macros or include paths there, but we can't stop them either. I suppose it's faster to enter them there if you have a lot of them and you just want to paste them in from somewhere without being forced to add them one at a time throug the regular UI, that may entice some people. Not sure how commonly or uncommonly that happens.
(In reply to comment #6) > (In reply to comment #4) > > Actually, we do scanner discovery on managed build. That's how anything you > > put in the "other options" boxes gets found. > Who's we ;). I know that doesn't happen here. Scanner discovery is only used > for built-ins and everything else is provided by our SDK integration and project > references. Currently scanner discovery on build output is not done with Internal Builder but performed by External Builder.
I've put myself to the CC list. It's because I also think output is too verbose. For example, I'm involved in a project now where we have tons of include paths and thus I get around 30-40 lines for the compiler call plus around 10 lines compiler output (like flash usage - it is an embedded C compiler toolchain). For every single compilation unit, of course. As you can imagine the compiler output (warnings, errors) is hard to find in the overall console output. Of course I could use the "Problems" view but I would prefer to use the console directly instead due to some reasons which is off-topic here I think. What I would find handy is if it would just show the name of the current compilation unit plus any warning or error issued by the compiler (probably everything which the appropriate parser would mark). Of course I would also prefer if there is an option to turn this feature on or off such that I could view the original output when I want to.
