When I execute delphi 2009 project using MSBuild command line, output always goes to C: drive
C:\MyProjects>MSbuild "C:\MyTestProject\Test.dproj" /t:Build /p:OutDir="C:\Output\bin\"
Why is this happening?
I know the docs say otherwise, but try OutputPath instead of OutDir.
For Delphi projects you need to use DCC_ExeOutput to specify where the EXE should go.
C:\MyProjects>MSbuild "C:\MyTestProject\Test.dproj" /t:Build /p:DCC_ExeOutput="C:\Output\bin\"
Take a look inside Test.dproj for any other options you might want to specify.
Related
Is there a way to do this in F#:
let fakeToolsPath = "D:\tools\FAKE\tools\FakeLib.dll"
#r fakeToolsPath
the fake tools are on a different path depending on the build agent that builds the code, so I need to be able to set it dynamically, from an environment variable or some config file.
Three ideas, in order of increasing hackiness - you'll be the judge which one makes most sense in your scenario:
In .fsx script, you can use __SOURCE_DIRECTORY__ to get the directory where the script is located. If your dll is always located in the same directory relative to the script, you can use that as a "hook" to get to it.
There's a command-line --reference argument to fsi.exe that should do what you want. If you're using fake.exe instead, you can use --fsiargs to pass it in (take a look at the link for details).
If everything else fails, create a symlink as a separate build step in your CI job configuration and just hardcode the path in the script.
I've been using the command prompt to practice assembly programs and I wish to use notepad++ as the editor. Adding notepad++ to the path will do the job but I don't want to type 'notepad++' each time I have to edit a file. Is there a way I can change the name of the executable? Without having to rename the application name.
You could create a quick batch file called, say, npp.cmd. That batch file only needs to have this in it:
#"C:\Program Files (x86)\Notepad++\notepad++.exe" %*
Put npp.cmd somewhere in your path (I have a C:\tools directory for batch files like this) and off you go.
Or associate your assembler sources with Notepad++.
ASSOC .asm=asmfile
FTYPE asmfile="C:\Program Files (x86)\Notepad++\notepad++.exe" "%1"
Then you can edit *.asm files with Notepad++ by double clicking on it in Explorer or by writing it's name in command prompt.
I have the following sample code:
program boohoo;
{$APPTYPE CONSOLE}
{$IFDEF boo}
{$MESSAGE warn 'boo'}
{$ENDIF}
{$IFDEF hoo}
{$MESSAGE warn 'hoo'}
{$ENDIF}
begin
end.
In the project options the conditional boo is defined. I would like to be able to add the conditional hoo as part of my msbuild command line.
I have tried it like this:
msbuild boohoo.dproj /p:Config=Release;DCC_Define="$(DCC_Define);hoo"
The output shows hoo but not boo. When I use verbose output to see the dcc32 command I see
-D$;hoo
Clearly I can do it like this:
msbuild boohoo.dproj /p:Config=Release;DCC_Define="boo;hoo"
but naturally I want to use whatever conditionals are declared in the project options plus what I specify on the command line.
Is there any way for me to specify this property with reference to the value from the underlying configuration?
Disclaimer: don't use MsBuild myself yet, all taken from the docs and some IDE experimentation
According to MsBuild command line reference ( http://msdn.microsoft.com/en-us/library/ms164311.aspx ):
/property:name=value
Sets or overrides these project-level properties, where name is the
property name and value is the property value. Use a semicolon or a
comma to separate multiple properties, or specify each property
separately. /p is also acceptable. For example:
/property:WarningLevel=2;OutputDir=bin\Debug
setting or overriding is all you can do for a property value. Adding to a property value from the project file is either not possible or a case of a hidden feature.
But I guess what you could do is define a custom property in your dproj file with an " " as its default value:
<PropertyGroup>
<ExtraDefines> </ExtraDefines>
</PropertyGroup>
reference that in your defines statement
<DCC_Define>DUNIT;$(ExtraDefines);$(DCC_Define)</DCC_Define>
which in the IDE should be DUNIT;$(ExtraDefines)
and then specify it on the command line:
msbuild boohoo.dproj /p:Config=Release;ExtraDefines="hoo"
I did test adding the $(ExtraDefines) to the Include options for the project using the IDE. And at least that didn't barf at me, even without having the option defined in the dproj. The commandline the IDE produced from this was:
...rad studio\7.0\bin\dcc32.exe --no-config -B -Q -DDEBUG;DUNIT; -E....
Which seems to indicate that the $(ExtraDefines) got eliminated as it had no value. And that it should be picked up using MSBuild and specififying a value on the command line.
Almost 5 years later, but all answers are not quite elegant ))
Recently, I've faced the same problem
And here is the solution:
Usually, DCC_Define is defined in a .dproj file like this:
<PropertyGroup Condition="'$(Cfg_1)'!=''">
<DCC_Define>boo;$(DCC_Define)</DCC_Define>
We all have tried to define DCC_Define via /property:DCC_Define=blah-blah
But accordingly to How to: Build the Same Source Files with Different Options:
The property value that is specified on the command line takes precedence over any value that is set for the same property in the project file, and that value in the project file takes precedence over the value in an environment variable.
So, failure (that is the question here!)
BUT! How to: Use Environment Variables in a Build
To use an environment variable in an MSBuild project
Reference the environment variable the same way you would a variable declared in your project file. For example, the following
code references the BIN_PATH environment variable:
<FinalOutput>$(BIN_PATH)\MyAssembly.dll</FinalOutput>
So, we must define environment variable with the name DCC_Define and values of our ADDITIONAL conditionals
> set DCC_Define=hoo;doo;moo;foo
and then simply run
> msbuild boohoo.dproj /p:Config=Release
DCC32 will get then -Dboo;hoo;doo;moo;foo
Straightforward solution is to create a new build configuration (say, boohooRelease), add both boo and hoo conditional defines to it and compile as msbuild boohoo.dproj /p:Config=boohooRelease. Not exactly what you are trying to do, but it works.
I just tried the following and it worked, so don't know whether Microsoft has changed it:
msbuild "myApp.dproj" /t:build /property:DCC_Define="boo"
remember to add the double quote "", otherwise it won't work
Another way is to create a wrapper project file like this:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Full" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Full">
<CreateProperty Value="$(DCC_Define);$(ExtraDefines)">
<Output TaskParameter="Value" PropertyName="DCC_Define"/>
</CreateProperty>
</Target>
<Import Project="example.dproj" />
</Project>
and invoke like this:
msbuild.exe "/t:Clean;Full;Build" "/p:config=Debug" /p:ExtraDefines=SOME_DEFINE wrapper.proj
It is certainly less elegant but you don't have to modify the .dproj file.
In the Delphi IDE, the path to the Delphi installation is specified as $(DELPHI). I am wondering if there is a way to create my own path indicators, such as $(MY_LIBRARY) or something similar. I thought $(DELPHI) was specified as an environment variable, but apparently not. Any ideas? (I'm using Delphi 7)
In Delphi 2010:
select Tools -> Options
select "Environment Variables"
specify either System, either User variable
For Delphi 5 you can add them from windows Environment variables
right click on My computer > properties > advanced > Environment variables
In Delphi 2010:
I know many of the XML tags in the Project.dproj can be used like this. (For exemple, $(DCC_DcuOutput), $(DCC_ExeOutput)...).
Maybe it is possible to add your own XML tags in the file and use them afterward. Though I'm not sure if they'll be preserved by the IDE.
Also of note is when your using the command line compiler, the file RSVARS.BAT located in the BIN directory of the current Delphi installation is what creates some of the environment variables for child processes. (for example BDS and BDSCOMMONDIR).
In Windows 7 (and Vista is similar) click the 'start' button, right-click 'computer', 'properties' and then 'advanced system settings'. Click 'Environment variables' and you're now able to create new ones as global (system), or just for the current user (you). For example 'MyVar'.
Now in a delphi path, refer to MyVar as $(MyVar).
MyVar will now be visible in batch files too as %MyVar%.
There is an alternative workaround -- use SUBST to assign a virtual drive letter to the root of the folder you would be using $(MyFiles) if you could and then just use that.
For Example if you have files in deep directory, you'd go to the command prompt and type:
SUBST M: "C:\users\Me\Delphi Files\My Components"
and then you could refer to it by M:
currently I'm trying to port a million-sloc legacy project from dull .cmd scripts to SCons. Parts of it are VC++, others are Delphi. Creating SConscripts for the C++ pieces was a breeze.
To build the delphi part I've written a very simple builder which detects whether it is a program or library project. Calling the builder after chaining via SConscript makes scons to call dcc32 $subdir/project.dpr what misleads dcc32 to look for units in the current directory instead of the $subdir.
Is there a way to tell scons to enter the $subdir before executing commands residing in the sconscript or should I fix it within the builder?
Thank you in advance
SCons already changes to the directory of sub-directory SConscripts when reading them, so it looks like the problem is going to have to be fixed in the actual builder.
Once the scripts are parsed, and SCons is running the build commands, it stays in the top-level directory. Commands are then issued using path names relative to that top-level directory. The way to change this behavior is to use the chdir keyword in your Builder.
The example from the scons man page is as follows:
b = Builder(action='build < ${SOURCE.file} > ${TARGET.file}',
chdir=1)
env = Environment(BUILDERS = {'MyBuild' : b})
env.MyBuild('sub/dir/foo.out', 'sub/dir/foo.in')
You need to specify the .file component as the use of chdir does not change the names passed to the builder, i.e. they are still relative to the top-level directory.