Does it take -style=LLVM or -style=file as the default one?
Here is an example of the command, and I wonder how does it behave:
clang-format-4.0 -i path/to/file/to/format.cpp
If -style is not specified, the default is -style=file. If no .clang-format file can be found, the default behavior is the same as -style=LLVM. Unfortunately, the documentation doesn't specify this.
Related
In my .ini file I have
[behave]
format=rerun
outfiles=rerun_failing.features
So I want to use "rerun_failing.features" file for storing scenarios that fail.
However when I run '--steps-catalog' command, it also stores that catalog to the same file. Why is that?
How to make set up two separate files for commands '--rerun' and '--steps-catalog'?
Thanks!
Use behave --dry-run -f steps.catalog ... instead. The output of the steps.catalog formatter is written to stdout, not the "rerun-outputfile".
I would like to set up a cmake script with some options (flags and strings). For some of the options I would like to use environment variables as a default. Basically, I'm trying to emulate something like MY_OPTION ?= default in a Makefile. I tried the following:
project (Optiontest)
option(MY_OPTION
"Documentation"
$ENV{MY_OPTION}
FORCE)
message("value: ${MY_OPTION}")
I called this in the following way:
$ cmake -DMY_OPTION=ON .
value: ON
$ cmake -DMY_OPTION=OFF .
value: OFF
$ MY_OPTION=OFF cmake .
value: OFF
$ MY_OPTION=ON cmake .
value: OFF
My problem is that the last line should be ON as well.
For bonus karma: I would actually prefer three levels of preference. The value of -DMY_OPTION should be used if given. If not, the value of a set environment variable MY_OPTION should be used. If this is also not set, a constant should be used. I guess, I could use a bunch of nested if statements and somehow check if the variables are set, but I don't know how and I hope there is a better way.
FORCE is (as of CMake 3.0.2) not a valid parameter for option.
This is the primary source of problems. CMake will interpret the string FORCE as the desired initial value of the option in absence of an environment variable. The usual contrived rules for string-to-truth-value-conversion apply, resulting in the option being set to OFF by this call.
Second, you need to account for the fact that the environment variable is not set. Your current code misses to handle that case properly. $ENV{MY_OPTION} will evaluate to the empty string in that case. If you evaluate the set values in both the cache and the environment, you can enforce any behavior that you want.
In general, you should think about what you actually want here. Usually, FORCE setting a cached variable is a bad idea and I would not be surprised if you found your initial argument for doing this flawed after some careful reevaluation.
Maybe value of MY_OPTION cached in CMake cache? Do you try to clean cmake cache after third call MY_OPTION=OFF cmake .?
I would like that when I run cmake for a certain CMakeLists.txt the "--warn-uninitialized" and "--warn-unused-vars" options are automatically turned on without actually typing those options.
How could I do that?
Thank you a lot!
I think your best bet would be to create an alias:
alias mycmake='cmake --warn-uninitialized --warn-unused-vars'
I found the following code snippet on the internet, and want to use it in my own .vimrc.
augroup CodeFormatters
autocmd!
autocmd BufReadPost,FileReadPost *.py :silent %!PythonTidy.py
augroup END
However, I'm not quite sure where to put the PythonTidy.py script, so that it is accessible from everywhere.
Furthermore I read that using BufReadPre is better than BufReadPost, respectively FileReadPre, is that true?
As it stands, PythonTidy.py must be accessible through your PATH. If you have a convenient place already contained in there, e.g. ~/bin, just place it there.
Alternatively, you can place it somewhere into your .vim directory, and use something like expand('<sfile>:p:h') to resolve the directory of your Vimscript, and build a relative path from there.
As you want to filter the read buffer contents with the :%! command, you have to use the BufReadPost event; with BufReadPre, the buffer hasn't yet been read and nothing would be sent to the filter.
PythonTidy is a command line executable: put it somewhere in your $PATH.
You can also put it anywhere and use an absolute path in the autocmd:
autocmd BufReadPost,FileReadPost *.py :silent %!/path/to/PythonTidy.py
I'm running msbuild from the command line with the following:
msbuild mysolution.sln -p:outputdir=c:\mydir
When I run this, the outputdir is being ignored and the default specified in the csproj file is being used.
The MSDN doc for this tool says that I should be able to override the build directory using this parameter. What am I doing wrong?
You should use OutputPath and more important you should use the right syntax :
msbuild mysolution.sln /p:OutputPath=c:\mydir
Note that OutputPath is preferred over OutDir. The documentation used to be wrong about this, but I see that they've finally fixed it.
Beyond that, it's difficult to say exactly what the problem is, since you didn't show the exact path that you're passing as a parameter. There are two possible problems that I can imagine:
The OutputPath option specifies the path to the output directory relative to the project directory. That means you can't set it to a global path like C:\mydir. I assume it is unable to find the path you specified, and so it defaults to the one specified in your project file.
If the path that you're actually specifying as a parameter contains spaces, the command is likely to fail. I believe you need to wrap the path in quotes and append an extra backslash to the end of the path string.
I believe you should be using OutputPath.