Iam using Delphi 2005 and i have included a unit to the main unit using compiler directive i.e.{$I sample.pas} whenever I try to build the main pas file I get the below error . F 1026 File not found and it shows the path where the sample.pas file is available. I tried different options like tried adding the path of the pas file in the project options- search path and also in the tools-options -library path and it doesnt work. I googled it and found a solution which says to do the following:
In the IDE from the main menu, navigate to
“Tools|Options|Environment Options|Compiling and Running”
switch “Show Commandline” ON
AND set sure you have “Verbosity” set to “Diagnostic”.
The problem is Iam using Delphi 2005 and unable to find the “Verbosity” option in Delphi 2005. It would be great if some one can help me
In Delphi 2009 it is right under the Show Commandline setting:
However, unfortunately for you the verbosity option isn't present in D2006, so I guess it was introduced in either 2007 or 2009.
Oh, and as far as the include directive goes: if your sample pas isn't in the same folder as the unit in which it is included, you could try adding the path to the $I directive:
{$I ..\..\General\sample.pas}
Put the file in the same folder as your project units, and change its extension to ".inc" ( not mandatory but I think that by convention directives files are named like this).
A possible solution could be to get the code working in a package and then have the package keep that part of things compiled. I have been able to use include files in other paths with packages, but it is quite tempermental. It can start rejecting them even with packages for reasons I don't know. This is indeed a VERY annoying problem.
You might also look into doing your builds via your own batch files where you can take full control of the command-line settings that are being used.
Related
I am trying to install a commercial component called JamShellBrowser but it will not install.
I have contacted the developer, but meanwhile I'd like to know:
What is a vrc file?
How is it produced?
Can it be controlled or modified with the Delphi XE4 IDE?
I checked the IDE's help but I could not find anything about vrc files and I searched for Delphi vrc and did not find anything that would help me.
The error message is:
Checking project dependencies...
Compiling JamShellDelphiXE4.dproj (Release, Win32)
brcc32 command line for "JamShellDelphiXE4.vrc"
c:\program files (x86)\embarcadero\rad studio\11.0\bin\cgrc.exe -c65001 JamShellDelphiXE4.vrc -foJamShellDelphiXE4.res
[BRCC32 Error] JamShellDelphiXE4.vrc(2): file not found: JamShellDelphiXE2_Icon.ico
Failed
Elapsed time: 00:00:00.1
I searched the components folders for an ico file, but there is none... thus the message, but even if I remove the line MAINICON ICON "JamShellDelphiXE2_Icon.ico" from the vrc file or even delete the vrc file it is automatically generated when I try to install.
I moved from Delphi 2010 to XE4 a few months ago and noticed the apparently new vrc file but I do not know what it is or how to handle these files.
A .vrc is a temporary file created by Delphi MSBuild process to compile resources files (.res) which will be linked in the final binary output. It is passed to CodeGear Resource Compiler/Binder (cgrc.exe) and deleted after the build process.
It doesn't appear anywhere in .dproj file. This behaviour is from BuildVersionResource target, imported from $(BDS)\Bin\CodeGear.Common.Targets. Look at this file (and at CodeGear.Delphi.Targets) if you want to get a better understanding of build process.
Removing <Icon_MainIcon> tag from .dproj it's not enough, as VERSIONINFO resources can also force the creation of .vrc file (I believe "vrc" stands for "Version Resource", although it is also used for main icon in applications).
In case of packages, Delphi always put version info in packages projects. The "include version information" IDE option is ignored with package projects.
So, if you (like me)
don't rely on Delphi IDE to set application main icon
don't rely on Delphi IDE to set version info resources; and
do manage to include your own resources files for everything
you can disable its creation entirely by setting the SkipResGeneration to true in your msbuild call. E.g.:
msbuild.exe myProject /t:Build /p:Config=Release /p:SkipResGeneration=true
However, this only works for MSBuild-based builds. I don't know how to do the same for builds from Delphi IDE.
Just open your #PROJECT#.dproj in any text editor file and find lines
<Icon_MainIcon>#PROJECT#_Icon.ico</Icon_MainIcon>
and delete them.
You will find one per Build target.
Save the file and you are done.
Edit: The original answer referred to the .dpr file, however note the section to edit is in the .dproj hence I've updated the the answer above to reflect this.
I believe this is a built in IDE behaviour of Delphi XE4 and XE5, possibly caused by an upgrade bug. Generation of VRC files is something that you can not disable except by removing the tags in the dproj file that cause it to be generated.
If there was a way to fix it or remove it, it might involve comparing your dproj file with another dproj file and looking for something that was appropriate only to a .dpr+.dproj Project that somehow got into your .dpk+.dproj project, like <Icon_MainIcon>.
It appears to be an intermediate file that is auto-generated when a .dpr+.dproj project has some version information which must be written out of the .dproj file, and into a temporary location and then compiled and linked into your application as a version info resource. However, I have also seen it get generated for a .dpk+.dproj project, and this mystifies me as well.
It also seems to contain a resource for your default application icon and version information, and packages do not normally have a versioninfo or application icon resource.
What I find to be possibly a BUG is that there is no UI in the Delphi IDE to let you set the Application Icon of a Package. Yet, I sometimes get a .VRC and an .ICO file. But I am not aware of a fix, other than to report the issue to Embarcadero Quality Central.
With a .dproj project, a .VRC intermediate file makes at least some sense. I see the following content: Version Info, Application Icon, and VCL Styles (ie AquaLightSlate.vsf) resource linkage.
this is a clarification...
I've just started to install several component libraries into Delphi RAD Studio XE5 that I've got installed in XE2 and XE4. When I try to Build most of them, I get this same error.
The problem isn't so much the .vrc file itself, it's this particular error:
[BRCC32 Error] <project_name>.vrc(2): file not found: <project_name>_Icon.ico
I can't figure out a way to bypass it, and I have no idea what it's looking for or where.
I tend to copy my component libs from one version to the next, opening them, building them, and installing them (ie. the ones that don't come with installers). I've never seen this happen in prior versions. However, this is the first time I've had RAD Studio installed; in the past I've just had Delphi. So perhaps it has something to do with having C++ installed as well?
I had to change my X.optset file to get this to work.
X being the name of your Delphi version you brought over these options from. Mine was PolyDelphiXE2.optset.
Once I corrected the name here no more funny compiling that brought in a different ico reference.
I want to create *.bpl file but I am failing to do so.
Specifically, I am trying to make JEDI plugins, but I have tried an empty pure Delphi package, too.
If I create a new package in Delphi XE3, I get an empty unit - if I "make" this project called "Package1.bpl", I get a .dcu file in "debug/win32/", but no .bpl file.
No error is reported by the compiler.
An empty JEDI plugin (bpl-style) only gives a .dcu, too, while an empty dll-style JEDI plugin gives a .cdu and a .dll file in "debug/win32/".
This is the first time I am trying to make a new package, so I am completely lost.
What am I missing?
Go to the Tools menu and navigate to Environment Options -> Delphi Options -> Library.
There you find the Package Output Directory and the DCP Output Directory. These directories are the default output directories for BPLs and DCPs, so the bpl will be created if your packages is compiled, but in a different directory from what you expect.
The JEDI plugins probably have their output directory configured otherwise in Project -> Options.
For those that don't want to travel into Delphi IDE/options etc, lately in Delphi XE it's something like this:
"C:\Users\Public\Documents\Embarcadero\Studio\17.0\Bpl;"
Your exact folder might be different based on 17.0
These folders also end up in the path environment variable of your system, bit dangerous and can lead to some mighty magic loading confusion ?!
"How's that BPL still loading after it was deleted from my local project folder ?" :)
Another solution is to add "." to your project settings without the "". Prevents you from having to modify your delphi environment options/settings, something you probably never want to do since JEDI and other projects may rely on these default settings to function properly. Only change it if you know what you are doing and how to correctly make JEDI and others work if it was changed, this may get tricky/hairy, probably requires search paths to be added.
IDE: Delphi 6 Professional.
We have big projects.
I cannot use Project Groups to build them all, because I got OM errors, and strange file errors when I did it.
My idea was that I will use DCC32.exe
Priorly I had a fight with the command line parameters (dcc32.cfg), but it I thought I solved it...
Today I tried to compile projects with it, but at first project I got errors.
chdir c:\d\anyproject
dcc32 -b any.dpr
The error reported me that it wasn't found a unit. I tried to compile in Delphi, and it was successful.
So I checked the problem. Why the previous project buildings were successful, and why this wasn't...?
Then I realized that this dpr is using references to a subdirectory, but not all files added to the project, more of them are linked by project's "search path".
But if it's true, then this meaning that DCC32 ISN'T USING THE PROJECT'S DOF/CFG FILES!
So the problem is that Delphi merges everything to provide the result.
It merges the global search paths, the project's compiler directives, the searching paths, so everything, and using the project's conditional directives too.
If I understand it well, the DCC32 don't use, only the dcc32.cfg, and I must merge everything for the compilation, what is an impossible job, because I need to write a parser what is interprets the project's parameters, and merges with globals.
Or I misunderstand something, and the problem is caused by other thing what I missed?
I waiting for your suggestions!
Thanks for all idea, link, info, etc.
dcc32 options from the following places:
A dcc32.cfg file. This can be either in the current directory, or the same directory as dcc32.exe.
The command line.
The source code.
I have order these in order of increasing precedence. So, an option specified in source code always overrides settings made a dcc32.cfg file, or on the command line.
dcc32.exe will choose whichever dcc32.cfg file it finds first. It looks in the current directory first.
What all this means is that you are responsible for getting the settings from the .dof file, and from the IDE into your command line compilation environment.
This is one of the many reasons why you should upgrade. Modern Delphi versions use msbuild for command line compilation and make it trivially easy to be sure that your command line builds are the same as IDE builds.
When you watch an msbuild in progress you will see that it results in a call to dcc32.exe with all options specified on the command line. Transforming the project settings into a call to dcc32.exe is what you are now faced with. In Delphi 6 you have to do that yourself. In modern Delphi, the tools are part of the product.
This might help:
http://delphi.wikia.com/wiki/Compile_from_Commandline
It describes how to do commanline compiles with Delphi versions from Delphi 1 to XE3 and also links to the tool dof2cfg which you might find helpful.
IIRC the command line compiler always uses a configuration file named dcc32.cfg found either in the current folder or where dcc32.exe resides. You may try to rename or copy your .cfg file to dcc32.cfg and see if that solves your problem.
First of all I would like to apologize for the question itself. I simply could not make anything better. Well, the question then follows with examples and detailed ...
I manually installed QuickReport Delphi 2006 from their sources. It is composed of two packages a "DesignTime" and a "RunTime".
My Delphi is configured to build the BPL files in "D:\BPL" and DCP files on "D:\DCP" for all packages compiled on my Delphi
The source code of QuickReport are in "D:\QuickReport" and their packages (design and runtime) are configured to save the compiled units (DCU) in the folder "D:\QuickReport\DCU." This was the only configuration done in the packages. Nothing is set up with different paths and, BPL and DCP files are placed correctly in the folders I've set up, as I mentioned earlier.
With these settings I was able to build and install QuickReport without problems (just a few compiler warnings, which I believe are normal). All QuickReport components appear in your palette in Delphi, which does not emit any error on start proving that the components are properly installed and all packages were found.
Now comes the test: I started a new win32 application, completely empty, just a blank form. Then it put a QuickReport component (TQuickRep). The first thing I noticed was that the unit "QuickRpt", which is automatically placed in the clause "uses" of the "interface" is underlined in red indicating that something is wrong.
When I perform a CTRL+ENTER in "QuickRpt" unit (uses clause), the Delphi finds the source file (.pas) correctly, which is in "D:\QuickReport" then I ran a BUILD ALL command and the following compilation error appeared:
[Pascal Fatal Error] Unit1.pas (7): F2051 Unit QuickRpt was compiled with a different version of QRExpr.TQREvElement
That's it!!!
This error is only happening with Quick Report. I have other third-party components installed using the same configuration as the paths and they all work properly.
Finally I was able to solve this problem. #RRUZ and another friend gave me the tip: An lost QuickRpt.dcu file on my system. There were a QuickRpt.res file also. I found them, but the place was very improbable to me: The delphi LIB folder!!!
Well, i have some clues about this bizarre thing.
Until Delphi 7, the QuickReport was shipped together with the IDE however, it was disabled by default. On that Delphi version, all we need to do is to register the bpl to gain full access to QuickReport!
On Delphi 2006, the QuickReport is not part of IDE and there are no BPL to register, however the guys at Borland forgotten to remove all files from the old QuickReport. The Delphi Lib Folder is one of the first folders to be checked on Delphi start, so, if there are old files there, new files on another place would be never compiled, generating the annoying error!
This problem may be present on Delphi 2005 too.
We have the following in our codebase, in a component file:
{$IFDEF ADO}
FDatabase : TADODatabase;
{$ELSE}
FDatabase : TODBCDatabase;
{$ENDIF}
The reason is that for various legacy applications, one or the other type of database connection and set of classes is to be used.
However, while configuring a new machine, it seems that our conditionals aren't taken into account. In the project settings, it says "ADO;DEBUG", and yet it compiles the above code with the odbc type instead.
The odd thing is that it isn't consistent. Two different units built as part of the same project uses separate settings. In other words, in one place our conditional is visible, in another it is not.
The file that compiles wrong does not have any {$UNDEF or similar directives, nor does it include any files.
What am I missing here?
Solved (ugh): Right, Delphi is just being boneheaded, or whatnot.
We found these:
I get “F1026 File not found”, OR some compiler options are not passed to the compiler from the IDE.
Configuration='Debug' Platform='BNB'
Which both mention the "Platform=BNB" setting. By enabling the diagnostic output, we see that exact value. So we try to override it per the articles, no luck, still BNB. Then we go to the project settings, turns out it can be overriden there as well, so we do that too, still no luck.
Turns out the Delphi installer, or whatnot, has added a "Platform=BNB" environment variable on operating system level, removing that, restarting Delphi, and all is well.
Well, as well as can be expected. We still have to use Delphi though.
You should always make a "build all" when you change those conditions.
It could be that one unit is actually not re-compiled. Check the following:
Is the .pas file included into the project?
Is there another file (.pas or .dcu) with the same name in the search path? It's possible the IDE sees a different file than the compiler.
Is the file actually compiled? Compare the timestamps of the .pas and the .dcu file.
Do you compile for another platform? Some compiler options are not passed unless the platform is "AnyCPU".
Whenever I encounter problems like this I brute-force delete every .dcu file in my project and component folders just in case the "Build all" doesn't remove all stale .dcus. The following recompile either solves the problem or reveals if any wrong .dcu was used.