With the following dummy qmake syntax I am trying to set an environment variable and then check it later:
MY_VAR = true
message("A")
defined(MY_VAR){
message("B")
}
The unintuitive part for me is that upon running this qmake script, only "A" is outputted to the console and not "B";
So what is the correct way of setting an environment variable in qmake?
To check for variable existence you must invoke
defined(MY_VAR, var): message(...)
BTW. this is a regular qmake variable, not environment variable.
Related
I have the following test:
*** Test Cases ***
My Test
${MY_VAR} Set Variable %{MY_VAR=mydefault}
If I export MY_VAR before running the test it picks that up.
If I don't have the env var set it uses the value mydefault.
So far so good, but I was expected to also explicitly override via the command line.
When I pass --variable MY_VAR=fromcmd it does not use that value.
Does %{} not support overriding with --variable?
It's true the variable setting in the command line has the highest priority, but this is not what happens here - in this line you are effectively re-setting the value.
You passed some value from the CLI, but when the execution got to that line, it actually did "the variable MY_VAR will now be set to the value of the env variable MY_VAR, or if there isn't such - to mydefault".
E.g. you're effectively overriding the value from the CLI args, present or not.
You can solve for this by first checking is the var already defined (from CLI, or some place else), and fall back to env and default only if not. The Get Variable Value returns by default None (the py type) if a variable is not defined, so using that:
${MY_VAR}= Get Variable Value ${MY_VAR}
IF $MY_VAR is None # not set yet?
${MY_VAR}= Set Variable %{MY_VAR=mydefault}
END
I have a user case where I need to execute a magic command and pass an argument to it, for example:
%my_magic_command hello
What I wish is for hello to be a value from an environment variable, e.g. assume I have an environment variable MY_VAR=hello, I want to be able to call something like
%my_magic_command $MY_VAR
Is there a way to achieve this in Jupyter?
I'd like to set the default target(s) of a Makefile to the space-deliminted value of an Environment Variable.
For this solution to work correctly, it must be possible for me to set an environment variable, then run make and have the target, (or optionally space-delimited targets), contained in the environment variable be used as though they were passed as targets.
DEFAULT_TARGETS="target target2" make
# ... should produce the same result as ...
make target1 target2
Thanks for the help!
You can do it by adding something like this to your makefile:
ifneq ($(DEFAULT_TARGETS),)
__default_targets: $(DEFAULT_TARGETS)
.DEFAULT_GOAL = __default_targets
endif
Following #Andreas lead I've landed on this ...
.PHONY: DEFAULT_TARGET
DEFAULT_TARGETS ?= intro
DEFAULT_TARGET: $(DEFAULT_TARGETS)
This use the "First Target as Default" paradigm, then expands the contents of the DEFAULT_TARGETS env-var to add requisites. It also has the advantage that if the DEFAULT_TARGETS environment variable is not set, the makefile will use the fall-back value, in this case that's intro.
In the shell this would look like, DEFAULT_TARGETS="target target2" make
I'm trying to print a message with QMake but I have problems with extensions:
lib_name = $$1
message("test1: $$MYPATH/$$lib_name/src/$$lib_name.pri");
message("test2: $$MYPATH/$$lib_name/src/$$lib_name");
For some reason, test1 doesn't print the correct path. It just prints the path until src/. But, test2 is ok. It prints everything until the value in $$1.
Any workaround?
QMake supports variables (objects) with members that can be used using the dot . operator e.g. target.path for INSTALLS. So, in your case, $$lib_name.pri means that you're accessing the member pri of lib_name which doesn't exist so there's no output.
You need to enclose variables in curly braces for QMake to distinguish them from the surrounding text i.e. $${lib_name}.pri.
Example:
message("test1: $$MYPATH/$$lib_name/src/$${lib_name}.pri");
# ~~~~~~~~~~~~
For more examples of objects, see Adding Custom Target and Adding Compilers sections of QMake's Advanced Usage page.
Here's another relevant SO thread: QMake - How to add and use a variable into the .pro file
I am trying to run the following command from Julia:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/.julia/v0.3/Smile/deps/downloads
When I run it as-is it tries to replace $LD_LIBRARY_PATH with a local variable.
When I escape the $, it puts quotes around the command, which invalidates it.
julia> cmd = `export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/tim/.julia/v0.3/Smile/deps/downloads`
ERROR: LD_LIBRARY_PATH not defined
julia> cmd = `export LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:/home/tim/.julia/v0.3/Smile/deps/downloads`
`export 'LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/tim/.julia/v0.3/Smile/deps/downloads'`
I would like to run the command in a form similar to:
run(`export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$newpath`)
How do I properly handle the dollar sign?
Thank you
*note: pasting the command directly into terminal and running it does work
In Julia, backticks are not completely equivalent to running the corresponding command at the shell. You can't interpolate environmental variables with $ (although $(get(ENV, "varname", "") should match the shell's behavior), and export is a shell built-in, not a command, so I don't think you can run it. Also, even if backticks shelled out, export would only change the environment of the subshell, not the calling process.
You should be able to set LD_LIBRARY_PATH from Julia as:
ENV["LD_LIBRARY_PATH"] = "$(get(ENV, "LD_LIBRARY_PATH", "")):$newpath"
but you should avoid this if possible. If your intent is to ccall a specific library, you can pass the library path directly to ccall, perhaps using find_library as you indicated in a comment if you don't know the full path advance. If you need to set LD_LIBRARY_PATH because the library needs to load other libraries, I'm not sure if there's a better way, but note that LD_LIBRARY_PATH is platform-specific. You might be able to dlopen the dependent libraries first, but I haven't tested that.