dummzeuch 1517 Posted March 3, 2019 The GExperts Grep Search expert has various options to tell it which files to search: The current file All files in project All files in project group A directory list (separated by semicolon) That sounds like an exhaustive list, but it isn’t. Both, project and project group, were only searching files explicitly listed in the project(s). Files that were linked into the project using the search path, were not searched. Until now, that is: There is now an option to use the MAP file instead of the DPR file for project search. https://blog.dummzeuch.de/2019/03/03/gexperts-grep-can-use-the-map-file/ 2 7 Share this post Link to post
PeterPanettone 158 Posted March 18, 2019 (edited) Thomas, that is an important addition, thank you very much! You wrote in your blog: Quote If there is no MAP file, it falls back to the original method of searching files listed in the DPR file. There could be cases where the fallback is not evident because the map file creation has failed for some reason while the user believes the map file is being used because he has checked that option in the Options dialog. Therefore, I feel it would be better having a checkbox directly in the Grep Search dialog: "Indirectly used units" in the "Delphi Code Content Types" group-box: This checkbox would be automatically disabled in the case no map file exists so the user is AWARE that no indirectly used units (I call them implicit units) can be searched. Edited March 18, 2019 by PeterPanettone 1 Share this post Link to post
Stefan Glienke 2019 Posted March 19, 2019 Please explain - what does the map file have to to with finding out units that are included in the project via search path? It would have to parse the uses clauses and then look for those files in the search path directories - figuring out if a unit is actually being used because the compiler might find a dcu instead is left as in improvement. Share this post Link to post
dummzeuch 1517 Posted March 19, 2019 51 minutes ago, Stefan Glienke said: Please explain - what does the map file have to to with finding out units that are included in the project via search path? The map file lists all units that have been linked into the executable. So it is the easiest way to get a list of these units. Grep then uses the same algorithm as the Uses Clause Manager's identifier tab to find the source code for these units. That algorithm uses the project (as the first step) and all configured search paths (including the browsing path as the last step), so it should find the same source code as the compiler / linker does. Share this post Link to post
Stefan Glienke 2019 Posted March 19, 2019 Fair enough - I would have used a different approach though that does not involve having to compile the project by recursively collecting all used units by analyzing their uses clause. Share this post Link to post
Bill Meyer 337 Posted March 19, 2019 Collecting from the uses clauses will yield the list of all units referenced in the project modules, but parsing the map file is the simplest way I know to discover which units participate in the finished executable. 1 Share this post Link to post
Stefan Glienke 2019 Posted March 19, 2019 I am just saying that I dislike having to actually compile the project - maybe I just did a change that causes a compile error which is why I trigger the search ("what unit was this thingy in again...?" or similar). Sure I could have produced the mapfile before I do that change and then let it search it but I have the feeling this will be very inconvenient. Coworker of mine did an IDE plugin for us to automatically propose all the paths that some units referenced in the project are in to add to the search path so I know it's possible (yes, probably a bit more work than simply parsing the map file) Share this post Link to post
Edwin Yip 154 Posted March 20, 2019 11 hours ago, Stefan Glienke said: Coworker of mine did an IDE plugin for us to automatically propose all the paths that some units referenced in the project are in to add to the search path... Very interesting! That's something I thought of for several times in the past. Share this post Link to post