This is a tool I created to use on my own projects - it’s a simple tool that works out what files are included, where they are and included and why. Yes the map file tells you what is compiled in, but it doesn’t tell you why or how a file was included.
In my case I was working on a console application that absolutely cannot link any vcl or fmx units - because I need it to run inside a windows container - the vcl statically links to parts of windows that are not present in the stripped down version of windows that runs in containers.
This tool helped me figure out what a simple grep didn’t.
I added the check command to the build process so that the issues doesn’t sneak back in again.
Signed precompiled binary under releases - or build it from source - use dpm to install the dependencies required.
@vincent umm have you been reading my secret emails to @ianbarker ? This is my biggest pain point when I start on a new project for a client with a codebase that’s a mess!
I was sure I had seen a tool around somewhere that did what I wanted - but I couldn’t find it - so an hour or so with claude gave me what I wanted, and it solved the problem I was having.
Third party libraries that are non visual yet link to the vcl is a major bug bear of mine.
I see that you code starts off by going through the uses statements in the dpr to get a list of pas files that are compiled.
what about units that are not in the dpr but are still compiled?
I may be wrong but it seems to me that, when compiling a unit, if a required dcu cannot be found but a pas file is found delphi will compile that pas file as well.
It looks at the uses clauses of the units included in the dpr and then drills down into those unit’s uses etc - and then uses the search/library path etc. I tried to get it to act like the compiler would when locating units. I verified it against the FinalBuilder source code (2K+ units not including third party) and verified that it found every unit.
Edit - for a unit to be included in a project, it has to be used - so even units not in the dpr are found using search paths. The readme could probably do with some clarification.
@vincent You mentioned remembering a tool that had some uses features. I haven’t looked at your tool (it sounds useful) so I don’t know what overlaps but there are a couple of other tools that I have installed with similar sounding features:
Project Dependencies in GExperts reports uses for units included in the project file (explicitly compiled) as well as all units in uses clauses (implicitly compiled), has a reverse “what units use this unit” feature as well
cnPack has a tool to list used units for the currently open unit, add a unit to the uses list from a list of all units found in all folders used in the project and included in the search and library paths, a uses cleaner, show uses initialization order, find uses units for identifiers (see which unit an identifier is declared in), and a bulk add a unit to uses in all units.
For anyone reading - both of these IDE plugins contain a bunch of other useful features - recommended.
Aha, couldn’t see the wood for the trees - I use GExperts and that is probably what I was thinking of.
One thing my tool does that an IDE plugin can’t is provide a build time gate - I have it setup in CI to fail the build if a vcl unit gets added to the project anywhere - happens surprisingly often with third party libs.
I can also save snapshots and compare before/after changes. It also detects circular references - e.g.
