views:

359

answers:

2

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:

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.

+1  A: 

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.

DR
The files are compiled, as we can insert uncompilable code into the two parts, and one of them will make the compile fail, but see my updated question.
Lasse V. Karlsen
+2  A: 

You should always make a "build all" when you change those conditions.

Uwe Raabe
We do, that's not the problem apparently, see my updated question.
Lasse V. Karlsen