Jump to content
dmitrybv

Correct transition from dcc32.exe to MSBuild.exe.

Recommended Posts

Good day.
How to correctly translate links in a cmd file from dcc32.exe to MSBuild.exe.
I have cmd files that compile packages for different Delphi versions.


File Make_RADStudioXE10_1_NoSrc.Cmd
 

…
Chdir /d C:\RADStudio\18.0\EhLib\Src
C:\RADStudio\18.0\Bin\dcc32.exe EhLib.Rtl.dpk -W^^ -$Y- -$L- -$D- -B -JPHNE -JL - || Pause
Copy C:\RADStudio\18.0\EhLib\Src\Rtl\*.dcu RADSpecific\RADStudioXE10_1\Lib\Win32\Release  || Pause

 

File Make_RADStudioXE10_2_NoSrc.Cmd

…
Chdir /d C:\RADStudio\19.0\EhLib\Src
C:\RADStudio\19.0\Bin\dcc32.exe EhLib.Rtl.dpk -W^^ -$Y- -$L- -$D- -B -JPHNE -JL || Pause
Copy C:\RADStudio\19.0\EhLib\Src\Rtl\*.dcu RADSpecific\RADStudioXE10_2\Lib\Win32\Release  || Pause


Please tell me how to change the dcc32.exe command line correctly to switch the compilation to MSBuild.exe?

 

By default, MSBuild.exe is not available from the command line because it is not specified in the PATH.

 

You can specify the full path C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
But how do you pass a link to the dcc32.exe compiler version to MSBuild.exe?
Like MSBuild.exe /dcc=C:\RADStudio\19.0\Bin\dcc32.exe
Like MSBuild.exe /dcc=C:\RADStudio\18.0\Bin\dcc32.exe

 

How does MSBuild.exe know which version of dcc32.exe to use?

Share this post


Link to post

It looks like you need to specify the dcc32.exe version via the BDS environment variable.


 

@SET BDS=C:\RADStudio\22.0
@SET FrameworkDir=C:\Windows\Microsoft.NET\Framework\v4.0.30319
@SET FrameworkVersion=v4.5



%FrameworkDir%\MSBuild EhLib.Rtl.dproj /t:Build /p:Config=Release /p:platform=Win32
%FrameworkDir%\MSBuild EhLib.Rtl.dproj /t:Build /p:Config=Release /p:platform=Win64
%FrameworkDir%\MSBuild EhLib.Rtl.dproj /t:Build /p:Config=Release /p:platform=Android64
%FrameworkDir%\MSBuild EhLib.Rtl.dproj /t:Build /p:Config=Release /p:platform=Linux64
%FrameworkDir%\MSBuild EhLib.Rtl.dproj /t:Build /p:Config=Release /p:platform=OSX64

 

Share this post


Link to post

Usually it is sufficient to call the rsvars.bat of the required version:

call "c:\Program Files (x86)\Embarcadero\Studio\23.0\bin\rsvars.bat"

 

  • Like 1

Share this post


Link to post
12 hours ago, Uwe Raabe said:

Usually it is sufficient to call the rsvars.bat of the required version:


call "c:\Program Files (x86)\Embarcadero\Studio\23.0\bin\rsvars.bat"

 

The rsvars.bat file contains the following line:

 

@SET PATH=%FrameworkDir%;%FrameworkSDKDir%;C:\RADStudio\23.0\bin;C:\RADStudio\23.0\bin64;C:\RADStudio\23.0\cmake;%PATH%

As far as I understand, this command adds new paths to the PATH.

How safe is it to call rsvars.bat many times? I need to compile my packages for all Delphi versions starting from 2009.

Can the PATH variable overflow after a certain number of rsvars.bat calls? Or not?

Or is there a way to reset all variables set in the rsvars.bat file?

Share this post


Link to post

AFAIK, the change to the PATH variable lasts until the batch file ends (unless executed by a call). If you need to call different Delphi versions inside the same batch file, you might save the original value and restore it before calling the next rsvars.bat

 

Share this post


Link to post

Thanks Uwe. I didn't know about it.

 

I did some tests. Indeed, if you execute a cmd file by its name without a prefix, then when you exit the cmd file, the values of the environment variables are not saved, but not always.

 

After installing RAD Studio, the installer adds a shortcut “RAD Studio Command Prompt” with the following value Target = %comspec% /K "C:\RADStudio\23.0\bin\rsvars.bat"

 

/k Carries out the command specified by <string> and keeps the command processor running.

 

There is no call prefix in the Target parameter when calling rsvars.bat. This means that rsvars.bat is executed as a standard cmd file.

 

But, after running “RAD Studio Command Prompt” (AND executing rsvars.bat and exiting rsvars.bat), all variables set in rsvars.bat have the values that were set in this file.

Share this post


Link to post

Or, simply run each build in a separate cmd.exe instance so they each have their own environment.  Changes made to the environment variables are local to each instance, not saved globally or across instances.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×