I find it difficult sometimes to locate errors/warnings in large projects upon make-ing (gnu). How do I segregate the errors/warnings from the usual compilation messages when the error does not stop the build process from going any further? A wrapper shell script could pick and display whatever I want, but before fleshing out one I thought of asking about the alternatives.
Thanks.
In theory, make -s will suppress the "routine" output of the build process, leaving you with only the errors and warnings. Also in theory, make will stop as soon as it encounters an error.
If either of those is not true for the project(s) you're working with, that's probably due to poorly written makefiles. So fixing the makefiles is one alternative.
To help make sense of verbose builds, some simple highlighting as provided by colorgcc can go a long way. IDEs like eclipse or even emacs can also helpfully pick out the error messages in the build output.
Also, it might be helpful to note that warning and error messages are usually written to stderr, while everything else goes to stdout. So it might be useful to simply discard stdout like so: make >/dev/null.
Related
I'm experiencing an issue with QTCreator. It doesn't parse compiler output and IssueTab is always empty, in spite of compiler output contains some. It seams that complier output is totally made to stdout and not to stderr (compile output is totally grey).
That happens if I use XCode Cmake generator. When I switch to Unix MakeFiles generator issues are shown normally, but I stacked to Xcode as project is really old and is written to support only XCode.
Search in google for some specific flags for Xcode generator hand't provided any useful response.
Thus I'm asking the Community.
A small hack: 1>&2. Now everything goes to stderr, and QtCreator tries to parse it
UPD: -quiet makes output more clean
How to make xcodebuild print compile errors and warnings to stderr?
I am getting some mysterious compiler type related errors in my ts code. I have another thread addressing them.
But I know there will be no adverse reactions to my code, so I would like to force it to compile and make my js files anyway so I can do some run-time debugging.
I have seen a comment or two about the project compiling despite some build errors. How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
I have VS2013 and TS 1.5.
Thanks, Brad
How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
Make sure that in your csproj you have noEmitOnError set to false.
When compiling a solution with many projects, if I make a compile time error in a project that many other projects use I'll get a flood of errors in the Error List window of visual studio:
Error 80 Metadata file
'C:\trunk\Projects\Libraries\K2DataBaseClient\bin\x64\Debug\CEPCortex.dll'
could not be found C:\trunk\Projects\TradeAiTeacher\CSC
These errors indicate that a project couldn't be built due to another project not being built. These types of errors cascade and don't really tell me anything useful as I know that its all due to a core project failing to build.
These errors often make it harder to find the actual error in the window.
Is there a way to tell visual studio to suppress this type of output and just show me the compile errors in cases like this to make it easy to find what actual code is broken?
Ideally it once the compile error has been fixed we can toggle this hiding off so I see all errors.
I had originally left this version agnostic but visual-studio 2013 is the version I am most concerned with.
No. The C# compiler categorically refuses to consider one error more "important" than another one. It cannot know how important an error can be, it doesn't know enough about the reason it had to produce the error. A missing reference assembly can produce a lot of errors because type definitions are missing. Of course the compiler cannot know the difference between them being undefined because of the missing assembly reference (ignore) or you mistyping a name (don't ignore).
Interpreting the Error List requires a massively parallel computing machine that's capable of high-speed correlation inference and pattern matching. With practical quantum computing still a distant future, you need to use the one that's readily available to any programmer, the one you have between your ears. Start at the top of the list. And work your way down, feeling less inclined to fix them as you progress down the list.
Never hesitate to rebuild before getting to the end of the list when you fixed a gross error. Like a missing assembly reference.
I've found the best way to work with existing the visual studio behavior is to use the advice in this link: and make the compiler stop after the first compile error.
This seems to get as close to solving my problem as you currently can.
In my attempt to compile GCC I noticed that while ./configure doesn't yield error messages and returns an error code of 0, there are still errors logged in config.log, which do later on cause make to fail. So, why doesn't configure fail already? Or does make modify config.log later on?
config.log contains the output of all configure probes. Some of them are expected to fail. For example, frequently Autoconf probes for several different possible alternative implementations of particular functionality, and some of them are expected to fail depending on the characteristics of your system.
It's therefore up to the author of the Autoconf configure.ac script to explicitly fail the configure step if the results are not viable. Some people do this when writing their configure.ac and some don't. Sometimes it can be quite hard to know at configure time whether a particular set of findings are viable. There's also a reasonable argument that it's easier to diagnose problems during the build, later on, than to issue an error message from configure and make people search through config.log for the details. That's particularly the case if the problems are relatively obscure.
The short answer is that configure didn't fail because the people who wrote the configure script you're running didn't program it to fail for the specific errors that you're seeing, for one reason or another.
I have a large legacy codebase with very complicated makefiles, with lots of variables. Sometimes I need to change them, and I find that it's very difficult to figure out why the change isn't working the way I expect. What I'd like to find is a tool that basically does step-through-debugging of the "make" process, where I would give it a directory, and I would be able to see the value of different variables at different points in the process. None of the debug flags to make seem to show me what I want, although it's possible that I'm missing something. Does anyone know of a way to do this?
Have you been looking at the output from running make -n and make -np, and the biggie make -nd?
Are you using a fairly recent version of gmake?
Have you looked at the free chapter on Debugging Makefiles available on O'Reilly's site for their excellent book "Managing Projects with GNU Make" (Amazon Link).
I'm sure that remake is what you are looking for.
From the homepage:
remake is a patched and modernized version of GNU make utility that adds improved error reporting, the ability to trace execution in a comprehensible way, and a debugger.
It has gdb-like interface and is supported by mdb-mode in (x)emacs which means breakponts, watches etc. And there's DDD if you don't like (x)emacs
From the man page on make command-line options:
-n, --just-print, --dry-run, --recon
Print the commands that would be executed, but do not execute them.
-d Print debugging information in addition to normal processing.
The debugging information says
which files are being considered for remaking,
which file-times are being compared and with what results,
which files actually need to be remade,
which implicit rules are considered and which are applied---
everything interesting about how make decides what to do.
--debug[=FLAGS] Print debugging information in addition to normal processing.
If the FLAGS are omitted, then the behaviour is the same as if -d was specified.
FLAGS may be:
'a' for all debugging output same as using -d,
'b' for basic debugging,
'v' for more verbose basic debugging,
'i' for showing implicit rules,
'j' for details on invocation of commands, and
'm' for debugging while remaking makefiles.
I'm not aware of any specific flag that does exactly what you want, but --print-data-base sounds like it might be useful.
remake --debugger all
More info https://vimeo.com/97397484
https://github.com/rocky/remake/wiki/Installing
There is a GNU make debugger project at http://gmd.sf.net which looks quite useful. The main feature supported by gmd is breakpointing, which may be more useful than stepping. To use this, you download gmd from http://gmd.sf.net and gmsl from http://gmsl.sf.net, and do an 'include gmd' in your makefile.