I'd like to debug Lazarus library code. In Delphi IDE I would simply check the Project Options -> Compiler -> Use Debug DCUs option on. Is there something similar in Lazarus?
Yes and no. It roughly works the same as in Delphi, you need two sets of the compiled units. (.o/.ppu), and some way to switch.
But because FPC/Lazarus are open source, only one set (the one without) is distributed. But you can craft the other byrecompile FPC and Lazarus with -gl. For tips on recompiling FPC/Lazarus see http://www.stack.nl/~marcov/buildfaq.pdf
(it is even possible to do combinations. I debug many of my applications with everything debug except systems and sysutils, so that I don't trace into each and every string and exception helper, a major annoyance on Delphi)
Currently the releases afaik don't distribute the duplicate sets, but this is more a release engineering problem. (specially since by using strip, the non-debug set can be probably crafted from the debug set)
BTW, it might be worth the trouble to ask on the Lazarus maillist if such way exists. Even if the release doesn't set it up, there might still be a possibility that the functionality exists.
Related
Background: as D7 is now officially unsupported, I'm trying to create a definitive stable and fast D7 Pro development environment, with all fixes applied directly to the source code instead of complicated patching or adding units to every project.
Borland did provide a makefile for the RTL dcu files, but even that does not produce the same size files as the official ones.
I'm wondering whether something is wrong with my setup. As an aside, what is the recommended way of creating the initial development environment now? I thought the best option would be to start afresh by downloading D7Pro and the update 7.1 from cc.embarcadero.com.
To the very best of my knowledge, the VCL is expected to be compiled with default compiler settings. Any variations to that are specified explicitly in the source code.
Of course there are debug and release versions. The former does not have optimizations enabled, the latter does.
There are some special requirements for the very low level RTL units but judging from what you say in the question, you are on top of that.
You are concerned that you will encounter the unit compiled against different version of XXX errors. But that will not occur since, as I understand it, you will be compiling the entire RTL and VCL.
Even if you re-compile piecemeal just the units that you modify, you will have no problems so long as you use default compiler options. Of course, you would have to refrain from making changes to the interface section of any unit in that case.
And even if you compile piecemeal you have to understand that there are some compiler options that have no influence on whether or not the .dcu files are compatible with others. A good example is optimisation.
I do wonder whether or not you are doing this needlessly. It sounds like you have a working solution. And nothing has changed recently. Delphi 7 updates dried up a decade ago. Why do you feel compelled to change now?
I have upgraded a project from RAD Studio 2010 to RAD Studio XE4. The project is mostly C++ using the C++ Builder half of RAD Studio, with smatterings of Delphi.
Under 2010, the Release build was 22MB. Under XE4, the same Release build is 55MB.
This is a problem because:
55MB is remarkably large for an EXE
It takes noticeably longer to start the program (not much, but some.)
Many of our customers download new versions from remote areas or on board ship while at sea. Size matters.
What could cause this, and how do I fix it?
Notes
Oddly enough, the debug build is still only 23MB. Project settings seem very similar. I diffed an export of the option sets and saw only <UsePackages>True</UsePackages> as something present in Release not Debug; removing it made no difference. Beyond that there's code optimisation turned on and lack of a _DEBUG define.
Debug info is generated for the Release build, but goes into an external .tds file. (This will be used for EurekaLog in future, and currently allows us to debug release builds of the program.) I wondered if the linker was linking in debug info, but as far as I know the C++ linker always places the debug info in an external file, which exists, plus EurekaLog is not yet enabled in the build.
The project files (.cbproj) were created in XE4, not upgraded from old 2010 ones. I made new projects and added the old .cpp and .pas files. This was to avoid issues caused by upgrading - on the Embarcadero forums it's often recommended to create projects anew when upgrading IDE versions. Until this occurred, I had indeed encountered fewer issues than in 2010.
There are many mentions of Delphi XE2+ EXEs being noticeably larger than those produced by old versions of Delphi. (1, 2, 3, 4, 5, 6.) While the C++ linker is different to that used by Delphi, it is possible the causes are similar.
The cause there appears to mostly be RTTI used by the Delphi RTL code, which in a Delphi project can be removed by specifying {$WEAKLINKRTTI ON}. The XE4 documentation does not mention an equivalent C++ linker pragma. There is #pragma explicit_rtti (the C++ analog of {$RTTI}) and __declspec(delphirtti) (the C++ analog of {$M}/{$TYPEINFO}).
The project is linked using runtime packages and the dynamic RTL. It is a 32-bit VCL forms application. I have XE4 Update 1 installed on Windows 7.
Edit: David Heffernan asks in a comment below about the .map file sizes of each project.
The release .map size is 17MB, and .tds size is 80MB.
Debug has now stopped linking, with the linker reporting it is out of memory (an old, old bug that should have been fixed years ago.) There are no .map or .tds files generated and so I can't give a comparison size accurately. From memory the .tds was about 100MB, and unfortunately I don't recall the .map size. If I get the project linking I will update the question.
Edit again: I found the answer (sortof) - turning 'Expand inline functions' OFF reduces the EXE size to the expected value. This is puzzling itself though - see my answer below. Note that the debug build already had this turned off and still won't link, giving an out of memory error.
I haven't marked my answer as correct yet, in case someone can provide some insight into exactly what is going on, which would be a much better answer than just 'turn this option off'.
Solved (sortof.)
The Release build had "Expand inline functions" turned on. Turning this off reduced the EXE size from 55MB to 17MB.
This is an astounding difference and I don't know why the difference is so big. I find it unlikely we have 38MB worth of inlined functions, even counting templates and headers, let alone ones using the inline keyword. If there is a way to examine the linker steps, output, or obj files to see what is being expanded, please comment - I'd find this really valuable.
How to automatically remove unused units from uses section on all source files of the project on Delphi XE2?
P.S. IDE will work much faster after that.
There is no way to fully automate this.
There are a few tools I'm aware of that take a wizard approach:
CnPack Uses Units Cleaner
Peganza's Pascal Analyzer (and it's sidekick icarus).
The Lazarus IDE has a "Unused Units" dialog in it's CodeTools package.
Peganza's tools simply show a report. CnPack will prompt to remove the unused units for you but you must confirm. Lazarus presents you with a list of unit's it thinks are unused and gives you the choice of removing some or all of them.
Why isn't it automated?
Because this is static analysis. Even the most sophisticated tools cannot determine with 100% certainty whether a specific line of code will be used at runtime let alone an entire unit. These tools have implemented their own parsers to accomplish this feat but they aren't fool proof.
In any case the main benefit of cleaning up the uses clause is removing visual clutter from both the source itself and the code completion feature. Yes there is some performance gained during compiling and certain IDE background operations will speed up slightly but I think you'll be disappointed if you think the IDE will miraculously speed up.
You'll see better IDE and compiler performance by:
Breaking your projects into smaller pieces that can be worked on independently.
Eliminating duplicate code.
Disabling unneeded IDE packages.
I'm certainly not trying to dissuade you from removing unused unit references. As I said it will help unclutter your source. Just make sure you're doing it for the right reasons.
We have a utility called the Delphi Unit Dependency Scanner (DUDS). It scans your entire project and builds a fully searchable tree of the units and dependencies. It can be very useful in finding unused units.
The application is Freeware and you can find it here.
Disclaimer-I am the author.
Don't think I would want a tool that would automatically rip out unnecessary units in the Uses section...
but there are tools out there to identify them...look at Icarus...freeware that you can get at http://www.peganza.com/downloads.htm
CnPack has "Use Cleaner..." option that I have used unit by unit basis without a problem. It also has the ability to do the entire project - which I haven't tried due to the size of the project.
Use reFind.exe utility provided since Delphi XE, use this command
reFind *.pas /X:unuse.txt
And unuse.txt is a text file with something like this:
#unuse Unit1
#unuse Unit2
#unuse Unit3
And that's it. It will remove the units in the uses clause taking care if the unit is the last one used and there is a ; after the unit.
In a legacy application (created in Delphi 6 under WinXP in 32-bit, recently ported to Delphi XE2 under Win7 in 64-bit) at design time, the standard controls look "modern", with color gradients etc. In run-time though, they look just like an old Win95 version.
That would not bother me much if, in particular, the default colors in TPageControl and TTabControl wouldn't make it really difficult to tell which tab is currently selected.
So my questions are:
What could make the theme not active at run time?
Is it possible to easily (e.g. through IDE configuration) make the design time look like the run time?
Note:
In the project options, I enabled runtime themes for each existing target. It didn't help.
I also tried to enable GlassFrame in the forms containing those controls. Unfortunately, the runtime look and feel stayed unthemed.
This application is built on a lot of in-house and external code that
I don't master (just a dwarf standing on shoulders of giants),
but whose source are available to me. Suspecting that some
instruction would disable themes at application startup, I looked for
some keywords like "Theme", "Skin", "TStyleManager", "SetWindowTheme"
hoping to solve this by myself. I could not find anything significant (to me, at least).
I tried to skin a small application as a test, using infos from
Question
Delphi XE2 VCL styles tutorial - how to change the style at runtime,
and it worked perfectly.
Skinning my application is not my goal. I just would like to be able to visually tune some GUI elements at design time, and it is easier if design and run time look alike.
It turns out that removing the line "{$R *.res}" in the dpr file had made the themes unavailable.
Under D6, I disabled version information in the project and replaced "{$R *.res}" with "{$R 'myApp.res' 'myApp.rc'}", to use my own rc file to have the version information in a separate, easy to edit file, and not to be forced to go through the project options.
Under XE2, that did not work anymore because the resource would often be overwritten (or not taken into account, I'm not quite sure) by Delphi during the build. I had to rename the rc file so that it does not match the application name, thus replacing "{$R 'myApp.res' 'myApp.rc'}" with "{$R 'myApp_rc.res' 'myApp_rc.rc'}".
Putting the "{$R *.res}" again (along with "{$R 'myApp.res' 'myApp.rc'}") seems to make things right with themes and not break the version information.
Thank you Brian for having me look in the good direction.
In my experience this is often due to project differences between DEBUG mode (used by default when in the IDE) and RELEASE mode. Open your project options and scroll to application (where themes styles and icon are defined). Notice that the platform and build option combo at the top holds separate values for each setting and I expect you will find that your DEBUG build config has runtime themes enabled but RELEASE does not.
I'm experiencing problems with debugging in Delphi 2009's IDE. Since having moved old projects that had been created using Delphi 7 to this version, all breakpoints except for those in one unit are neglected. I couldn't figure out which unit that is, but that seems to change from time to time.
Enabling debug DCU's overcomes this phenomena, but I don't want to step inside RTL/VCL units. Only those used by my project, like the Version 7 IDE did with standard settings.
Chances are when you first moved the project to D2009 you built your units without debug info. Now that those units have been created, they don't get rebuilt every time. What you are probably seeing is that the breakpoint only works in the unit you're currently editing and making changes to. This is consistent with the fact that the compiler knows to rebuild that unit (with the now properly set debug flags), and that unit only.
The solution is the make sure the Debug configuration is selected and then do a full build.
Delphi 2009 comes with different build configurations. Make sure you've got Debug build mode set, not Release mode, and that the debug compile option is turned on.