In the Your First Script guide to Premake 5, there's a line:
targetdir "bin/%{cfg.buildcfg}"
It's clear from context that %{cfg.buildcfg} substitutes in the build configuration eg. Debug. But is this documented anywhere? Is there a list of other namespaces and names I can use eg. the workspace build directory?
Those are called value tokens. In the wiki you can find a list of the ones available https://github.com/premake/premake-core/wiki/Tokens
Related
We have one ASP.Net solution with several projects. each project have build.pubxml with unique folder path.
For example:
In project Test we have this line inside the build.pubxml:
<publishUrl>C:\publish\SolutionName\Test</publishUrl>
In project Exam we have this line inside the build.pubxml:
<publishUrl>C:\publish\SolutionName\Exam</publishUrl>
In the build pipeline (in TFS) with have MSBuild step with this argument:
/p:PublishProfile=build.pubxml
After the build we got 2 folders - Test and Exam in C:\publish\SolutionName.
So far so good.
The problem is we have few branches, and we want to separate the publish folder for each branch, so we added .pubxml for each branch and in the build pipeline we specified the correct one. but is make are a lot of work on each new branch created and can cause mistakes.
We tried to pass the /p:publishUrl=C:\publish\BranchName in the MSBuild but then we got a one folder with all the content of Test and Exam and not two folders.
The idea is to have only one .pubxml file for each project with a parameter and pass the value in the pipeline, for example:
<publishUrl>C:\publish\$(Parameter)\Test</publishUrl>
And in the build we will pass the parameter according to the branch.
It is possible to do something like this?
It is possible to do something like this?
The answer is Yes. Since msbuild accepts Global Properties in command-line. If we define one Property in build.pubxml like <publishUrl>C:\PublishFolders\$(BranchID)\xxx(Test,Exam...)</publishUrl>, then we can simply pass the value in msbuild arguments like this:
Then we'll get Test and Exam folders under C:\PublishFolders\NewTest. Also we can choose to pass the pipeline predefined variables to the command like: /p:BranchID=$(Build.SourceBranch)...
This works for build in local machine, tfs and Azure Devops pipeline. Hope all above helps :)
I'm trying to build and deploy ASP.NET web application via TeamCity and WebDeploy.
Before you ask - I found several similar questions, but neither of them worked in my case.
I'm trying to pass TeamCity parameters to MsBuild. I have a build template which defines the parameters as empty, and then build configuration override them.
Tried system properties, but they didn't work for me. What's even worse, TeamCity doesn't log MsBuild parameter values, so I can't take a look at them.
Here's the example of how I pass parameters to MSBuild in my build template:
/property:MsDeployServiceUrl=https://$(deploy_vm_name):8172/MsDeploy.axd /property:DeployIisAppPath=$(deploy_app_name) /property:SkipExtraFilesOnServer=True /property:UserName=$(deploy_username)
/property:Password=$(deploy_password).
According to the documentation, syntax is correct.
Parameters are system.deploy_app_name, system.deploy_username, system.deploy_password, system.deploy_vm_name.
The error message I get - C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4115, 5): Invalid Web Deploy service URL.
I'm using TeamCity version 10.0.2 with MsBuild version 14.
Any suggestions? What did I miss?
So the correct move was to specify system parameters named exactly after MSBuild parameters and then don't mention those parameters in MSBuild step. After I did that, all went fine.
I recognize it's not very flexible solutions since you might have several MSBuild steps, but if anyone knows better one - please share it
I think because you're defining these properties via arguments in a build step, you need to use the typical %teamcity.parameter% syntax where you are using instead the $(msbuild_parameter) syntax.
Or just skip setting them on the command line entirely. You should be able to resolve the system.parameters from TeamCity in the MSBuild script using the $(msbuild_parameter) syntax.
From the documentation you linked:
For MSBuild (Visual Studio 2005/2008 Project Files) use $(). Note that MSBuild does not support names with dots ("."), so you need to replace "." with "_" when using the property inside a build script.
You aren't inside a build script, you're outside the script defining property arguments.
Given a build.sbt which is committed to a code repository, what is a general pattern which allows users to override setting values defined in this script?
On the surface, this appears to have been answered in Where should local settings (per user, and not version-controlled) go in newer (0.10+) versions of SBT?. The answer there is to simply define two scripts in the same directory -- build.sbt and local.sbt, and rely on the fact that sbt will combine these scripts together. This may work for augmenting values (i.e., appending lists), but I don't see how it works for overriding the script value, since if a setting's value is set in both scripts, I don't know which of the two values will survive after sbt has combined the scripts.
It could be that I'm missing something very simple.
I'd recommend using ~/.sbt/0.13 global directory where your .sbt files are processed during project load and after the other files in the project itself.
I found ~/.sbt/0.13/global.sbt a good place for global settings - the name always hints me for its purpose.
Lets say you have a client and a server project where these have some packages in common.
Is it possible to produce two exec files (client, server) from a single Ada project?
Using Ada 2012 with Gnat.
Yes. You can see an example of how to do it in the project files in my LEGO Tools repository. The critical part is to list the relevant compilation units in a "Main" clause in the project file like this:
for Main use ("build_mpd_file",
"fractal_landscape",
"outline_boundaries",
"pgm_to_ldraw",
"split_ldraw_file");
Yes.
There's nothing special about a subprogram that is to be the main portion of the executable. (There are some restrictions though; IIRC it has to be a paramaterless subprogram, and if a function has to return Integer.)
For GNAT, all that's needed is for you to specify which compilation-units are main files.
I use an ivysettings.xml file to configure the repositories to use for sbt, which uses Ivy.
However, it's not able to download a particular snapshot which uses unique naming (i.e. date-based naming). It only tries the patterns listed explicitly in my ivysettings.xml file (which makes sense), so it can't see the details in maven-metadata.xml which tell it the filename of the snapshot jar to download.
I tried specifying the version explicitly instead of as a snapshot in Build.scala:
"com.jolbox" % "bonecp" % "0.8.1-20131105.191813-1"
(which would be my ideal solution, because then it would be cached in our maven repository and I'd be guaranteed to always use the same snapshot), but this generated the wrong URL (there should be an 0.8.1-SNAPSHOT in there, but of course there isn't):
http://maven/nexus/content/groups/softwaretools-snapshot-group/com/jolbox/bonecp/0.8.1-20131105.191813-1/bonecp-0.8.1-20131105.191813-1.pom
I then tried specifying the URL explicitly using from, but this didn't work.
I then tried using latest.integration as the version, but that didn't correctly identify the latest version - it thought it was 0.8.0-rc1, which is clearly wrong.
Download the dependency manually and add it to the lib directory of the project (create it if necessary); remove it from the Build.scala file.