0

I am in the middle of upgrading from Delphi XE3 to XE7 and I have noticed that my FinalBuilder script is no longer working as expected.

I have various Delphi projects configured to output the BPL / DCP files to $(BDSCOMMONDIR)\* which is set as a system environment variable to C:\Users\Public\Documents\Embarcadero\Studio\15.0. Opening up the projects in the IDE & compiling works as expected, however, whenever I compile using FinalBuilder the files are built to C:\Users\Public\Documents\RAD Studio\15.0 and I have no idea why, I have searched everywhere and can't see where this path is set i.e.

  • (IDE) Tools -> Options -> Environment Variables
  • %APPDATA%\Embarcadero\BDS\15.0\environment.proj
  • FinalBuilder environment variables
  • System environment variables

In all those locations the path is as expected. My suspicion is it's an issue with having both XE3 and XE7 installed on the same machine, purely because for the XE3 setup $(BDSCOMMONDIR) points to C:\Users\Public\Documents\RAD Studio\10.0 (only difference is the product version). As I am only evalulating XE7 at the moment I would like to try avoid having to uninstall XE3 unless it's absolutely necessary.

Note - one other difference here is when I installed XE7 I chose the Delphi install rather than RAD Studio one which I used previously when installing XE3 (I don't need the C++ Builder stuff).

Does anyone have any idea why this is happening?

Ganesh Sittampalam
  • 28,821
  • 4
  • 79
  • 98
James
  • 80,725
  • 18
  • 167
  • 237
  • How do you specify in FinalBuilder that you want it to build with a specific Delphi version? Surely once it has that information it takes care to setup the appropriate environment. I also wonder why you have defined a BDSCOMMONDIR environment variable in the system environment variables. – David Heffernan Sep 16 '14 at 10:40
  • @DavidHeffernan there is an option in FinalBuilder against each individual compile action which allows you to set which version of Delphi you want to use, it works fine for XE3 (I wonder if this is potentially a bug with FinalBuilder?). I had the BDSCOMMONDIR in my own user environment variables but changing it didn't seem to make any difference so I tried it in the system (same problem though). Also, funnily enough changing the value for BDSCOMMONDIR in the `environment.proj` file made no difference in the `Tools -> Environment Options` (not sure where those values are pulled from). – James Sep 16 '14 at 10:45
  • I don't understand why you are setting `BDSCOMMONDIR` env vars anywhere. It's just not your job to do that. You should unwind all of that. Modifying `environment.proj` is another bad move. Why are you doing all of this? – David Heffernan Sep 16 '14 at 10:47
  • @DavidHeffernan Sorry think I was confusing myself there...I set `BDSCOMMONDIR` in the user/system environment variables so it can be picked up by FinalBuilder, the reason for this is because there are some pre-compiled BPL/DCP files that we just need to manually copy. However, in hindsight there's probably a better way in FinalBuilder for doing this (perhaps I can load in environment variables from the Delphi IDE). – James Sep 16 '14 at 10:51
  • I would start by unwinding all of the changes to environment variables, and putting back any IDE options to their original state, and restoring any modified environnent.proj files etc. Basically undo all the messing around that you have done. Then work out how to get FinalBuilder to use the appropriate environment when building. Does FinalBuilder let you setup the environment by invoking `rsvars.bat`? And does it build using msbuild? – David Heffernan Sep 16 '14 at 10:53
  • Ok, so I've removed instance of `BDSCOMMONDIR` from my user/system environment variables and I've undone the changes to the `environment.proj`. So in my FB script I can no longer reference the `BDSCOMMONDIR` variable (which makes sense). If I go to the compiler options in FB I can tell it to load the variables from the specific Delphi version on startup (which I presume uses `rsvars.bat`), however, after doing so it only appears to load the *User overrides* from Delphi and none of the System ones. – James Sep 16 '14 at 11:07
  • Yeah, I've no idea about FinalBuilder. Never used it. I script all my own builds. I guess the docs say how to get the FB build tasks to configure the build environment. – David Heffernan Sep 16 '14 at 11:09
  • Yeah no worries, I have read the docs and this is apparently how it's supposed to be done but clearly something funny is going on as it's not loading the System ones. I can workaround it by adding an override with the same value but it would be good to understand why the others aren't loaded. However, even if I figure this out, does this solve the problem? My compile actions are all configured to load the settings from the Delphi projects, FB doesn't pass anything to the compiler therefore that doesn't explain why BDSCOMMONDIR *appears* to change when built in the IDE vs via FinalBuilder. – James Sep 16 '14 at 11:11
  • No, I'm not claiming that this will resolve your problem. But I think it's important to get your machine to a clean state in order to investigate. But something has got to set the env vars in order to build. You don't want them set globally in either system or user vars. You do want the process that build to have them set. The IDE arranges this. FB clearly needs to do so somehow. One option would be to use rsvars.bat. But I've no idea how it does it. – David Heffernan Sep 16 '14 at 11:12
  • No, don't do that! I've got millions of Delphi versions installed on my machine. The key is to make sure that the global environment knows nothing at all about them. Only when doing specific tasks do you set up a local environment with the necessary vars. – David Heffernan Sep 16 '14 at 11:15
  • Read this: https://www.finalbuilder.com/support/forums/aft/10336 Do you have this option checked? – David Heffernan Sep 16 '14 at 11:16
  • @DavidHeffernan yeah I removed that comment after seeing your update, I won't uninstall anything just yet :) I guess FB is doing a bit more than just calling `dcc32` externally, like you say it must be also loading in the environment variables otherwise the projects wouldn't compile. Looking at the output log it calls the projects like `\B Project.pkg \Q` which as far as I can remember just means perform a quiet compile. – James Sep 16 '14 at 11:17
  • @DavidHeffernan yep got that option enabled, that's what I was referring to in my previous comment about loading in the env vars from Delphi and it works to an extent, it just doesn't appear to load the system ones from Delphi i.e. `BDS` / `BDSCOMMONDIR` etc. – James Sep 16 '14 at 11:19
  • Sounds like you need to remove that option. Won't it load the settings from the latest Delphi version? What type of action are you using in FB? I expect this issue is all about how you are using FB, but we cannot really see any details of that. – David Heffernan Sep 16 '14 at 11:21
  • @DavidHeffernan just using the [Build Delphi Action](http://help.finalbuilder.com/Index.htm?delphicompileraction.htm) with all the project settings loaded from the Delphi project itself. Remove what option? This [one](http://finalbuilder.com/support/forums/aft/10336)? – James Sep 16 '14 at 11:24
  • I think I should back out of this, since I don't know FB. You may need help from somebody who does. FWIW, I cannot really see the point of FB. You can build with a two line .bat file. One line to call rsvars.bat, and one line to call msbuild. I do suspect that FB is making life much more complex than it needs to be. – David Heffernan Sep 16 '14 at 11:25
  • @DavidHeffernan No worries, thanks for your help anyway. FWIW I inherited FB, it wasn't a choice on my part. However, the script itself is much more complex than just compiling a few projects so it does come in handy. – James Sep 16 '14 at 11:26
  • In reality my build scripts are more complex than building Delphi projects, but then again I always script that myself using my preferred tool (Python). I'm a bit of a control freak mind you. – David Heffernan Sep 16 '14 at 11:30
  • @DavidHeffernan haha the UI part of it makes it fairly simple to work with + organise things easier. Anyway I digress...more frustratingly if I switch back to XE3 it works as expected! – James Sep 16 '14 at 11:36
  • Can't you just call rsvars.bat and move on? – David Heffernan Sep 16 '14 at 13:16
  • @DavidHeffernan I tried adding a command line call to `rsvars.bat` in the script before it runs the builds but it didn't work. If you look at the comment on @UweRaabe's I found an article that was quite interesting, possibly the actual problem. – James Sep 16 '14 at 13:33
  • "It didn't work." Hard to diagnose this beyond suggest that you "fix it". No matter what, you know that you need to set this environment variable. How are you doing so? How do you want to set it? Do you have a plan for how to set this variable? Are you using msbuild? I'm sure I asked this already. – David Heffernan Sep 16 '14 at 13:35
  • @DavidHeffernan I'm not sure what information I can give you other than running rsvars.bat didn't change anything which would suggest that it's not what the problem is. At the moment I have reverted back to using a user environment variable and just accommodating the output path FB seems to be fixed to (frustrating as it is). I don't specifically use msbuild and as far as I am aware neither does FB for building delphi projects. – James Sep 16 '14 at 13:49
  • FB purports to be able to use msbuild. FB can surely have per action environment variables. I suggest that you need to understand how you are building better. Because if you don't know whether or not you are using msbuild then you are in trouble. What's more if you don't use msbuild then your automated builds could well be different from your interactive ones. Which is not what you want. – David Heffernan Sep 16 '14 at 13:51
  • @DavidHeffernan that's *sort of* the beauty of the likes of FB, it shouldn't really matter if it's using msbuild behind the scenes or not (unless I need something specific to that). I use a `Build Delphi` action, setup all my properties and it does it's thing. It's only since upgrading to XE7 and, consequently, FinalBuilder 7 that this issue has begun to occur. I am leaning towards it being a bug in FinalBuilder because the path it's generating is not by me or Delphi. – James Sep 16 '14 at 13:53
  • If you don't really understand what you are doing, and you are changing global and program settings by trial and error, you aren't in a position to suspect that it is a bug. In my opinion you need to understand what you are doing. You cannot hope to get this right if you don't attempt to gain understanding. This is why I do this stuff myself. So that I actually understand what is being built, and know that it is done correctly, and reproducibly. And does not rely on global settings. And allows versions to be isolated from each other. – David Heffernan Sep 16 '14 at 13:55
  • Anyway, the simplest way for you to proceed is as Uwe says. Remove all global settings. All Emba related system/user env vars. Remove all Delphi settings from your PATH. Then add the necessary env var in FB, local to the Delphi build. – David Heffernan Sep 16 '14 at 14:00
  • @DavidHeffernan there is a method to the madness, like I said I inherited this build process and it's been in place for around 10 years - it works and has done for many years. I understand & take your points, and concur, however, the fact is it *worked* with XE3 and now after installing XE7 & the latest version of FB it *doesn't* - the path appears to be dictated by FB which would suggest it's a bug. FYI even the guys at FinalBuilder are suggesting that it is infact a [bug](https://www.finalbuilder.com/support/forums/aft/10291). – James Sep 16 '14 at 14:14
  • Maybe it is a bug. I never said otherwise. But my points stand. It pays to know what's going on and understand things. My previous comments contains what I consider to be very sound advice. Remove all global settings. – David Heffernan Sep 16 '14 at 14:18
  • @DavidHeffernan I am not sure what you are getting at "remove all global settings"? What global settings? I don't have any, all I did was add a BDSCOMMONDIR env var so it can be picked up by FinalBuilder - that's it. If this bug is fixed in FB then I can *completely* get rid of that issue and reference the BDSCOMMONDIR loaded in from Delphi. Also, just to clear this up - I certainly do know & understand what's going on here, however, sometimes things break and you do everything & anything to try fix it because nothing logical is working - that's what's going on here. – James Sep 16 '14 at 14:28
  • @DavidHeffernan the fact that I've only came back onto this project after 1+ years away from it doesn't help either :) – James Sep 16 '14 at 14:28
  • What I suppose I mean by knowing and understanding is things like whether or not FB is using msbuild or dcc32. You certainly do have global settings. The environment variables that you have been modifying are global settings. And the BDS installer modifies your PATH and sets other variables. You should remove all Borland/Emba references from your PATH variable. And remove all other Borland/Emba related env vars. That way you can isolate builds. – David Heffernan Sep 16 '14 at 14:38
  • @DavidHeffernan well I can tell you for sure that it uses `dcc32`, I already explained in a previous comment that all FB was calling was `\B Project.pkg \Q`, I guess what I failed to mention was it was calling the Delphi compiler and not msbuild. I can double check all the vars but as far as I can recall all I did was add the BDSCOMMONDIR one and that's just a requirement (for now) for FB to work. – James Sep 16 '14 at 14:47
  • OK, that's good that you know that. I think I'd use an msbuild task myself if at all possible. Then the automated builds would match the IDE builds. I'm probably not helping now though (and have not been helping for some time ....) So, I'll try to keep quiet!! – David Heffernan Sep 16 '14 at 14:50
  • @DavidHeffernan all advice/feedback is welcome :) I understand & agree with all of your points, however, as I am sure you are aware deadlines/time constraints and trying to manage a team & be a developer + manage the builds etc. means I don't have the luxury of time (at least at the moment) to overhaul the process. I am gradually improving it as I go along here & there and actually on this iteration removed a good few redundant tasks which was nice. – James Sep 16 '14 at 14:53
  • Actually, just picked up a point you made - does the IDE compile using msbuild rather than dcc32? I admittedly wasn't aware of that :) I just presumed it used dcc32... – James Sep 16 '14 at 14:56
  • 1
    Ultimately it calls dcc32, because that's the compiler. Or dcc64 for Win64. Or indeed one of the other compilers. But msbuild drives it. And by going via msbuild you are sure that the options passed to dcc32 are identical to those done from interactive builds. – David Heffernan Sep 16 '14 at 15:21

1 Answers1

4

BDSCOMMONDIR is virtualised along with all the other delphi variables like BDS, otherwise it's impossible to compile with multiple versions of delphi.. which is something library/component vendors do all the time.

The issue here is a bug in Finalbuilder's XE7 support, a fix will be released shortly.

Vincent Parrett
  • 581
  • 5
  • 9
  • Thanks Vincent, I did have my suspicions that this may be related to the difference in the installs, this is a bit of a showstopper for me at the moment so any pre-release build would certainly help. Also, on the virtualisation - are they only virtualised if the "*Load environment variables on startup from X*" is ticked in the compiler options or is this always supposed to happen if you use a `Build Delphi` action? – James Sep 17 '14 at 08:40