I am using Atlassian's Bamboo to build a project, and the way I'm doing it asks for the executable and any parameters I want to send to it. Therefore, this is not a batch file. When the executable finishes, it sets the error level to 1, indicating "warnings" in compilation. I really could care less about these warnings, but Bamboo sees the ERRORLEVEL=1 and fails the build.
Basically, what I'm after is to be able to call a "failing" command, AND reset ERRORLEVEL in the same line. Basically...
set %ERRORLEVEL%=1 THEN set %ERRORLEVEL%=0
I have a really bad feeling that this isn't possible...and I also don't think it is possible to set the compiler to ignore warnings from the command line. Therefor, I need to change how Bamboo is building this project.
Related
New to CMake. When adding libraries I see a lot of instructions saying do this:
cmake -D OPENSSL_ROOT_DIR=/usr/local/opt/openssl
Why is that preferred over putting it in the actual CMakeLists.txt? e.g.
set(OPENSSL_ROOT_DIR "/usr/local/opt/openssl")
You do not commit the first one to the repository while you either commit the second one or have to be careful to not commit it with other stuff.
The second method is usually used to allow users of some project to modify some aspect of that project. So whatever pertains to the project itself (not customizable) goes straight to the CMake files everything else might be provided from the command line.
Note, also, that the CMake presets add an ability to customize the build outside the CMake files so the method of providing variables directly via a console call is something I'd expect going away and getting replaced with presets. But the way they work is still the same: variables defined in the preset get to CMake cache with generated console call (with an IDE it might be different).
Specifically I'm looking for an example to do what is stated in the cmake documentation for add_custom_command:
If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script. (To run a full script, use the configure_file() command or the file(GENERATE) command to create it, and then specify a COMMAND to launch it.)
A little more detail without bulking this up too much: There's an external program that generates 3 source files that get compiled later. The generation program only updates the timestamp on the files it changes, not all files. So even though my DEPENDS timestamp is newer, it may not need to change 1 of the source files and thus cmake tries to run the code generator each time. I want to touch all the files at the end of the code generation so that ALL their timestamps get updated.
What is the process to run COMMANDS in add_custom_command in order?
EDIT:
This is what I'm currently trying to do:
add_custom_command(
OUTPUT
${CONFIG_TOOLS_GENERATED_FILES}
COMMAND if exist ${Application_SOURCE_DIR}/..MCUExpresso/board rmdir ${Application_SOURCE_DIR}/..MCUExpresso/board
COMMAND
"${MCU_CONFIG_TOOLS_DIR}/bin/eclipsec.exe" -noSplash
-Load ${MEX_FILE}
-HeadlessTool Pins -ExportSrc "${Application_SOURCE_DIR}/../MCUExpresso"
-HeadlessTool Clocks -ExportSrc "${Application_SOURCE_DIR}/../MCUExpresso"
-HeadlessTool Peripherals -ExportSrc "${Application_SOURCE_DIR}/../MCUExpresso"
DEPENDS ${MEX_FILE}
COMMENT "Generating source files using MCU Config Tools"
)
There are two issues here - the directory I'm trying to remove (with the generated code) could end up getting deleted after the code generation runs since the commands aren't stateful. Secondly, the directory doesn't actually get deleted - seems like it's a pathing problem with windows...
I understand that cmake is build generator. It mean that it can generate appropriate builds (makefiles, Visual Studio project etc.) based on instructions from CMakeLists.txt. But I do not understand two things which I guess are related:
Why there are two buttons "Configure" and "Generate" in cmake-gui? In command line tutorials that I've read (e.g. this one) usual process was done with one cmake command.
What is cache in cmake world? AFAIK it is state when "Configure" button was pressed but "Generate" button was not pressed. But why is this useful? What all those variables that pops-up after pressing "Configure" mean? Why I'm supposed to edit them? Isn't the only allowed configuration done via CMakeLists.txt?
Thanks
There are two stages when CMake is run, as reflected by the two buttons in the CMake GUI. The first stage is the configure step where the CMakeLists.txt file is read in. CMake builds up an internal representation of the project during this stage. After that, the second stage called generation occurs where the project files are written out based on that internal representation.
In CMake GUI, the two stages can be run separately. When you run the configure step, the GUI shows all cache variables (see below) which changed their values since the last time configure was run or since CMake GUI was started if this is the first configure run. Normal practice is to re-run the configure stage until no variables are highlighted red. Once configure leaves no variables in red, you can press the generate button and the build tool's native project files will be created and you are good to go starting your builds, etc.
The command line cmake tool doesn't allow you to separate out running the configure and generate steps individually. Rather, it always runs configure and then generate.
For simple projects, the distinction between configuration and generation is not all that important. Simple tutorials will often just lump the two together since the reader can get away without understanding the distinction for basic project arrangements. There are, however, some CMake features which rely on this distinction. In particular, generator expressions are a generation-time feature where decisions about certain aspects of the build are delayed to generation time rather than being fully handled at configure time. One example of this is configuration-specific content such as compiler flags, source files only compiled in for some configurations, etc. The build configuration isn't always known at CMake's configure step (e.g. Xcode and Visual Studio are multi configuration build tools, so there can be more than one and it is selected by the user at build time). The generation step will process generator expressions for each build type and the result can be different for each configuration. You might also find this answer informative regarding this particular example. For a more advanced example of a technique which takes advantage of the distinction between configure and generation stages, see this post, but be aware it is not a common technique.
Regarding your other question about what is the cache, CMake records information between runs in the variable cache. At the end of the run, it updates a file called CMakeCache.txt in the build directory. When you next run CMake, it reads in that cache to pre-populate various things so it doesn't have to recompute them (like finding libraries and other packages) and so that you don't have to supply custom options you want to override each time. You wouldn't typically edit CMakeCache.txt by hand (although it's okay to do so). Rather, you can modify the variables you want in CMake GUI and then re-run the configure step (don't forget to then also run generate to create updated project files). You can also define or modify cache variables at the cmake command line with the -D option.
I am using the TeamCity Visual Studio runner. I want to add a setting that is not accessible from Visual Studio.
/Property:FileAlignment=4096
I typed that directly into the build step "Command line parameters." The build log shows the error:
MSBuild command line parameters contains "/property:" or "/p:" parameters. Please use Build Parameters instead.
I don't understand how to provide this to MSBuild from TeamCity and get rid of this warning!
1. Which kind of parameter should I use?
There are 3 kinds:
Configuration parameters
System properties
Environment variables.
I don't want an environment or system variable because I don't want this build to depend on anything external. I am going to try Config right now, but then I'm not sure I'm filling it in right.
2. How can I tell this parameter is actually getting used?
The build log, which seems only to have navigable/foldable xml-like levels with their program, did not say the build parameters.
You should use "System properties". Don't worry about the name, that's just how TeamCity calls it. They are regular properties. You can add them in "Edit Configuration Settings > 7. Build Parameters".
For example, you can add the system property as follows:
Name: system.FileAlignment
Type: System property (system.)
Value: 4096
Note that TeamCity will insist on the "system." prefix. It doesn't matter because the MSBuild script will still see it as $(FileAlignment).
The TeamCity documentation defines Build Parameters as "a convenient way of passing generic or environment-specific settings into the build script". Configuration parameters provide a way to override some settings in a build configuration inherited from a template. They are never passed to a build. System and Environment parameters are provided to your build script. Environment variables are actually set on the system (I can't find any documentation for this). System parameters are passed to the script engine.
TeamCity automatically provides System variables to the actual command line (it looks like the Visual Studio runner runs msbuild.exe and not devenv.exe). I guess that TeamCity is constructing a command like
cmd> msbuild.exe my-solution.sln /p:FileAlignment=4096
I tried this on my command line, just to make sure that it should work (I added the /v:diagnostic flag). The diagnostic verbosity makes msbuild print all of it's properties to the console. I verified that FileAlignment=4096 was in there.
That /FileAlignment property appears to be a special property that's automatically in any .csproj file. So you should be good to go. You can check the actual parameters that were passed to the build by clicking on any build and viewing the 'Build Parameters' tab. There's a section that shows the "Actual Parameters on Agent".
This was solved. To clarify, Anthony told how to solve the problem in the commandline using MSBuild. It can also be solved on the commandline using devenv, per a ticket with Microsoft, the syntax is:
devenv ..\..\mysolution.sln /Rebuild /Property:Config=Release;Platform=AnyCPU;Filealignment=512
What I wanted, however, was to get Teamcity's "Visual Studio Build" to accept the parameter. This was achieved as follows. In the box for Command line parameters, I entered:
/Property:FileAlignment=filealignment v:diag
Then the output tab for Build Parameters shows:
User Defined Parameters
Name Value passed to build
system.filealignment 512
system.verbosity diagnostic
(This is -754 chars for a comment so must be typed as a post)
hi Anthony, Thank you for replying!
Yes, msbuild on the commandline works fine for me as well and project files may store FileAlignment properties. In our case, upon discussion with Microsoft, it appears necessary that I specify the solution-wide aka build-wide alignment, ie in the command arguments, in addition to fixing the projects (which I have already done).
No parameter that I specify on the GUI item ( /Build Step / Command line parameters/ ) will appear on the tab /Build Parameters/. Of course some will not compile at all.
Also I have even more weird behavior where using
/verbosity:diagnostic
vs
/verbosity:minimal
causes a longer build log for the minimal! It appears diagnostic is hiding the details inside of a special task, which is part of Teamcity and not me;
[16:24:05]: Overriding target "SatelliteDllsProjectOutputGroup" in project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" with target "SatelliteDllsProjectOutputGroup" from project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets".
I am struggling with this because the Teamcity-generated build output log is so nice to have as a TreeView. That works with the SLN build but using any bat file cannot produce log file with the pretty (xml, presumably) tree-format.
If you have further ideas I will love to hear them, and thank you for your edits! :)
I have a Hudson job that runs a maven goal. Before this maven goal is executed I have added a step to run before the build starts, it is a shell script that obtains the version number that I want to use in the 'Goals and options' field.
So in my job configuration, under Build Environment I have checked the Configure M2 Extra Build Steps box and added a shell script before the build. The script looks like this:
export RELEASE={command to extract release version}
echo $RELEASE
And then under the Build section I point to my 'root pom'. In the Goals and options I then want to be able to do something like this:
-Dbuild.release.version=${RELEASE} deploy
Where build.release.version is a maven property referenced in the POM. However since the shell doesn't seem to make its variables global it doesn't work. Any ideas?
The only one I have is to install the Envfile plugin and get the shell script to write out the RELEASE property to a file and then get the plugin to read the file, but the order in which everything is run may cause problems and it seems like there must be simpler way...is there?
Thanks in advance.
I recently wanted to do the same, but AFAIK it's not possible to export values from a pre-build shell to the job environment. If there is a Hudson Plugin for this I've missed it.
What did work, however, was a setup similar to what you were suggesting: having the pre-build shell script write the desired value(s) to a property-file in the workspace, and then using the Parametrized Trigger Plugin to trigger another job that actually does the work (in your case, invoke the Maven job). The plugin can be configured to read the parameters it passes from the property file. So the first job has just the shell script and the post-build triggers, and the second one does the actual work, having the correct parameters available as environment variables.
General idea of the shell script:
echo "foo=bar
baz=`somecmd`" > build.properties
And for your Goals and options, something like:
-Dbuild.release.version=${foo} deploy
Granted, this isn't as elegant as one might want but worked really well for us, since our build was broken into several jobs to begin with, and we can actually reuse the other jobs that the first one triggers (that is, invoke them with different parameters).
When you say it doesn't work, do you mean that your RELEASE variable is not passed to the maven command? I believe the problem is that by default, each line of the shell script is executed separately, so environment variables get lost.
If you want the entire shell script to execute as if it was one script file, make the first line:
#!/bin/sh
I think this is described in the Help information alongside the shell script build step (and if I'm wrong, that's a good place to look for the right syntax).