I need
understand how work some(5-6) exported function - for easy codejumping
if code base is full I build it -and using browsing
but code base not full so compiling fail.
one road from many: add proxy unit wich include all proxed(thouse that implimentation I not have)(by hands or part auto) function,type,const,ets THEN build as full - that path 1.
may be exist tool that can linked all source and gen some output(html or other -not is defined) for jumping in code from using some identificator to it definition and vica-versa?
UPD1. find Ctags,OpenCTags for Notepad++ . All is good, only one silly little mis: jump to interfase part of defenition , but I wonna to implimentation part (for C/C++ it like goto .h and not to .c/.cpp) any help?
I think you're asking about a pascal dependency analyzer, such as Peganza, discussed here:
Tool that shows unit dependencies for Delphi 2010 or Delphi 7 program
Related
One of the project we are currently working on uses a static objective-c library created by an ex employee.
The problem we have is that the library was built for arm7 which has 32 bit architecture. Is there a way to recompile for new architecture. It seems like a long shot though.
___Edited I don't have the source code.
Do you have the source code and Xcode project? If so, the answer is yes. As mah says, you may have to refactor the project for the latest IDE.
If you don't have the source code then the answer is a resounding "NO!" Compiling means converting source code into machine code. No source code = nothing to compile. You might be able to analyze the machine code and reverse-engineer it, but that's a horrific amount of work.
Delphi 10 Seattle introduces Winapi.Security.pas. The project (a package) I'm trying to upgrade already has a Security.pas file. Short of removing Winapi from the list of scope names for the project (huge undesirable ripple effect), is there a way to tell the IDE and compiler to use the project's Security.pas file instead of Winapi.Security.pas?
I already tried renaming the projects Security.pas, but that caused even more problems with the compiler generating errors that have nothing to do with the code it was complaining about, so that's a rathole I'd rather not go down right now. This project builds just fine unchanged in XE7, FWIW, so this isn't due to any code changes in the project.
Updates:
Renaming the file and using a unit alias doesn't work.
The compiler behavior for a package differs from an application.
Looks like this might actually be related to the Winapi.Security unit rather than something as generic as you suggest in the question. For instance, the following package compiles just fine:
package Package1;
requires
rtl;
contains
Windows in 'Windows.pas'; // blank unit named Windows.pas in project folder
end.
Note that I have, like you, included Winapi in the project's list of unit scope names.
On the other hand, this package does not compile:
package Package1;
requires
rtl;
contains
Security in 'Security.pas'; // blank unit named Security.pas in project folder
end.
The compiler fails with:
[dcc32 Error] Package1.dpk(7): E2200 Package 'rtl' already contains unit 'Winapi.Security'
If the issue was purely related to unit scope names then either both packages would compile, or both would fail. Hence my conclusion that there is something out of whack with Winapi.Security.
I can find no source code for Winapi.Security. I wonder what it actually is. [Nicholas Ring located the source for me, inside the rtl\win\winrt directory.]
Anyway, I think it's time to submit a QP report. The package below that fails to compile is probably the starting point for that QP report. [Your submitted report is here RSP-12469.]
It seems clear to me that in the short term you must rename your unit if you wish to adopt Seattle.
FWIW, here are some other units that behave the same way as Winapi.Security:
Winapi.ApplicationModel
Winapi.CommonTypes
Winapi.Devices
Winapi.Foundation
Winapi.Gaming
Winapi.Globalization
Winapi.GraphicsRT
Winapi.Management
Winapi.Media
Winapi.Networking
Winapi.Storage
Winapi.UI
Winapi.WebRT
These are all newly added WinRT units which I expect is important.
If you put both Winapi.Security and your local Security in the same uses clause then you are able to access the members of both of them without issue. If you put them in separate uses clauses (Interface vs. Implementation) then you will get the error:
E2004 Identifier redeclared: 'Winapi.Security'
If I only include Security.pas in the uses clause (and it is included in the project) then it accesses its members just fine.
Perhaps I need more information about what error you are running into? I'll send you a sample project that shows this working.
I might well be wrong, but I believe that if Security.pas is in the uses clause of the dpr file, along with its full path, it will be preferred over whichever file can be found via the namespaces and search paths.
Open project settings, in the Delphi Compiler section remove "Winapi" from "Unit scope names".
This way, when you need the Security unit shipped with Delphi, you'll have to write Winapi.Security, and if you write Security, it will use your custom Security unit.
I am aware that there are already other questions on the topic, such as:
This one
This one
This other one
.. but hey, I am new to F# and still don't get it.
I have a F# project (thelibrary) which contains some modules. This project references in the solution explorer all the necessary libraries. Each .fs file opens the libraries used in the module. The F# project compiles properly.
I have then another F# project which contains a script. I reference thelibrary and the libraries used by thelibrary itself. In the script I reference with #r the dll with thelibrary and all the libraries used by thelibrary. I then open all the modules.
Intellisense says all is allright until I execute the script.
The script returns the error:
error FS0074: The type referenced through 'Fmat.Numerics.Matrix`2' is defined in an assembly that is not referenced. You must add a reference to assembly 'Fmat.Numerics'.
What is the procedure to hack this problem? How do I proceed from there?
I am interested is a solution to this specific problem but, as well, a cookbook recipe to fix this type of issues that have been quite a source of frustration for me.
Thank you.
The behavior of F# Interactive can be a bit odd in this case. In general, I think that things work better when you use #I to include the path with referenced assemblies in the resolution context and then reference the libraries by name using #r. So if you have a library Fmat.Numerics.dll in a folder C:\libs and it references another library another.dll then you can do:
#I "C:\\libs"
#r "another.dll"
#r "Fmat.Numerics.dll`
The first line means that F# Interactive will automatically look in the folder with your libraries (this can be relative path to your script location too) - as a result, the next two lines can just reference the libraries by their file names.
This is still a problem. I can also reproduce and fix the problem as follows:
I have three projects:
Informedica.Settings.Library
Informedica.Settings.Services.Interfaces
Informedica.Settings.Services.Models
Project 2 uses project 1 and project 3. Project 1 uses project 3.
When I load the references in the order (first proj 3 then proj 1):
#r #"..\..\Informedica.Settings.Services.Models\bin\Release\Informedica.Settings.Services.Models.dll"
#r #"..\..\Informedica.Settings.Library\bin\Release\Informedica.Settings.Library.dll"
Everything works. Unfortunately, when I use the VS2013 send references to fsi or use the new power tools generate references option, the order is:
#r #"..\..\Informedica.Settings.Library\bin\Release\Informedica.Settings.Library.dll"
#r #"..\..\Informedica.Settings.Services.Models\bin\Release\Informedica.Settings.Services.Models.dll"
This will result in the FS0074 error. Apparently, because a type from Services.Models is used in Settings.Library and the order of reference is reversed, fsi cannot handle this. Correcting the order of referencing solves the problem.
Running things in fsi does not add references from the project, you need to use #r .... The error message is reasonably obvious in what you need to do - add a reference to Fmat.Numerics. It is also possible that you have such a reference, but that fsi is sensitive to the load order.
I'm currently porting a rather big project from C++ Builder 5 to the newest version, C++ Builder XE. It's my first experience with C++ Builder. I'm stuck with an error in a file, but I don't want to include this file anyway (it's code of a component not required anymore). I was not able to find out where and how this file is included, however. The compiler error does not give any hint at all apart from the error itself. How do you usually find out where a file is included?
The preprocessor is perfect for this. Right click on the cpp file which gives you the error in the project manager then choose "preprocess"
The output from this tells you every file and line number in the order they are processed. You can then search for the file in question, and the line above it is the file that included it.
This could conceivably be another header file as well, so it could be a long chain, but you can determine exactly where it comes from.
In the Project Options, enable the compiler's general messages. When the compiler encounters an error, you will be able to see the chain of includes that lead to the erroneous code.
If the files in question are rather sizable, a tool like Doxygen can be helpful in showing you the include dependencies (as well as call paths, etc.).
If it's just once or twice you'll have to do this, David Dean's suggestion of the preprocessor is golden.
I'm building a program that uses plugins. Unfortunately, the plugin framework's dynamic linking forces the RTL and VCL out of my project EXE and into the BPL versions, and they don't have debug info enabled.
So I built a testing framework that links to my plugins statically so I can actually see what I'm doing while tracing through the code. But now, every time I try to recompile, I get an error: "unit turbu_skills was compiled with a different version of turbu_database.GDatabase"
I've seen this error before, but only when I've been changing things I probably shouldn't have been, like the RTL or VCL libraries. I don't understand why it's doing that with my own code. The turbu_skills and turbu_database units are both units I wrote myself. GDatabase is a global singleton variable, whose class definition I haven't changed in weeks. Any change that triggers a recompile causes this error, even if I haven't touched anything in either of the units.
Doing a full build (SHIFT-F9) causes it to compile correctly. But if I then press SPACE in a unit (any unit) and hit F9, I get the error again. What's going on and how do I stop it? This doesn't happen in the main app, only the testing framework.
EDIT: I have the source to all of my units. Deleting DCUs and similar files doesn't help. Copying the entire project to a different computer, deleting all DCUs, and building there doesn't help. There's an objective, reproducible conflict between the layout of my program and the compiler, and I want to be rid of it.
The source can be found at http://www.turbu-rpg.com/downloads/Turbu_source_setup.exe if anyone wants to test it. It requires Delphi 2009 with the JVCL already installed; the installer package will take care of the rest. Maybe having the source code available will help someone track this down. I certainly hope so, because wherever the issue is, it's beyond me. The problem can be found in testing.exe and also in turbu.exe in turbu.groupproj.
EDIT 2: Turns out this was another cross-unit generics issue. Grr. I managed to code a workaround. I just hope they get the generics problems fixed soon.
The error "unit is compiled with a different version of..." is an annoying one. It occurs in a situation like below:
+--------+
| unit A |
+--------+
| |
| |
V |
+--------+ |
| unit B | |
+--------+ |
| |
| |
V V
+--------+
| unit C |
+--------+
Both unit A and B use unit C and unit B uses C. Unit B and C are compiled and for some reason the source of unit B is not available. Now Unit C is changed (any change will do and is recompiled) And the dcu of unit C differs from the unit C used by unit B, so unit B needs to be recompiled too. But unfortunately, the source is not available so the compiler gives up.
It is not entirely clear what's wrong with your situation.
You have a test framework that links to the plugins. So where do unit X and Y fit in and do you recognize the pattern shown above?
But the fact that a complete build solves the problem is hint in this direction. And this is not the first time I saw problems with partial recompiles. So I always use the complete version.
I hate this problem. I find it pops up every now and then and although it sounds in your case to be directly related to what you are doing with plugins, I've solved this in the past by finding and deleting all the dcus, bpls and dcps of the packages that we've written and then rebuilding the packages.
How I solved the 'path madness' in Delphi XE7:
Rule1: Always separate the DCU from the PAS files
Tools -> Option -> Library path:
Path to global (3rd party) libraries (DCU folder) that never change.
c:\Delphi\Tools\FastMM\
c:\MyProjects\Packages\Third party packages\$(Platform)
c:\MyProjects\Packages\DragDrop\$(Platform)
c:\MyProjects\Packages\Graphics32\$(Platform)
Project -> Options -> Search path:
Path to personal libraries, that changes often.
Enter the path to the DCU folder first, then path to PAS file.
This way, the compiler will use the DCU files first, instead of recomilin every time from PAS files.
It will recompile anyway if you do a Build.
c:\MyProjects\Packages\cCommonControls\$(Platform)_$(Config)
c:\MyProjects\Packages\cCommonControls\
Project -> Options -> Output directory:
Leave it empty so the exe file is generated in project's folder
Project -> Options -> DCU output directory:
Use .\$(Platform)_$(Config) in order to enforce Rule1
This happens to me very often when I forget to change the DPK Build control from Rebuild as needed to Explict rebuild in Options...|Description.
Check that you don't have an strained old dcu file somewhere in source dir.
For future reference, simply pointing the compiler to source-code versions of the "problem units" fixed this for me (i.e. adding the folders containing the source code to the search path).
In my case, I added the locations of the "problem" units to my project's search path. As long as it could find it, it compiled. Of course, if you have several versions of the file in question, it could complicate matters...
Your actual .dpr file contains a reference to an incorrect version of a .pas file.
View > Project Manager > expand tree and examine the path of all the units.
There is a duplicate file in the list of search paths, and the incorrect version is found first
Are you using a modified VCL? The units you reference in your interface section also determine your interface. I would suggest making sure you do not have two different versions of any of your units with the same name (including VCL/RTL) that may be referenced from your project. Maybe it is something a silly as the background compilation is using a different version of the units then the disk compilation. So editing it triggers the background compiler, which then messes up the synchronization.
Definitely something buggy with the compiler. I have found that altering the order of the units in the uses clause will allow you to get "one free compilation" in. After that, the error re-occurs and your back to rebuilding. :-(
For me the problem was that I installed Delphi with minimum required components. And when I opened a project that was compiled with full Delphi installation it happened to me. Coping the files in the "Source" folder in Delphi installation folder from another machine with full Delphi installation solved my problem.
Unit ppParameter was compiled with a different version of ppRelatv. TppRelative :
Delete all .dcu in your program folder / your computer, then re-compile or re-build again.
Then your program will running well again.
my case and solution:
we had a main application that builds an exe file and
some plugin projects that build dll files for this exe
(the dll project also needs some of the applications source files)
sometimes when compiling the dll files the "was compiled with a different version" problem occurred
the problem was this:
the exe project was setup to create all it's dcu files in a separate directory: e.g. App\DCUs
the dll project had this DCUs directory in the search path, but also some of the application's source directories: e.g. App\Utils, App\Core, etc.
thus, when you compiled the dll project, some of the applications source files were compiled again (now possibly with a different version of other dependencies):
and we ended up with 2 different dcu's of the same *.pas file
the solution is easy: remove the App\DCUs directory from the dll project's search path.
I just had the same error message in Delphi XE. Mine was solved after closing Delphi, opening it again and recompiling my project.