I have successfully registered an IDE notifier (IOTAIDENotifier80) so I get AfterCompile notifications.
Is it possible to find out whether the project was built versus just being compiled/made?
I've found this answer about implementing a IOTAProjectCompileNotifier but this is not available in D2007.
Any other way? I'd be fine with an undocumented way as this is for an inhouse expert only.
Update: I need this to replicate the "AutoInc build number" feature with an external .rc file containing the version info resource. Maybe this can be done via BuildEvents? Although I like the ability to log a message in the IDE showing the updated version number...
I have no idea about writing experts or hooking into the IDE, and I'm scared of trampolines. Having said that, I've noticed that you can tell the difference between a compile and build by monitoring the timestamps of the files in your project output folder, but this difference is only evident if no code (*.pas or *.dfm) has changed since last compile or build. In other words, when there is a code change, you can NOT tell the difference by monitoring the timestamps. However, when there is no code change since last compile or build, a compile will only change the timestamp of the exe (the dcu timestamps are not changed).
Therefore, in the absence of other more elegant solutions, and only if you are really desperate for this information (ie, was it compiled or was it built?) then I can suggest a 2-part solution for you.
Part 1. Write a process to monitor changes in timestamps in your output folder, and
Part 2. Tell your fellow developers there is a bug in D2007 which complicates your build process, but that this bug is easily overcome by simply compiling twice or building twice (or if you know how to automate this then go for your life). If you can get your developers to compile twice or build twice then upon the second compile or build you will be able to deduce whether it was a compile or build by testing if the timestamp of the dcu changed upon the second compile or build.
Now, I will go and stand in the naughty corner and ask myself "why me?". Cheers.
Related
This is the error messsage I get.
I know it's kind of an eye roller, that it's difficult nigh impossible to tell what I may need without the source, but it seems like a deployment problem as people that installed the Qt SDK can run it. Plus, I figured I'd have better luck asking here than with a chinese developer that speaks google-english.
So here's what I've done:
I installed the MSVC2012.
I used a program called cffexplorer to see what the exe was looking for. I have the 7 or so .dlls that are at the top of the tree.
I found a recent (jun 2013) qwindows.dll from elsewhere on my system and put it in ./plugins (I've tried this file in ./, ./plugins, and ./plugins/platforms
I created a qt.conf with the following data (I determined the format from an existing Qt based app that works)
[Paths]
Plugins = plugins
Yet, I continue to get this message. Any suggestions on what I might look for to clear this up?
Ask the developer what compiler was used to build the application. Then you will need the right dll (that was built with the same compiler as the application). Also notice that (by default) the documentation says that qwindows.dll should be in the platforms folder in the same path as your executable, read more here. Depending on whether the developer used a Qt built with angle, you may also need: libEGL.dll and libGLESv2.dll. Dependency walker might help you find dependencies that are not there.
I am debugging a bpg with multiple dll's. Can someone tell me why my breakpoints, that DO work, eventually stop working? The only way to get them back is to do a build all in my project group file (BPG file in Delphi 6)?
I have looked at several other posts, but have not had much luck getting an answer to this specific question. Again, I can successfully debug, all dll's in the BPG provided I do a build all. Doing a build all every time is taking too long.
I am using Delphi6 in WinXP.
Thank you
In Delphi 6, such a failure to find debug information (all the blue lines are gone from your sources) that is solved by a complete rebuild is usually a symptom that you have to examine your project (.dpr) settings. For each project (dll or exe) make sure a different unique compiler output folder (DCU output folder) is used.
We currently use Delphi 2009 and GIT to develop an application. We have set up a prebuild script to generate a version number and build ID using information from git and compile this as a resource that is included in the project. The problem is that this script doesn't run on a regular compile. This means that the other developers can end up with a discrepancy between the actual version number and the number in the resource (especially when switching branches in git).
Since we use our software to make some critical calculations, we would like to use this build id to reproduce calculations and track down problems.
Other than trying to force my developers to frequently press shift-F9, how can I ensure that the the prebuild script gets run when necessary (ideally at each compile)?
Jason
UPDATE: It's true that the pre-build script gets run at each compile. The problem was that I expected to get a different result pressing F9 after making a tag in git, even though no code had changed.
We solved a similar issue by writing a custom IDE plugin which uses the IOTAIDENotifier50 interface. Specifically using the BeforeCompile method, to test some required project settings and also generate dynamic version information (VERSIONINFO resource). It gets called for every type of build (compile and build). We also generate a unique exe serial number and log everything, which helps us track down issues and is similar to your script. For completeness we have only done this in Delphi 2007 and Delphi XE.
Pre build actions do run before every compile.
You state in a comment that the actions sometimes don't run when you press F9. That makes sense because F9, or Run, only invokes a compile if source is deemed to have changed.
A BeforeCompile notifier plug in will behave in exactly the same way. Your solution is to make sure that you compile before running using Ctrl+F9.
My Delphi installation has been going downhill for the past few months. It seems though that every so often when I build a release it has strange errors in it which are resolved if I build, then compile, then build, compile, etc.
I've talked to another developer who thinks that this is a compiler error. This sort of degrading performance over time has happened on other computers to us too.
What does stack overflow think could be the problem.
What I've seen most is a case where multiple versions of the same units/dcus exist in different folders/paths, and depending on almost insignificant variations the compiler/linker uses a different path and picks different versions of the units to build the exe.
I would make a huge Spring clean-up, scrutinize the lib/search paths, remove all dcus and make sure there is no duplicate versions of any unit.
And, agreed, reinstalling Delphi could help start with a clean state.
I agree with #François about the DCUs, but also want to point out an observation: sometimes it matters what was built prior to what you're building. i.e. if you have several projects that contain source code that results in various .dcu/bpl files being created in a common directory, but the project that you're concerned with doesn't explicitly call for them to be rebuilt, then you're going to end up with whatever is there. If you clear the dcus/dcps prior to building, and then find that your project doesn't build, then you are missing a uses/requires clause somewhere. Every project shoudl be able to build on a "clean slate", and not rely on leftover binaries.
That's not much to go on, but it sounds like a classic case of "bit rot". Too many things interacting in too many ways for too much time under a poorly-designed OS, leading to strange forms of data corruption.
First thing I'd do is uninstall Delphi and reinstall. If that doesn't work, try reinstalling Windows. (If it's been around long enough for this to be happening, you're probably due for an OS reinstall anyway.) And if that doesn't work, contact Embarcadero tech support.
We have a very important application, but so far no source code. The application was written in COBOL and a compiled version is in our production system and is running.
However, we need to migrate to a new server, and new cobol compiler. We're under the impression that we need to recompile the code to get it to work on the new server. Running the exising compiled program gave runtime memory errors.
We have some source code for the program, but it is old. Not sure what the diff is between it and the compiled program.
Okay, so the question -- what should we do?
Time is not on our side, since we have to send our old server back to get credit for it. Ideas, suggestions, crazy or otherwise? (source control is obvious and its not up to me to do it, so save the lectures)
Create an image of your old server. Then run the old server as a virtual machine on your new server.
However, I agree a better option is probably to keep your production server.
In the short run it would probably be cheaper to arrange to keep the old server. In the semi-long run, you need to make time and budget to reengineer the program, either re-write it or see how much effort it would be to hack the old code into shape doing what the program currently does.
It's sadly. You should consult the Source Recovery Company
If your source code is relatively close to the compiled version, try this:
decompile new version into assembler
compile the old source code into assembler
compare
reconcile as best you can the differences from new version with old version, into the old souce code
repeat
To augment this, and probably as a second step, as it will bring the source code farther from the new compiled version, test with input data and just try reverse-engineering based on the output what would be needed to create that output. The more test input data you have the better this could work.
Good luck!
(I'm not a COBOL programmer but..)
If you know what version the compiler was that compiled the original program, you could at least compile the old cobol source; if the compiled versions is identical you know the source actually is the current version.
If they differ, you could try to (somehow) decompile, or at least disassemble, the working compiled version and the freshly compiled version and use a diff tool to get an idea of how big difference there is.
crazy sugestion: COBOL DECOMPILER --> SOURCE --> NEW COBOL COMPILER...?
(edit: http://juggersoft.com - PAID cobol decompiler)
if you have the .int (intermediate) binary files you can just run on the new server, if not, them you musto to recompile.
The program could have been produced by an external resource and that person or software house or organisation could have the latest source in their repository. It may be held by your parent organisation if you have recently merged, or may be in a different or backup computer installation in your organisation. There may be a copy on the developer's user account and may not have been sent to the production or live site or someone from head office has a copy to assess and try to resolve the situation. You may have success if phone those people or you could always talk to the installation computer operator or support staff and see if they have one on mag tape, CDROM or other backup storage.