I know. The wildcard mode is kept in the PR. Seems to me that’s wrong We should go to regexp seems to me.
I have simplified the code. See the PR.
Looks like you incorporated my macro … but maybe you could leave the “wildcard” possibility, too … see my ListLibraries.cxx source code again.
That said, I have some doubts.
This is clearly some change that breaks “backward compatibility”, but maybe there are not any people who really rely on it (well, it should explicitly be described in the “release notes”, of course).
The original source code parses the returned “libs” using " \t\s" as separators, while my macro considers only " " (on the other hand, the TSystem::GetLibraries description says it returns a space separated list of loaded shared libraries, so I don’t understand why / when another separators need to be considered and what is “\s”).
The original source code thinks there can be “-lNameOfLib” (it will remove the leading “-l”), and it will completely skip “-Lpathname” (actually, anything that begins with a “-”, except “-l”), while my macro doesn’t care.
Yes, I mentioned you in the PR log.
I thought of it but as wildcards do not work because of “/”, is it not simpler to have only regular expression? The way it is done now only changes ListLibrariesinternal code which only parses the RegExp and displays the libs satisfying it. Is that not what is requested from that simple utility?
Calling sequences are not modified so it is much less intrusive. Also, I added a clear example in the method doc.
I checked in the ROOT code and in roottest: ListLibraries is not used in any tests. So there will be no issue like comparing the new output to a reference one.
Note also that I did not keep the header and footer of the listing. That did not bring any interesting information and would only make the parsing by a program more difficult.
I’ve been thinking about the “wildcard” possibility because someone might already be using such strings with an “appropriate” number of “/” characters inside (and the required changes in the macro were trivial).
BTW. I don’t really understand why you people do it. Whatever I “propose” / commit" is done anonymously (otherwise, I would have created my own pull requests, wouldn’t I). Well, short / simple pieces of code (let’s say up to something like several tens of lines) could be “CC CC0”, and longer / complicated pieces of code could be “CC BY”.
Seems to me the list libraries always contains / in libraries’ names. A wildcard with ‘/’ does not work. Or at least I did not find a simple way to make it work. Did you ?
The regular expression on the opposite works nicely as it should. So why not simply use working code instead of something which works only when you list all the libraries (which I think 99% of the 0.1% of people using this functionality are doing).
Because that’s the proper way to behave when you use (or get some inspiration from) code written by somebody else.
In the case of “wildcards”, you need to use an appropriate number of “/*” substrings (yes, it’s a pain, but maybe someone really wants to make sure that some library comes from some precisely defined directory).
For your example, in one of the previous posts, you would need:
root -l -q 'ListLibraries.cxx("/*/*/*/*/*/*Core*", kTRUE)'
Well, short / simple pieces of code (let’s say up to something like several tens of lines) could be “CC CC0”, and longer / complicated pieces of code could be “CC BY” → Wikipedia → Creative Commons license
Ok, but that’s a real pain, isn’t it ? plus this solution requires to add an extra parameter, and then the help will need to explain the diffrence between wilcard and regexp. Are we sure we want a such complexity for a such simple fonctionnality ?
Of course one other track will be to understand why ‘/’ are special in wilcard.
I’ll check.
I know, but that’s not really convincing.
The new version of ListLibraries has been approved. I will merge the PR. Thanks, @abelloni to have seen the problem and @Wile_E_Coyote for your help.