Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix version reading for some of development tools #591

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Fix version reading for some of development tools #591

wants to merge 1 commit into from

Conversation

kapsh
Copy link
Contributor

@kapsh kapsh commented Dec 30, 2020

No description provided.

@kapsh
Copy link
Contributor Author

kapsh commented Dec 30, 2020

I noticed that some of development tools displayed as "not found" despite them being installed. This should fix detection for some of them.

2020-12-30_19-14-38_devtools

kapsh
kapsh commented Dec 30, 2020
View reviewed changes
Copy link
Contributor Author

@kapsh kapsh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see how to fix "Python (default)" within this function: it targets stderr for python command but this works only for python2. When this command points to python3, it's stdout ignored.

Maybe just remove that line?

hardinfo/util.c
@@ -1432,6 +1432,7 @@ gboolean hardinfo_spawn_command_line_sync(const gchar *command_line,
GError **error)
{
shell_status_pulse();
DEBUG("Trying: %s", command_line);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind if I leave it here? It slightly helps to discover how hardinfo works internally.

modules/computer.c
@@ -294,7 +294,8 @@ void scan_dev(gboolean reload)
{ N_("LLDB"), "lldb --version", "(?<=lldb version )(\\d\\.?)+", TRUE },
{ N_("strace"), "strace -V", "\\d+\\.\\d+\\.?\\d*", TRUE },
{ N_("valgrind"), "valgrind --version", "\\d+\\.\\d+\\.\\S+", TRUE },
{ N_("QMake"), "qmake --version", "\\d+\\.\\S+", TRUE},
{ N_("QMake (Qt 5)"), "qmake-qt5 --version", "\\d+\\.\\S+", TRUE},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qmake binary (or symlink) is not always installed, and there can be more than one present.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where are qt4 related here? some 3thr party system only runs in qt4

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing this out. I remember qt4 being unsupported for five years, but it looks like at least stable debian has it, thus it should be supported here as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does not matter is are supproted or not.. currently there are complete desktop build around qt4 you know it? trinity desktop! and some NASA related programs only runs under qt4 and python2 you know it?

modules/computer.c
@@ -280,7 +280,7 @@ void scan_dev(gboolean reload)
{ N_("C (Clang)"), "clang -v", "\\d+\\.\\d+", FALSE },
{ N_("D (dmd)"), "dmd --help", "\\d+\\.\\d+", TRUE },
{ N_("Gambas3 (gbc3)"), "gbc3 --version", "\\d+\\.\\d+\\.\\d+", TRUE },
{ N_("Java"), "javac -version", "\\d+\\.\\d+\\.\\d+", FALSE },
{ N_("Java"), "javac -version", "(?<=javac )(\\d+.?)+", TRUE },
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Java is a mess. Recent versions (checked on 11) report version to stdout while older (checked 6 and 8) write it to stderr. But taking into account that 11 is only LTS available (for "casual" users) and java 8 have no public updates anymore, should be safe to use newer way from now.

Regex changed because I've seen javac 11.0.9.1 on centos 7.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

almost 90% of 3trh party java progams does not runs with "only LTS available", almost java 8 are commonly used today, seems you are talking only about openjdk right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my experience there is only single java binary installed inside /bin or /usr/bin in various distributions.
Played with centos:7 container just to be sure. /usr/bin/java symlinked to /etc/alternatives/java which is symlinked to one of javas inside /usr/lib/jvm.

@mckaygerhard
Copy link
Contributor

this is a mess.. for those software that are crap in versioning (python java etc) is better to provide module for deteccion and present as comma separated string by example:

Java: 8 (8.3.126), 11 (11.9.1)
php: 5 (5.6.40), 7 (7.3.4)

@lpereira
Copy link
Owner

Thanks, @kapsh!

Since you marked this PR as a draft, here are some suggestions to improve this feature:

  • Instead of a boolean saying "use stderr", have a mask: "stderr" (1<<2), "stdout" (1<<0), or "stderr+stdout" (1<<2|1<<0). If both are set, and if one produces empty output, we try the other; otherwise, we try the first one.
  • Group by programming language, and list known executable names for that programming language. Useful for things like Java, Python, C and C++, and even C# (with Roslyn and Mono for instance). If multiple versions are found, we list them as @mckaygerhard suggested.

@kapsh
Copy link
Contributor Author

kapsh commented Jan 30, 2021

@lpereira @mckaygerhard I believe that your suggestions can be summarised in this way:

  1. Find every possible binary by wildcard. Say, python* => python, python2, python3 => display both binary name and version in GUI as "Python: python (version 2.7), python3 (version 3.9), etc.". Probably this will also require running glob over every PATH item.
  2. Pack 3 values into read_stdout to solve stderr<=>stdout changes between releases.

Sounds fine?

@lpereira
Copy link
Owner

lpereira commented Feb 1, 2021

By wildcard might be a problem, because, let's say we glob on python*, and there's a program called python-something in the path; that'll be executed, too.

@kapsh
Copy link
Contributor Author

kapsh commented Feb 1, 2021 via email

@lpereira lpereira mentioned this pull request Feb 21, 2021
Open
@baryluk
Copy link

baryluk commented Feb 22, 2021

The python one should be left alone. It is reporting things correctly as not found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mckaygerhard mckaygerhard mckaygerhard left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@kapsh @mckaygerhard @lpereira @baryluk