I am currently working with 'inherited' code that has (scattered randomly throughout) a whole bunch of conditional compiler directives based on the version of Delphi, going back to Delphi 2 . From now on, all development will be with Delphi 2009 or future. Is there a tool in Delphi 2009 , or a plugin, that will automatically remove compiler conditional code segments based on a specified 'minimum' version?
I highly recommend the Delphi Inspiration Pascal Preprocessor (DIPP)
This can do a number of things with a source file in addition to removing conditional defines, including the "inlining" of include files and removing comments (all of course highly configurable and controllable by options supplied to the processor).
The conditional defines functionality is especially useful as you can either have all such conditionals simply removed or provide a set of DEFINE's that you wish to apply. DIPP will then emit a source file that reflects how it would appear to the compiler with those symbols DEFINED, but without the conditional directives themselves.
So in your case you would simply defined the symbols appropriate to your "baseline" Delphi version.
You should give JEDI PreProcessor (Pascal PreProcessor) in the JCL a try.
In the trunk in our SVN the source can be found in the dir jcl/devtools/jpp and in our latest release (2.1) zip-file the jpp.exe can be found in the dir devtools.
I don't know of such a tool but it should be relatively straight-forward to write it.
Loop through all files in the directory using FindFirst and FindNext
Use TStringList.LoadFromFile to read all pas files.
Loop through the strings and look for {$IfDef} directives. If the version specified in the conditional section is older than D2009 remove all text until the {$EndIf}.
Use TStringList.SaveToFile to write the modified file to disk.
My advice would be to ONLY change code you completely manage. If however you are also going to modify existing 3rd party code, then I suggest you go through each IFDEF defined for validation. Some vendors do not use the standard IFDEF VERxxx calls, but create their own which might be called something like VER70UP or such. The most common place for this would be in include files, so look for a {$I ???.INC} file near the beginning of each file, then analyze this for what is being used and how.
The other reason to analyze each $DEFINE/$UNDEF is the fact that a version specific one might turn on a new define that your previously not checking...one that ultimately leads into dead code.
Use GExperts, you can use both GrepSearch or GrepRegularExpressions to search in your code and then use the Replace tool in the GrepResults to remove whatever you need.
You can do a search and replace
operation on all of the matches in the
list or only the selected file/match.
When you choose one of those options,
a dialog appears prompting for the
string to use in place of the matched
text. Note that forms that are
currently open can not have their text
replaced, due to limitations in the
IDE. Please close all forms before
trying to replace text in them.
Related
Just upgraded from Delphi XE to Tokyo, and was hoping for some updated IDE features.
One nice to have feature would be automatically providing options to add a unit to the uses clause. For example, if you reference something in code that isn't in a uses, it would be nice if the IDE prompted you to add the related unit(s).
For example, keeping it simple, in IntelliJ, you might declare a Button, but not yet have added the associated Library to the Import clause.
When this happens, the offending line is highlighted (just like in Delphi), but the IDE will let you add the necessary library with an Alt-Enter. If there are multiple libraries (it knows about it) it will prompt you for the one you want.
Anything like this for Delphi?
Delphi 2007 and later versions support this for most types that it knows about (in the search or library path). (It may have been available in D2005/2006; I don't have them installed anywhere now to check. I know it was not in Delphi 7.)
Put in the type, and use the Refactor menu (Refactor->Find Unit) or press Ctrl+Shift+A.
Here's an example:
It's not 100% effective, but it's a vast improvement over the old way.
(And yes, I know about TArray<string>, before someone chimes in. I just grabbed a quick type that I knew wouldn't be in the default VCL form uses clause for an example.)
I have this craving to do some experiments with modifying the underbelly of the Delphi run time library (RTL), system.pas and the likes... It is possible or not?
I'm very fond of challenges like "yes, but you'll have to provide custom .obj files for some assembler wizardry because they were never distributed with the official Delphi source". Fine with me, I just want to know.
I want to do this experiment with Delphi 7, but inside information on any other version is fine. It is one of the perks of being with a company that worked with Delphi since the Stone Age.
(I always figured this to be one of those RTFM questions, with the answer being a resounding "NO!", but for some reason google won't confirm it.)
You can recompile the RTL like any other unit.
For System.pas you must use the command line compiler.
For instance, here is a working batch file content (there is some not well documented command line switches):
del *.dcu /s
"c:\program files\borland\delphi7\bin\dcc32.exe" -O+ -Q -M -Y -Z -$D+ System.pas
This will recompile System.pas and SysInit.pas (both lowest level RTL files).
But in order to use your recreated dcu files, you'll have to put the folder containing the updated dcu files into the first position of your IDE: for instance, in Delphi 7 it's Option / Environment Options / Library, then put your folder FIRST in both "Libary path" and "Browsing path" field.
And it's perhaps worth deleting the original .dcu files in your Delphi installation directory.
But be sure you won't change the "interface" part of the unit, or you'll have troubles with compiling with other not modified units of the RTL (or third-party components). You can change the "implementation" part, apply fixes or rewrite some part for speed or such, but don't change the "interface" part to avoid any linking error.
Always make a backup of the original .pas and .dcu files which you are changing. And it's a good idea to make some automated compilation test, so that you could be sure that your modifications of the RTL won't add any regression.
We made such a RTL recompilation for our Enhanced Run Time Library for better speed of low-level RTL functions (mostly System.pas and SysUtils.pas). Designed for Delphi 7 and 2007. For more recent Delphi version, you still can use the same principle.
You can only recompile the RTL from the command-line. There should be a makefile in the RTL source directory of your installation. It is designed to be used with the make.exe command-line utility which should be in the "bin" folder of your installation. I would recommend you copy the relevant sources to a separate location for experimentation. I must caution you that the System unit is tightly coupled with the compiler which expects many functions to have a specific name and have particular parameter lists, if any are even declared. Many RTL "helper" functions don't have any formally declared parameters, yet expect parameters to be passed in a certain fashion.
Another bit of caution is changing the interface declarations of certain classes, functions or types. Doing so may cause serious incompatibilities with existing DCU files and components. For this reason you must be very careful when intermixing DCU files from the included RTL or third-party components with your custom modified versions. I would suggest you start by only making implementation section changes only before venturing into the mine-field of interface breaking changes.
I need (to make some quick and dirty tests) to modify the code of Variants and SysUtils.
What I need to do to "compile" the changes?
I can of course open those units in the IDE, but if I change them and I buoild a project again I don't see those units recompiled.
What is needed to be done?
The problem is you would need to compile ALL of the RTL/VCL against the 'new' units.
Instead modify a copy of the units in question and add them to your project when you want to use them. Delphi should use these over those in the RTL/VCL.
Unless you do not change the interface part of the unit (that is, you only modify the implementation side), you can make your own version of the RTL units (only exception is System.pas and SysInit.pas, but this is not in your scope - see our blog site for some enhancements of those units).
What you need is to put your own version of Variants.pas and SysUtils.pas in the search path of your project. They will be taken in account instead of the default RTL.
But be aware that you may easily break anything.
For testing purpose, this is OK, but if you want to use those modifications, you shall better use some automated regression tests, and know explicitly what you are doing.
Please note that you can use the "debug" version of the RTL units (from the project options), then step with the debugger within the official source code. It may help finding issues without touching the source.
If you change the interface part of the unit, you'll have to recompile all units which call the modified unit - for SysUtils and Variants, this is almost all RTL.
Delphi runtime DCUs are precompiled. It would be a waste of time to compile them at every build.
If the code you are trying to modify is a method of a built-in class, then a class helper may help:
http://docwiki.embarcadero.com/RADStudio/en/Class_and_Record_Helpers
So the question is which part of code do you want to modify in the runtime?
If you really wish to recompile the RTL you can do so (Make a backup first!). Versions of Delphi prior to Delphi 2010 had a makefile in the source folder that could be run from the command line to rebuild the rtl/vcl. I don't know for sure (I'm still using D2009) but from what I've heard this file is no longer present in newer versions. Hopefully there is an alternative. Otherwise you would wind up wasting a lot of time trying to guess that the compiler settings for each unit.
If you wish to "patch" a bug in the rtl for your project only you can copy the unit you want to modify into your project's folder and make your change. If the unit your modifying is used throughout the RTL/VCL you may find yourself copying quite a few dependent units into your project folder in order for it to compile.
If this significantly slows down the compile time for your project you can always do your initial compile then remove the "patched" units, leaving behind the compiled dcus.
The Delphi project I'm working on requires me to create a very large type library in order to add COM support. The problem is with the type library/ridl editor in Delphi is that it becomes difficult to manage (from a programmer point of view) such a large file, and I'd like to split it along functional lines. The problem I have is that I cannot see a way to include one ridl file in another. I'm aware of the importlib function, but I also cannot find a way to create more than one type library in the same project, or create a tlb file from within delphi. Can anyone give me ideas on how to better manage this?
Standard IDL has an include statement for pulling in other files into the TypeLibrary compilation. RIDL stands for REDUCED IDL, so it might not support it, though. You will have to try it and see.
It's easy enough to find all your external dependencies. Just run the program and open up the Modules info window. But how can I find all my internal dependencies? I know the program keeps a list of all the units, because I've traced my way through the initialization code a time or two. But is there any easy way to access this list from the debugger?
The Delphi debugger can show you which units were compiled into a module (exe, dll or package). You can see this in the Modules view (View | Debug Windows | Modules). Click on a module in the upper left pane, and the lower left pane will show all the compilation units that were built into that module. If a particular compilation unit was made up of multiple source files (i.e a .pas and a .inc file), that will be shown too (when you expand the comp unit).
Alternatively, you can have the Delphi compiler show you a list of used .dcus by passing --depends when you compile a project. It will output a .d file with a list of the .dcus (and .dcps) that were required.
Another, but rather cumbersome way, is to generate a map file, it contains a list of all units used in a program.
see also this answer:
How can I find all the units in my Delphi app?
I use the GExperts Project Dependencies.
With the "Used By...", you can see units included but not used by anyone.
But you can't see unit included in uses clauses that could be removed when they don't have any code actually called.
Here's the help:
Project Dependencies
The project dependency expert enables you to see what units a particular unit uses, and in turn what units use a particular unit. When this expert is activated, it parses all of the current project's source code for uses clauses and builds up a list of dependencies. To view the dependency information for a particular unit, click on it in the left pane. The right pane will contain the dependency information. Indirect dependencies are units that are used by used units of a particular unit.
You can refresh the dependency information at any time by clicking the refresh button on the toolbar and you can sort the file listing by clicking on the column headers.
(source: gexperts.org)
OTOH, you can also use free Peganza's ICARUS as a more detailed reporting tool but less interactive...
Have you looked at Pascal Analyzer or the free limited version, Icarus, from Peganza Software? They will create "uses reports" telling you what module uses what others, so that should give you the info you're after.
Marc
GExperts has a Project Dependencies tool. I have used it before when trying to track down used units. You can't search in it but you can export the list to a CSV file and search there. This also only lists what is in the uses section. If you have a module included that is not being used it will still show up.
I know of at least two ways you could try to get a view of all the units used in your project
CTRL-SHIFT-B opens the object browser. If I'm not mistaken, here you can get a view of used units. I'm not entirely sure about this method and don't have Delphi available to verify it.
Use Modelmaker; Modelmaker can give you a tree like view of all your unit dependancies. Look at the Visualizing existing code section for more information.
The easiest way is to compile program and check which .dcu was created by compiler. Make sure to setup compiler to create .dcu in a separate directory, for example c:\dcu. I have created simple utility that searches .pas for every .dcu file in directories that are in a compiler search path (that can be read from .cfg, .dof or .bdsproject file).
You can use a MAP file in conjunction with MapFileStats, this will not just give you all your dependencies, but the amount of code (and resources) they contribute in the final executable.
Useful to spot units you have dependencies to, but use little of, as well as spotting "fat hog" units, which take everything plus the kitchen sink with them.
FWIW, reducing dependencies and eliminating hogs isn't just beneficial to executable size, it's also beneficial down the road when it'll be time to upgrade to a new version.
There is a (rather old) utility called UsgParse. It builds a treeview of all units referenced by a project.
I found a copy on the NexusDB site via
http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.thirdpartytools.general/2004-03/0231.html
source: http://www.nexusdb.com/downloads/USGParse/USGParse_src.zip
binary: http://www.nexusdb.com/downloads/USGParse/USGParse.zip