I'd like to ensure particular options are set on 150+ packages. So I thought I could create a quick FB project to do this. Unfortunately, it isn't working.
I've attached the project source and log, separately. I'm not sure the log would be useful so I attached it separately.
FinalBuilder 7.0.0.1561
This project has two actions: a list iterator containing a list of the packages I want to update (DPK files) and a child Delphi Compile action. On the Delphi Compile properties, I have selected "Load settings from project file". In script events on the action, I'm using Action.CompilerOpt to set specific values. At the end, I'm setting Action.UpdatePackageSource = True. Yet, neither the DPK nor the DPROJ are being updated.
So, either I'm doing something wrong, I'm expecting FB to do something it isn't support, or a bug has managed to stop me in my tracks.
I had to look at the source for this one. It seems that the Update Package Source Option is not used/allowed when the compiler settings are loaded from the project (dproj). I’m not sure why that’s the case, I will have to have a look back through our source control history (118 checkin’s since we switched to surround scm in 2005!) to see why that is, however looking at the code it does seem to be very deliberate.
Ok, just had a look and it was added at the same time we added support for loading from bdsproj files in 2006. I believe the reason had to do with which compiler settings override which (cmdline vs dpk). We may be able to remove that restriction but I will need to do some testing on this tomorrow (it’s almost midnight here now).
Thanks Vincent. I hit the wall in the middle of the night last night. I was ready to crash myself, but decided to post the question in hopes that you'd see it before the end of your day.
I always remember the huge time difference, I just forget which way it goes. (The end of my workday is the beginning of your work *next* workday. But sometimes I forget and get it backwards, thinking the beginning of my day is the end of yours. But that would only be a nine hour difference rather than sixteen hours.
I have removed the restriction as I couldn’t find a good reason for it, however I reserve the right to revert the change if it causes other users problems (I’m assuming I put it there for a reason, but I can’t for the life of me think why… it was a while ago now, too many lines of code ago).
BTW, our timezone is GMT+10(11 now with daylight saving) so it’s probably around 15-18hrs difference at the moment depending on which coast (or part of the middle) you are in.
Thanks for a new build just for this little change.
I think it would be completely safe because the changes to the DPR are written to my disk as a DPR.modified file. The original .DPR is not affected. I'll write another quick script to replace the original .DPR file with the .modified version, unless there is a different property or option that I can use to change the .modified behavior.
FB doesn't update the .DPROJ. However, once I open the .DPR in Delphi and immediately close the .DPR, Delphi prompts if I want to save changes and the .DPROJ is updated. Again, this is perfectly acceptable for me. I just wanted to make sure I wasn't missing something that would cause FB to update the .DPROJ.
No matter what I do, FB writes {$REFERENCEINFO OFF} to the modified .DPK. I originally had this in my script:
Because I'm trying to get {$REFERENCEINFO ON} written to the .DPK. I've tried several True/False combinations of the above, including combinations where only one or the other were set via script. I always get {$REFERENCEINFO OFF} in the .DPK. If this is a bug, please just add it to a list of future items. I can easily search and replace one with the other.
As a side note, we're just now starting to use Delphi XE. I'm encouraging the other guys on my team to try out FB XE edition. I'm also getting ready to completely redesign our build process, so I'll be spending a lot of time in FB again.
Thanks Vincent!
[Edit: Strange, the forum's "Edit" editor seems to be different than the "Post" editor. After editing, the code block now shows HTLM tags for newline/break or paragraph. *shrug*]
My apologies for the delay in replying. It took me a while to pin this one down. It's a bug.. and one that's been there for some time. I had to confirm the behavior for older delphi version vs more recent versions to make sure the bug wasn't introduced trying to fix something else. I spent a few hours playing with the options to confirm the behavior hasn't changed and it is a bug in FB.
Anyway, I should be able to check in the fix for this later today. The logic for this will be :
if CompilerOptions.ReferenceInfo and CompilerOptions.DefinitionsOnly then sDirective := '{$DEFINITIONINFO ON}' else if CompilerOptions.ReferenceInfo then sDirective := '{$REFERENCEINFO ON}' else sDirective := '{$REFERENCEINFO OFF}';
I'll post here when a build is available with the fix.