Hi, I am testing gmic cli and the gmic gimp plugin on several different OS, like Mac, (virtual) Windows, linux, Windows wsl (windows subsystem linux) and Android Termux app!
I think it would be helpful to have in gmic global variables with the targetOS, perhaps similar to the naming in the gmic download section, the targetOS build date (and time) of gmic and a custom function returning the compilation date (and time) of update<version>.gmic! This info could extend the printout of “gmic +v”.
Ah, and possibly it would be helpful for Mac users to add some information similar to Python, e.g.
MacOS:
MacPorts (see instructions in GIMP Downloads for Mac):
By the way, actually official Gimp for Mac is only recent with MacPorts. Seemingly there is nobody to update Gimp native for Mac. MacPorts is at the beginning a bit cumbersome, still lateron it is quite easy and allows also the build of prereleases from git without problem.
Yes, that would make sense to me as well.
What I do in my own G’MIC CLI builds is that if the CLI has been called without any parameters, I call cimg::info() to spit out some info that G’MIC already has collected about the features built into it and the system it is running on:
@David_Tschumperle: I assume it is currently not possible to access the data from cimg::info() from within the G’MIC CLI or at least trigger the output?
Not bad, most of the info I proposed is there. An internal function similar the CImg examples could allow to extract the necessary information in gmic.
From what I see in the output of cimg::info(), what is really missing is the OS type, so probably a $_os variable could be good.
But apart from that, what kind of information is that really useful ? The list of libs linked against the gmic executable maybe ?
My opinion is that global variables have only few interest if they are used only to display information. On the contrary, the information they give should be compared with something in order to make some part of G’MIC commands specific to a particular case (e.g. a particular OS).
I’m not sure having a variable $_os that can take thousands of different values would be really useful in that context.
If you really need details about an OS, then maybe a system call (with exec) to e.g. lsb_release -a could be a better choice.
You are right, still looking back in this list to trace errors or problems the way gmic is compiled would help. How that information is stored or hidden in the final product is not the problem. lsb_release is one way to get information about the running system, but try to find such a method for all available systems, your g’mic is relatively widespread…
By the way, with this new _os global variable is_windows and is_macos should be superfluous or replaced.
However, your work is much appreciated, I thought to simplify a bit the exchange…
I agree with you, having a G’MIC command that do so maybe not that easy to implement. But on the other side, I’m not sure G’MIC is the software that should be used to return very precise information about the running OS. After all, this is only an image processing framework
Probably superfluous in the long term yes. I’ll probably remove them in the future.
No worries. I also appreciate your suggestions and bug reports a lot. G’MIC code wouldn’t be at this point without your help.