Command line compilation always using TwineCompile

[jgallango]

Hi,

When we were using TC 2.x we created 2 separate batch files to compiIe using or not TwineCompile

Command line to compile using TC
msbuild Project.groupproj /target:Make /p:CoreCompileDependsOnTargets="DccCompile;TCBuildFileList;TCCompile;TasmCompile;BrccCompile;" /p:Configuration=Release

Command line to compile NOT using TC
msbuild Project.groupproj /target:Make /p:Config=Release

We are now using TC 3.2, and I recently noticed that now our command line scripts always compile using TC (I am using TC 3.2.0.213). I don't know if the problem happens since we updated to 3.2 or was it there already in 3.0.

The scrips have not changed for quite some time now, so I wonder, is there a way to make sure that we can disable TC?

Thanks

[jomitech]

Do your project files include the TCTargets.targets file?

[jgallango]

Yes, all our cbproj have included both Borland and TCTargets targets files since we started to use Twinecompile back in version 2.x

<Import Project="$(MSBuildBinPath)\Borland.Cpp.Targets" />
<Import Project="C:\Program Files\JomiTech\TwineCompiler\TCTargets.targets" />

Previously, we had the option to compile from command line using TwineCompile or not depending on the BAT file use, which used the different msbuild commands mentioned in the original post.

Are you saying that now build will always use TC if the cbproj includes TCTargets.targets?

[jomitech]

With TwineCompile 3.2, we made TC the default compiler with MSBuild. To revert it, call MSBuild using this command line parameter:

/p:CoreCompileDependsOnTargets="DccCompile;BccCompile;TasmCompile;BrccCompile;"

[jgallango]

Hi Jon, I have tried the option you mention and:
1.- I see that with those options it now uses BCC32 instead of mtbcc32 when compiling the code (GOOD)
2.- I get many compilation errors, apparently due to problems with RAD Studio lib paths (When disabling TC in the IDE it compiles fine). Anything else I should add in the BAT file I use to compile?

The compilation errors I get are like these:
...
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Cpp.Targets(883,3): error : Error E2257 C:\Program Files\CodeGear\RAD Studio\5.0\\include\dinkumware\yvals.h 890: , expected
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Cpp.Targets(883,3): error : Error E2316 C:\Program Files\CodeGear\RAD Studio\5.0\\include\stdio.h 159: 'wint_t' is not a member of 'std'
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Cpp.Targets(883,3): error : Error E2040 C:\Program Files\CodeGear\RAD Studio\5.0\\include\stdio.h 159: Declaration terminated incorrectly
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Cpp.Targets(883,3): error : Error E2316 C:\Program Files\CodeGear\RAD Studio\5.0\\include\stdio.h 169: 'wint_t' is not a member of 'std'
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Cpp.Targets(883,3): error : Error E2040 C:\Program Files\CodeGear\RAD Studio\5.0\\include\stdio.h 169: Declaration terminated incorrectly
...

[jomitech]

TwineCompile does not change the include paths at all. I'm very surprised that you're seeing compiler errors when switching back to bcc32.

[jgallango]

Hi Jon,

My compilation errors using bcc32 got solved after reinstalling C++ Builder (sigh).

Enabling/Disabling compilation with Twinecompile works fine in 3.2 for me now with your suggested msbuild flags:

Using TC
----------
msbuild Project.groupproj /target:Make /p:Configuration=Release

NOT Using TC
----------------
msbuild Project.groupproj /target:Make /p:Configuration=Release /p:CoreCompileDependsOnTargets="DccCompile;BccCompile;TasmCompile;BrccCompile;"

Thanks

[jomitech]

Glad you solved it - although it was the hard way.

[jgallango]

Yep, just for the record, I had to reinstall Codegear to get command line to compile without TC, but when it happened the same to another co-worker we realized that the reason was that we had replaced ilink32 and bcc32 in C++ Builder 2007 with the ones from C++ Builder 2010.

That was something we both had to do to overcome a compilation/linking problem in the past that according to the Codegear forums the only working solution was to replace compiler/linker with newer ones.