Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Why end with many "Abandoned" error lines instead of the actual errors?

See original GitHub issue

I started using catkin_tools recently, and apparently lots of thoughts went in there from a workspace maintainers’ point of view. But when I actually develop code in a non-minimal workspace and something fails to build in the middle of the build process, at the end of the console output I get tons of lines saying

Abandoned <<< XYZ                                 [ Unrelated job failed ]

instead of the actual build errors, or even the name of the failed package. Together with the typical length of C++ error messages this easily exceeds scrollback on my systems and I end up using combinations of catkin build, catkin build >/dev/null, catkin build 2>&1 | less to build my workspace. It would be very nice for usability if at the end of the output (1.) there would the error log of the failed package, possibly only the first few lines, or (2.) a line saying “package xyz failed to build. Look here for the full error log: /logfile”. Another alternative would be to just stop processing after the first error. Of course something like this could be optional.

What would you prefer upstream?

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:8 (8 by maintainers)

github_iconTop GitHub Comments

rackocommented, Apr 6, 2018

You should check out the --summarize option:

  --summarize, --summary, -s
                        Adds a build summary to the end of a build; defaults
                        to on with --continue-on-failure, off otherwise

It can become a bit verbose as well, but it does the part of the trick: It lists failed, successful, ignored and abandoned packages.

v4hncommented, Dec 1, 2022

With #734 merged, the biggest chunk of this issue is addressed for me and it’s easy to rerun the build for the failed package once you know its name. It would still be nice to have the build error log for the package printed with the output reporting the failed package name, but I will still close the issue here now.

it would be nice to see a new release that includes this and the other unreleased patches.

Thanks @timonegk ! 🐈

Read more comments on GitHub >

github_iconTop Results From Across the Web

Error bars do not work with custom values - multiple series chart
I have a bar which has multiple series. Think of it as a number charts combined together.
Read more >
Errors—ArcGIS Pro | Documentation
Errors can be created for a variety of reasons, from identifying empty geometries and invalid connectivity to discovering incorrect asset types in a...
Read more >
Visual Studio compiles fine, but it still shows red lines
When I open my code it shows red Underlines which we usually see when there is an error in our code. Surprisingly, the...
Read more >
Designing Better Error Messages UX - Smashing Magazine
Errors are everywhere, and so are error messages. They are of course common in web forms, but also in complex tables, incompatible filters, ......
Read more >
Common sentence faults | Write Site | Athabasca University
Gordon hoped that Emma would abandon the idea of suing the company, for her own sake as much as for anybody else's. Typical...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found