msbuild fails to compile (Delphi) project group
Ivo Bauer
I have problem compiling a project group that consists of 2 Delphi
projects (packages) from command line using msbuild. This is how I
call the msbuild:
msbuild /t:Build "C:\My
Components\ModLink2\Packages\ModLinkRadStudio2007.groupproj"
This compiles just fine in RAD Studio 2007, Delphi 2007 for Win32, but
not in *stand-alone* C++ Builder 2007 (December update applied,
11.0.2902.10471). I'm getting the following error:
===== console output begin ===
Microsoft (R) Build Engine Version 2.0.50727.42
[Microsoft .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation 2005. All rights reserved.
Build started 2/17/2008 6:27:45 PM.
__________________________________________________
Project "C:\My
Components\ModLink2\Packages\ModLinkRadStudio2007.groupproj" (Bui
ld target(s)):
Target Build:
Target modlink110r:
__________________________________________________
Project "C:\My
Components\ModLink2\Packages\ModLinkRadStudio2007.grouppr
oj" is building "C:\My
Components\ModLink2\Packages\RadStudio2007\modlink110r.dp
roj" (default targets):
Target CoreCompile:
C:\Program Files\CodeGear\RAD Studio\5.0\\bin\dcc32.exe -B
-DRELEASE
-JL -LE..\..\Bin\RadStudio2007 -LN..\..\Lib\RadStudio2007
-N0..\..\Lib\RadStudi
o2007 -NH..\..\Include\RadStudio2007 -NO..\..\Lib\RadStudio2007
-NB..\..\Lib\Rad
Studio2007 --no-config -$Q+ -$R+ modlink110r.dpk
CodeGear Delphi for Win32 compiler version 18.5
Copyright (c) 1983,2007 CodeGear
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Delphi.Targets
(113,3): error : modlink110r.dpk(31) Fatal: E2202 Required package
'vcl' not fou
nd
modlink110r.dpk(31) Fatal: E2202 Required package 'vcl'
not found
Done building target "CoreCompile" in project
"modlink110r.dproj" -- FAI
LED.
Done building project "modlink110r.dproj" -- FAILED.
Build FAILED.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Delphi.Targets(113,3):
err
or : modlink110r.dpk(31) Fatal: E2202 Required package 'vcl' not found
0 Warning(s)
1 Error(s)
===== console output end ===
It looks like msbuild does not pass the required library path to the
Delphi command line compiler. I cannot compile this project group from
the IDE, because there is simply no Delphi personality available with
stand-alone C++ Builder 2007. How do I proceed to get this work?
--
Ivo Bauer
agen...@gmail.com
David Dean [CodeGear]
Ivo Bauer <ab...@zom.zc> wrote:
> Build FAILED.
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Delphi.Targets(113,3):
> err
> or : modlink110r.dpk(31) Fatal: E2202 Required package 'vcl' not found
This is probably because C++Builder (alone) is not meant to build
dproj files. You should be able to call dcc32 -JL modlink110r.dpk
without error.
--
David Dean (CodeGear)
Lead C++ QA Engineer
Ivo Bauer
> This is probably because C++Builder (alone) is not meant to build
> dproj files. You should be able to call dcc32 -JL modlink110r.dpk
> without error.
Thanks for the response. As I see it, the previous versions of C++
Builder (6 and below) were not meant to build Delphi project files.
But did not the integration of C++ Builder into the same IDE with
Delphi change things a bit? I know C++ Builder was released as a
stand-alone edition, but still it comes with the support for building
*.dproj files from command line using MSBuild. How can I say that?
Because I discovered that it installs the following msbuild-support
files into the .NET framework directory:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Common.Targets
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Cpp.Targets
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Delphi.Targets
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Borland.Group.Targets
I'd guess that this is an indication that there is support (albeit
incomplete) for building Delphi project files even in a stand-alone
edition of C++ Builder. I'd like to use msbuild because it eliminates
the need to remember and specify all the params/options/switches that
dcc32 takes. After a bit of research I realized that the registry key
for Delphi library search path is empty. This was the reason why the
core VCL packages could not be found during compilation from the
command line. So, I found the problem and it had to be solved:
Solution #1:
========
I added this entry "$(BDS)\lib" to the Search path value of the
Software\Borland\BDS\5.0\Library registry key under both current user
and local machine. Then I had to reflect this change in
%AppData%\Borland\BDS\5.0\EnvOptions.proj file (which holds
information about various path settings in order to pass them to
msbuild) as per readme file by creating/updating the string value
named ForceEnvOptionsUpdate under
HKLM\Software\Borland\BDS\5.0\Globals to value of 1. Now I closed the
IDE and reopened it. The EnvOptions.proj file got updated (the
timestamp has changed) but the newly entered Delphi library search
path was not taken into account. So, I manually added the following
tag into EnvOptions,proj file:
<Win32LibraryPath>$(BDS)\lib</Win32LibraryPath>
And now, suprise: The build of my Delphi project group from
stand-alone C++ Builder 2007 has succeded!!
Solution #2:
========
This one is actually better, because it does not require you to modify
any file. I found that you can actually override a property values
passed to msbuild via EnvOptions.proj file (using the /p switch), so
the following command line made my build succeeded as well:
msbuild /p:Win32LibraryPath=$(BDS)\lib /t:Build "C:\My
Components\ModLink2\Packages\ModLinkRadStudio2007.groupproj"
Conclusion:
========
I can live happily with solution #2. The only minor issue is that
using the /p switch you actually overwrite the previous value of the
property. Do you (or anyone else) know how to preserve the previous
property value and extend it by appending some more text to it? I mean
like you sometimes extend the system environment variable Path like
for instance using %Path%=%Path%;$(BDS)\lib - is there anything like
this but for mbuild properties?
Thanks!
--
Ivo Bauer
David Dean [CodeGear]
Ivo Bauer <ab...@zom.zc> wrote:
> I know C++ Builder was released as a
> stand-alone edition, but still it comes with the support for building
> *.dproj files from command line using MSBuild.
I don't think it was supposed to... From my perspective, as a former
customer, I believe it should, so I'm glad this oversight occurred. (and
I can now use precedent to keep it in there)
> After a bit of research I realized that the registry key
> for Delphi library search path is empty.
Thanks for this piece of information. I'll enter it as a bug in the
internal system and try and get it fixed. 8-)
> I can live happily with solution #2. The only minor issue is that
> using the /p switch you actually overwrite the previous value of the
> property. Do you (or anyone else) know how to preserve the previous
> property value and extend it by appending some more text to it? I mean
> like you sometimes extend the system environment variable Path like
> for instance using %Path%=%Path%;$(BDS)\lib - is there anything like
> this but for mbuild properties?
I know just the person to ask... Let me get back to you.
David Dean [CodeGear]
Ivo Bauer <ab...@zom.zc> wrote:
> I can live happily with solution #2. The only minor issue is that
> using the /p switch you actually overwrite the previous value of the
> property. Do you (or anyone else) know how to preserve the previous
> property value and extend it by appending some more text to it? I mean
> like you sometimes extend the system environment variable Path like
> for instance using %Path%=%Path%;$(BDS)\lib - is there anything like
> this but for mbuild properties?
OK, According to the MSBuild documentation, properties set on the
command line with /p do indeed override ALL instances of that property
set anywhere in the project file or its imports. However, you can also
set a system level environment variable with the same name. MSbuild
picks up environment variables as properties.
Ivo Bauer
> OK, According to the MSBuild documentation, properties set on the
> command line with /p do indeed override ALL instances of that property
> set anywhere in the project file or its imports. However, you can also
> set a system level environment variable with the same name. MSbuild
> picks up environment variables as properties.
Thank for this information. I'll give it a go. However, it would be
great if you can get those issues(*) fixed for the future release of
C++ Builder.
(*)
Issue #1: Delphi library search path is empty once the C++ Builder is
installed.
Issue #2: Delphi library search path is not taken into account when
EnvOptions.proj file gets updated.
--
Ivo Bauer
Ivo Bauer
> I don't think it was supposed to... From my perspective, as a former
> customer, I believe it should, so I'm glad this oversight occurred. (and
> I can now use precedent to keep it in there)
That is good to hear, David. It definitely makes it easier than ever
before to deploy third party VCL components written in Delphi over to
C++ Builder developers (there is no longer a need to convert Delphi
project files to their C++ Builder counterparts).
>> After a bit of research I realized that the registry key
>> for Delphi library search path is empty.
>
> Thanks for this piece of information. I'll enter it as a bug in the
> internal system and try and get it fixed. 8-)
David, thank you for your willingness to help.
While you're at it, you might want to know about another issue that is
closely related to the one above. Even if the "Delphi Library search
path is empty" bug gets fixed, you need to reflect the change you have
done to the Delphi library search path in the "EnvOptions.proj" file
that is used to provide the information about the important paths to
the MS build engine. Currently, if you try to modify the registry key
value that is responsible for storing the Delphi library search path,
and even force the updating of the "EnvOptions.proj" file by setting a
proper global registry key value (as described in the C++ Builder
readme), the file in question gets updated, but the changes in the
Delphi library search path are not take into account (IOW the tag
"Win32LibraryPath" is still missing or not updated if you insert it
there manully beforehand).
--
Ivo Bauer