What is the definition of what is output at the different levels of MSBuild build output verbosity?
Quiet
Minimal
Normal
Detailed
Diagnostic
There exists the same question on social.msdn:
Quiet: only shows the result of your build.
Minimal: shows some configurations of your msbuild, and the CSC task.
Normal: This will show all the targets and its mainly steps.
Details: In addition to normal, this flag shows the task and it's implementation within the each target.
Diagnostic: Contains all the information that a MSBuild need and produce, it's switches, parameteres, prerequisites and etc. The input parameter of the target and task, and also contains the value of the input and output parameter, the detail steps of the task execution. The time execution for each task.
See how default logger uses verbosity here.
From learn.microsoft.com
Verbosity Settings
The following table shows how the log verbosity (column values) affects which types of message (row values) are logged.
Something that I could not find in the MS docs, but worked out through experimentation: at -v:m (i.e. minimal verbosity) you can still get the cmd for each step echoed by adding -clp:ShowCommandLine. That combo is substantially quieter than -v:n ("normal" verbosity, i.e. the default), but still gives you the cmd echo. At -v:q however, there's no cmd echo even with -clp:ShowCommandLine added. Sadly, -v:q doesn't actually suppress the tool banner of msbuild itself, you also have to add -nologo for that. (See my answer to another Q for the experiments/details on this affair.)
Also, as someone else discovered: at minimal and quiet verbosity you'll get no stdout from the tools, meaning msbuild suppresses that passthrough, otherwise present at normal and above verbosity. I'm not sure about stderr output from the tools, i.e. whether -v:m suppresses that too or if you need -v:q to suppress stderr passthrough. That needs an additional experiment...
Related
I use CMake version 3.16.
I tried the following:
set_property(TARGET ${PLUGIN_NAME} PROPERTY VS_GLOBAL_FR_VERSION
$<$<CONFIG:Debug2017>:"2017">
$<$<CONFIG:Release2017>:"2017">
$<$<CONFIG:Debug2018>:"2018">
$<$<CONFIG:Release2018>:"2018">
$<$<CONFIG:Debug2019>:"2019">
$<$<CONFIG:Release2019>:"2019">
)
And it kind of worked...
This variable (FR_VERSION) is supposed to be used in a script that is launched after build. This is how it looks:
add_custom_command(TARGET ${PLUGIN_NAME} POST_BUILD
COMMAND echo $(FR_VERSION)
COMMENT "This command will copy files to dist"
VERBATIM
)
In Visual Studio, however, we got the following:
echo $<$<CONFIG:Debug2017>:"2017">;$<$<CONFIG:Release2017>:"2017">;$<$<CONFIG:Debug2018>:"2018">;$<$<CONFIG:Release2018>:"2018">;$<$<CONFIG:Debug2019>:"2019">;$<$<CONFIG:Release2019>:"2019">
which fails to execute with the error message:
"The syntax of the command is incorrect."
If I don't try to set a different value for different build configs like this:
set_target_properties(${MAYA_PLUGIN_NAME} PROPERTIES VS_GLOBAL_FR_MAYA_VERSION "2018")
then the post-build script is generated as expected. (But this is not acceptable to me, because I need different parameter values for different build configurations).
I would appreciate any advice at this point.
Some target properties support generator expressions, while others do not. The documentation for a property will explicitly say that generator expressions are supported. Take the COMPILE_FEATURES property, for example:
Contents of COMPILE_FEATURES may use “generator expressions” with the syntax $<...>.
The documentation for VS_GLOBAL_<variable> does not have such language. Thus, as suggested, you can put the generator expression directly in the add_custom_command() call, which is supported:
add_custom_command(TARGET ${PLUGIN_NAME} POST_BUILD
COMMAND echo $<$<CONFIG:Debug2017>:"2017">
$<$<CONFIG:Release2017>:"2017">
$<$<CONFIG:Debug2018>:"2018">
$<$<CONFIG:Release2018>:"2018">
$<$<CONFIG:Debug2019>:"2019">
$<$<CONFIG:Release2019>:"2019">
COMMENT "This command will copy files to dist"
)
I have a TeamCity build that passes some arguments to an .exe and runs it daily. One argument is for a date parameter, currently set to a static date. It now needs to be dynamic, passing in the current date.
I tried setting the value to %env.BUILD_START_DATE% but this makes all my agents incompatible because of an implicit requirement for that env variable. I also tried setting the date in the DOS command line script, skipping TC params altogether, but it still ends up with that implicit requirement.
The top answer here: TeamCity Current Date variable in MMdd format
indicated need for a TC plugin, the second answer, however, did not require a plugin and is mostly complete. How I made it work on a variation of that second answer:
1.) Add a powershell build step to run the following:
echo "##teamcity[setParameter name='env.BUILD_START_DATE' value='$([DateTime]::Now)']"
2.) Give env.BUILD_START_DATE a default value in the Environment Variables section. Without the default value TC thinks having this value is an implicit requirement of a build agent, rendering all of them incompatible.
If you are unfamiliar with PowerShell, here is a Bash approach.
You can set a parameter with script and retrieve the value from the next build step.
echo "##teamcity[setParameter name='env.BUILD_START_DATE' value='$(date +%%Y-%%m-%%dT%%H:%%M:%%S%%z)']"
The doubled %% is because TeamCity considers % as its own parameter in build script.
The parameter will have ISO8601 format timestamp. For other formats, please see various Bash date format at here; https://www.tutorialkart.com/bash-shell-scripting/bash-date-format-options-examples/
You can set the variable in the config, which should be overridden during runtime. I don't see env.BUILD_START_DATE in my TC parameters, but I do see system.buildStartTime. I set it to a dummy value (I use "[Filled Automatically]"), and everything works fine. Build gets run and system.buildStartTime gets overridden at build time.
I have some JMeter tests, and they take different amounts of time. I'd like to change the granularity of the reports without having to change the reportgenerator.properties file. I read the documentation about generating reports, and I'm still not clear. Do I do it something like -Jreportgenerator.properties.overall_granularity=10000?
Can/How do I do this?
Actually, I found that the following worked for me in JMeter 3.2.....
jmeter.bat -Jjmeter.reportgenerator.overall_granularity=1000 -g testresults.jtl -o dashboard
This sets the granularity to 1 second for my report.
And another example,to give the report a granularity of 1 second and a different title e.g. My Report
jmeter.bat -Jjmeter.reportgenerator.overall_granularity=1000 -Jjmeter.reportgenerator.report_title="My Report" -g testresults.jtl
-o dashboard
First of all, here's a cite from the aforementioned file:
THIS FILE SHOULD NOT BE MODIFIED
This avoids having to re-apply the modifications when upgrading JMeter
Instead only user.properties should be modified:
1/ copy the property you want to modify to user.properties from here
2/ Change its value there
Then, -D option overrides system property for JVM, that should look like
-Dreportgenerator.properties.overall_granularity=10000
you may add it stright to the command line when starting JMeter with standard script provided.
As far as I know, usually for JVM running JMeter the genuine configuration properties are looking exactly like this (system properties), so application of -D option must work.
Here's the kind of a proof from official properties reference:
The properties present in jmeter.properties or
reportgenerator.properties should be set in the user.properties file.
These properties are only taken into account after restarting JMeter
as they are usually resolved when the class is loaded.
So that must be working, come back if not. :-)
UPDATE:
It turns out, the property name has been misspelled by topicstarter, the correct name is:
-Djmeter.reportgenerator.overall_granularity=10000
./jmeter.sh -Jjmeter.reportgenerator.overall_granularity=1000 -g /path/to/jtl/file -o /where/you/want/to/store/dashboard
This works perfectly in JMeter 4.0 and 5.0
I have a script which collected together a number of files to be installed. This includes a number of empty directories.
Previously I would use the D flag in the manifest file which would copy empty directories. However due to the way I generate the manifest files (as part of our build process) I can sometimes end up with two D entries with the same destination folder. e.g:
D;${A_LIB}/all/pysys/${PYSYS_VERSION}/lib/python2.7/site-packages;./third_party/python/lib/python2.7/site-packages;COMMON;${UNIX}
D;${A_LIB_BT}/python/${PYTHON_VERSION};./third_party/python;COMMON;${ALL}
This causes InstallAnywhere to fail to build the installer.
To get around this I rewrote the manifest generation code to parse the directories previously pointed to by a D and replace the D entry with F entries for each file in the directory.
Unfortunately this will not include empty directories (which we may / may not need in the installer but in general it's just safer to create them than have some piece of code fail because they're not there).
I've tried the following in the manifest. Reference, Reference3 and Reference4 are empty, Reference2 contains a single directory (which is itself empty). Only Reference2 is present in the install - the other three which are empty directories seem to get excluded.
D,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference,./samples/pysys/cor_002/Reference
D,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference2,./samples/pysys/cor_002/Reference2
D,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference3/.,./samples/pysys/cor_002/Reference3/.
D,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference4/../Reference4,./samples/pysys/cor_002/Reference4/../Reference4
I've also tried increasing the log level but this has not revealed anything. Is there a way to increase this log level?
export LAX_DEBUG=true
Any suggestions?
DISCLAIMER: I've cross posted this to InstallAnywhere's forums but I will do my best to keep the answers in sync and spread the knowledge.
I can't speak to your manifest challenges. However, my first thought is to change the manifest generator to be sensitive to duplicate output locations -- maybe by storing them in a Map or Set -- and then handling collisions when they occur by failing the build or adjusting the output location(s).
On the other hand, I can tell you how to increase the verbosity of your installer.
Make the installer more verbose by adding:
-Dlax.debug.all=true -Dlax.debug.level=3
to Project > JVM Settings > Installer Settings (tab) > Optional Installer Arguments > Additional Arguments. You'll want to remove these before you ship. You can also add these to the command line when you start the installer. Level values of 4 and 5 work, too, and are even more verbose.
You can also make your installer print its progress to the console by going to Project > JVM Settings > Log Settings. Here, uncheck Include debug output (stderr and stdout). Then enter the word console in Send stderr to: and Send stdout to:. Rather than console, you can also set a specific file name. You'll also want to undo these settings before you ship.
The solution turns out to be so blindingly simple that I never tried it.
To get EMPTY directories installed by Install Anywhere you have to specify the directories as files in the manifest. So with the following directory structure:
Reference <empty>
Reference2
testdir <empty>
Reference3 <empty>
Reference4 <empty>
You need to specify the entries in the manifest as F. Specifying then as D will only result in the "Reference2" directory being included.
F,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference,./samples/pysys/cor_002/Reference
F,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference2,./samples/pysys/cor_002/Reference2
F,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference3/.,./samples/pysys/cor_002/Reference3/.
F,$IA_PROJECT_DIR$/samples/pysys/cor_002/Reference4/../Reference4,./samples/pysys/cor_002/Reference4/../Reference4
Sorry to answer my own question, really wasn't the plan!
I'm using Sphinx on Windows.
Most of my documentation is for regular users, but there are some sub-pages with content for administrators only.
So I want to build two versions of my documentation: a complete version, and a second version with the "admin" pages excluded.
I used the exclude_patterns in the build configuration for that.
So far, it works. Every file in every subfolder whose name contains "admin" is ignored when I put this into the conf.py file:
exclude_patterns = ['**/*admin*']
The problem is that I'd like to run the build once to get both versions.
What I'm trying to do right now is running make.bat twice and supply different parameters on each run.
According to the documentation, I can achieve this by setting the BUILDDIR and SPHINXOPTS variables.
So now I have a build.bat that looks like this:
path=%path%;c:\python27\scripts
rem BUILD ADMIN DOCS
set SPHINXOPTS=
set BUILDDIR=c:\build\admin
call make clean
call make html
rem BUILD USER DOCS
set SPHINXOPTS=-D exclude_patterns=['**/*admin*']
set BUILDDIR=c:\build\user
call make clean
call make html
pause
The build in the two different directories works when I delete the line set BUILDDIR=build from the sphinx-generated make.bat file.
However, the exclude pattern does not work.
The batch file listed above outputs this for the second build (the one with the exclude pattern):
Making output directory...
Running Sphinx v1.1.3
loading translations [de]... done
loading pickled environment... not yet created
Exception occurred:
File "C:\Python27\lib\site-packages\sphinx-1.1.3-py2.7.egg\sphinx\environment.
py", line 495, in find_files
['**/' + d for d in config.exclude_dirnames] +
TypeError: coercing to Unicode: need string or buffer, list found
The full traceback has been saved in c:\users\myusername\appdata\local\temp\sphinx-err-kmihxk.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>.
What am I doing wrong?
Is the syntax for exclude_patterns in the sphinx-build command line different than in the conf.py file?
Or is there a better way to build two different versions in one step?
My first thought was that this was a quoting issue, quoting being notoriously difficult to get right on the Windows command line. However, I wasn't able to come up with any combination of quoting that changed the behavior at all. (The problem is easy to replicate)
Of course it could still just be some quoting issue I'm not smart enough to figure out, but I suspect this is a Sphinx bug of some kind, and hope you will report it to the Sphinx developers.
In the meantime, here's an alternate solution:
quoting from here:
There is a special object named tags available in the config file. It can be used to query and change the tags (see Including content based on tags). Use tags.has('tag') to query, tags.add('tag') and tags.remove('tag') to change
This allows you to essentially pass flags into the conf.py file from the command line, and since the conf.py file is just Python, you can use if statements to set the value of exclude_patterns conditionally based on the tags you pass in.
For example, you could pass Sphinx options like:
set SPHINXOPTS=-t foradmins
to pass the "foradmins" tag, and then check for it in your conf.py like so:
exclude_patterns = blah
if tags.has('foradmins'):
exclude_patterns = []
That should allow you to do what you want. Good Luck!