Author Topic: RFC: collect system information so users can attach it when looking for help  (Read 535 times)

Offline Miguel Gimenez

  • Almost regular
  • **
  • Posts: 130
The attached code returns extended system information (including active plugins and their versions) that can complement the build log when somebody looks for help in the forum.

This information could be added to (for example):
  - the build log (always or only when rebuilding)
  - a new tab in the About dialog
  - under the Help menu, like Firefox does (I don't know english wording, Information for solving problems?)
  - when saving the build log to HTML

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2062
i would expand this even future:
  • Print the full executable path for the compiler, linker ecc at the beginning of every build target
  • Print all variable expansions at the beginning of every build target
  • Print all back tick expansions at the beginning of the build process
  • Probably add also a compiler -v output so the version of the compiler is added at every build target (make this optional)

I would output this all in the build log, or the output html. This would help finding problems a lot. I don't think that there is a large performance impact. If it is we could add a option to disable this "verbose" logging. I had many situations where the information from the list would have saved me a lot time finding errors..

We could create a minimal plugin, that collects all this information and creates a zip file, ready to upload to the forum...

Offline Miguel Gimenez

  • Almost regular
  • **
  • Posts: 130
I have added the compěler location, executables' names and user variable expansions (not the macros, because the MacroManager does not collaborate). This is done at project level, not for each target,

The information is shown in tab called System inside the About dialog. The data adquisition function is in dlgAbout.cpp declared as static, so it can be called from everywhere without instantiating dlgAbout.

Due to the generated enthusiasm I put the patch here instead of creating a ticket; If it were accepted then I would create a ticket.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2062
I would also add the Backtick map found in

globals.cpp:859
Code: [Select]
typedef std::map<wxString, wxString> BackticksMap;
BackticksMap m_Backticks; // all calls share the same cache
wxString ExpandBackticks(wxString& str) // backticks are written in-place to str
This is also something that is cached, never cleaned until restart and can mess up things quite hard and obfuscated.

Some nice formatting with html or markdown would be nice...

I don't know what i think about the place in the about dialog...

Quote
(not the macros, because the MacroManager does not collaborate)
What is the problem? I think at least the macros of the activated project should be added...

[edit:] Also detailed wxWidgets library information would be nice. I think this sys info should be splitted up in two: "Codeblocks system info" with plugins end wxWidgets ecc.. and "Build system info" with macros backticks ecc..
« Last Edit: September 25, 2018, 11:13:02 pm by BlueHazzard »

Offline Miguel Gimenez

  • Almost regular
  • **
  • Posts: 130
Quote
I would also add the Backtick map

I will check, didn't know how to access them

Quote
Some nice formatting with html or markdown would be nice...

The text format is better for the tab and for copy/paste. If this information is ever added to the HTML build log I will add HTML formatting.

Quote
I don't know what i think about the place in the about dialog...

This is the least intrusive place I saw, anyway it can be moved to another place.

The macros manager has no public method to retrieve the macro information, of course this can be changed but possibly devs will be reluctant.

Quote
Also detailed wxWidgets library information would be nice

What detailed information? Are you talking about the library used to compile CB or the one (possibly) used in the project?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11197
    • Travis build status
The macros manager has no public method to retrieve the macro information, of course this can be changed but possibly devs will be reluctant.
If it is for read only purposes, I don't see a problem. Also there should be a comment saying that this is supposed to be used by the logger and could be removed without notice at any time.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Miguel Gimenez

  • Almost regular
  • **
  • Posts: 130
I have moved the info collection routines into a class and added HTML generation capability (sample attached).
Where should this class be? It should be called from the About dialog and the compilergcc plugin.


Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5108
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Where should this class be? It should be called from the About dialog and the compilergcc plugin.
Still in the src/src/dlgabout.cpp?

Anyway, you did a very nice job! Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2062
i was talking about the wxWidgets used by the codeblocks executable.

My final imaginary goal is a button "Collect data to report to forum" and we get all information needed to help people without asking for every part slowly..

Offline Miguel Gimenez

  • Almost regular
  • **
  • Posts: 130