Just when I think I know how the shell works fairly, something comes along and stumps me. The following commands were executed on GNU bash, version 3.2.25.
I have several ./configure scripts that all share a group of common configure options, one of them being CFLAGS.
To that end, I have two variables
CFLAGS="-fPIC -O3"
COMMON_CONFIGURE_OPTIONS="CFLAGS=\"$CFLAGS\" --enable-static --disable-shared --prefix=$PREFIX"
When this gets passed to `./configure', it is done so like,
"$FOO/configure" $COMMON_CONFIGURE_OPTIONS
For the life of me, I cannot seem to get this to expand correctly. I have tried manually substituting the value of $CFLAGS into $COMMON_CONFIGURE_OPTIONS. I have tried every combination of single and double quotes under the sun. I have even tried quoting the entire "CFLAGS=..." argument.
The version I gave above yields the following (when set -x is enabled)
../configure 'CFLAGS="-fPIC' '-O3"' --enable-static --disable-shared --prefix=../install
configure: error: unrecognized option: `-O3"'
Try `../configure --help' for more information
What I expected, and what I desire, is for configure to be invoked like
./configure CFLAGS="-fPIC -O3" --enable-static --disable-shared --prefix="$PREFIX"
How can I achieve what I want, and additionally, are there good resources/tips on how to avoid this problem in the future?
To achieve what you want, I think you want to fundamentally change your approach. Assuming your configure scripts are generated by autoconf, I would suggest using a config.site file. That is, simply do something like:
mkdir -p $PREFIX/share
echo 'CFLAGS="--enable-static --disable-shared"' > $PREFIX/share/config.site
And then invoke configure as:
/path/to/configure --prefix=$PREFIX
Make sure that CONFIG_SITE is not set in the environment when you invoke configure, else the defaults will come from the file named there.
Related
I'm trying to run the command bison file_name.y from PowerShell, but it does not work. the command seems to be executed by the shell in fact the shell returns to ask for input but does not produce any output. I also tried the command bison file_name.y -d but I got the same result. I have checked the system variables and are correctly set. In fact, flex works correctly, for which I followed the same procedure.
I want to use ctest from the command line to run my tests with memcheck and pass in arguments for the memcheck command.
I can run ctest -R my_test to run my test, and I can even run ctest -R my_test -T memcheck to run it through memcheck.
But I can't seem to find a way to pass arguments to that memcheck command, like --leak-check=full or --suppressions=/path/to/file.
After reading ctest's documentation I've tried using the -D option with CTEST_MEMCHECK_COMMAND_OPTIONS and MEMCHECK_COMMAND_OPTIONS. I also tried setting these as environment variables. None of my attempts produced any different test command. It's always:
Memory check command: /path/to/valgrind "--log-file=/path/to/build/Testing/Temporary/MemoryChecker.7.log" "-q" "--tool=memcheck" "--leak-check=yes" "--show-reachable=yes" "--num-callers=50"
How can I control the memcheck command from the ctest command line?
TL;DR
ctest --overwrite MemoryCheckCommandOptions="--leak-check=full --error-exitcode=100" \
--overwrite MemoryCheckSuppressionFile=/path/to/valgrind.suppressions \
-T memcheck
Explanation
I finally found the right way to override such variables, but unfortunately it's not easy to understand this from the documentation.
So, to help the next poor soul that needs to deal with this, here is my understanding of the various ways to set options for memcheck.
In a CTestConfig.cmake in you top-level source dir, or in a CMakeLists.txt (before calling include(CTest)), you can set MEMORYCHECK_COMMAND_OPTIONS or MEMORYCHECK_SUPPRESSIONS_FILE.
When you include(CTest), CMake will generate a DartConfiguration.tcl in your build directory and setting the aforementioned variables will populate MemoryCheckCommandOptions and MemoryCheckSuppressionFile respectively in this file.
This is the file that ctest parses in your build directory to populate its internal variables for running the memcheck step.
So, if you'd like to set you project's options for memcheck during cmake configuration, this is the way to got.
If instead you'd like to modify these options after you already have a properly configured build directory, you can:
Modify the DartConfiguration.tcl directly, but note that this will be overwritten if cmake runs again, since this file is regenerated each time cmake runs.
Use the ctest --overwrite command-line option to set these memcheck options just for that run.
Notes
I've seen mentions online of a CMAKE_MEMORYCHECK_COMMAND_OPTIONS variable. I have no idea what this variable is and I don't think cmake is aware of it in any way.
Setting CTEST_MEMORYCHECK_COMMAND_OPTIONS (the variable that is actually documented in the cmake docs) in your CTestConfig.cmake or CMakeLists.txt has no effect. It seems this variable only works in "CTest Client Scripts", which I have never used.
Unfortunately, both MEMORYCHECK_COMMAND_OPTIONS and MEMORYCHECK_SUPPRESSIONS_FILE aren't documented explicitly in cmake, only indirectly, in ctest documentation and the Testing With CTest tutorial.
When ctest is run in the build, it parses the file to populate its internal variables:
https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client-via-ctest-command-line
It's not clear to me how this interacts with
I am having some trouble running ant. Here is a simplified verison of my problem. I have a shell script script1.sh:
export ANT_HOME=/opt/Ant
ant -version
This works. but when I try create another script script2:
cd /location/of/script1
sudo -E ./script1.sh | tee log.txt
I get the error ant: command not found. Does anyone know why this is happening.
Sounds like you're losing your PATH setting after sudo. Try adding echo $PATH in script1.sh to see the before and after values. Or just define script1.sh as
export ANT_HOME=/opt/Ant
${ANT_HOME}/ant -version
Without knowing what shell, or seeing more of the scripts it's hard to tell exactly what is happening. But if you want script2 to know about ANT_HOME you're probably going to need to source or eval script1. See here. Also I know pipes '|' cause Bash to perform operations within sub-shells which can be problematic under certain circumstances (if you're using Bash).
EDIT:
Double check that you are using the version of ant that you think you are:
#!/bin/bash
# Capital A here seems suspicious to me...
export ANT_HOME=/opt/Ant
echo "`${ANT_HOME}/ant -version`"
Although i had installed pycuda and using it ok,it started (without doing sth) not to work.So,i i tried to do the install again ,but when i am doing
python configure.py --cuda-root=/usr/local/cuda/bin
it gives me the error in the title.
The nvcc file is in the above directory.
pycuda is not finding nvcc. Did you try adding /usr/local/cuda/bin to your env PATH variable? That's the way I have this setup.
Edit:
As far as I can tell the configure.py doesn't call nvcc compiler it just creates the the makefile. I take that this problem happens when you run sudo -c "make install" which calls setup.py.
A couple of things to try. Make sure that you have CUDA_ROOT set:
echo $CUDA_ROOT
If it's empty, set it with:
export CUDA_ROOT=/usr/local/cuda/bin
Try running the make command again. Now with the -E to preserve your env:
sudo -E sh -c "make install"
I encountered the same issue on a Slackware64 13.37.
Install command su -c "make install" switches to root (0bv10u5Ly) thus CUDA_ROOT should be set in the root's profile. CUDA_ROOT is not an environment variable, it's used by the setup.py. Add /usr/local/cuda/bin to PATH and define CUDA_ROOT=/usr/local/cuda/bin then try to install again.
This is the quick and dirty way but if none of above worked out for you like me, below will definitely work. (:
Remove
nvcc_path = search_on_path(["nvcc", "nvcc.exe"])
if nvcc_path is None:
print("*** CUDA_ROOT not set, and nvcc not in path. Giving up.")
sys.exit(1)
and set
cuda_root_default = "/usr/local/cuda/bin"
in setup.py file. Then try su -c "make install".
In my case, I had to set CUDA_ROOT=/usr/local/cuda because with /usr/local/cuda/bin path, it was not able find include folder and it was failing with error didn't find cuda.h.
I'm trying to set an environment variable in a build script with phing.
This is normally done command line like this:
export MY_VAR=value
In Phing I did the following but it isn't working.
<exec command="export MY_VAR=value" />
I see that this is quite an old question, but I don't think it has been answered in the best way. If you wish to export a shell variable, for example say you are running phpunit from phing and want to do an export before invoking phpunit, try:
<exec command="export MY_VAR=value ; /path/to/phpunit" />
Simply do the export and invoke your command inside the same exec tag. Separate the export statement and the shell executable with a semicolon as shown. Your script will be able to access the value using the standard php function:
$myVar = getenv('MY_VAR');
Bold claim: There is no way to set/export a (Unix) shell variable in PHP so that it is visible inside the scope that started the php script.
php myfile.php (does putenv or shell_exec('export foo=bar');)
echo $foo
Will return nothing.
As PHP can not do it so neither can phing.
Accessing shell environment variables accross multiple script runs (if its that what you want) seems also like an unideal design decision, pretty stateful.
Apart from that I'd urge you to stick to phing and learn its lean lesson. Phing helps stateless thinking to some degree.
I'd never heard of phing before, but this looks very promising as a build tool. Thanks for posting! I looked through the doc on phing.info, I found the following possibility:
#0 I would like to clarify one point. Are you saying that
prompt$ > export MY_VAR=value
prompt$ > phing build.xml
doesn't set MY_VAR to value so it is visible inside the running phing processes? I'd be surprised, but I would understand if this is not how you want to run your build script.
#1 I think in the context of a build tool, a feature like exec is meant to run a stand-alone program, so, while the exec may run and set MY_VAR, this is all happening in a subprocess that disappears immediately as the exec finishes and continues processing the next task in the build.xml.
If you're just trying to ensure that your phing script runs with specific values for env_vars, you could try
Command-line arguments:
....
-D<property>=<value>
// Set the property to the specified value to be used in the buildfile
So presumably, you can do
phing -DMY_VAR=value build.xml
#2 did you consider using a properites file?
See http://www.phing.info/docs/guide/stable/chapters/appendixes/AppendixF-FileFormats.html
and scroll down for info on build.properties
#3 also ...
Phing Built-In Properties
Property Contents
env.* Environment variables, extracted from $_SERVER.
you would access them with something like
${env.MY_VAR}
#4 This looks closer to what you really want
<replacetokens>
<token key="BC_PATH" value="${top.builddir}/"/>
<token key="BC_PATH_USER" value="${top.builddir}/testsite/user/${lang}/"/>
</replacetokens>
I hope this helps.