I'm trying to run a Makefile for building a kernel module in QtCreator. I can successfully invoke the make file from the command line.
My assumption was that this shouldn't be a problem to set also in QtCreator by defining the build step as a custom command make.
It seems however that QtCreator is introducing some other working paths instead.
As the showcase above points, both the working directory and the script absolute path are set to /home/user/module which is the path in which the correct Makefile resides.
However, QtCreator seems to be searching for the Makefile at /home/user/Qt/Tools/QtCreator/bin/Makefile: No such file or directory.
Am I missing a setting somewhere or is this a bug?
You are using the PWD environment variable in your makefiles. This environment variable is updated only by a shell though, and custom process steps are not executed in a shell by default, but started directly as a child process. This means that PWD will stay as it is shown in the "Run Environment" section of the run configuration instead of being changed to the working directory of the step.
If your custom step depends on features of the shell, you should run it in a shell, i.e. set the "Command" to /bin/sh (or /bin/bash or whatever you prefer), and the "Arguments" to -c make (or whatever you need to pass to your preferred shell to execute a command).
Related
I installed Haskell on my MacOS system using ghcup installer. It worked because if I type ghci I am dropped into this interactive shell. However I got this message in the terminal after doing the install:
In order to run ghc and cabal, you need to adjust your PATH variable.
You may want to source '/Users/user1/.ghcup/env' in your shell
configuration to do so (e.g. ~/.bashrc).
Detected bash shell on your system...
If you want ghcup to automatically add the required PATH variable to "/Users/user1/.bashrc"
answer with YES, otherwise with NO and press ENTER.
YES
grep: /Users/user1/.bashrc: No such file or directory
My shell is bash 3.2 But as you can see, when I typed YES it says there is no such file. How do I find my shell configuration file, or resolve this? I'd like to complete the setup correctly here.
And I have to be honest about my level of knowledge here, I don't truly understand what this is asking exactly. Is the PATH variable 'env'?
On macOS, .bashrc does not exist by default. ghcup will create this file, so the command you ran will have worked correctly. However, one of ghcup's subcommands expected to find the file before it was created, and therefore reported that error message. You can safely ignore this.
At the top of my makefile I have this line:
SHELL := /bin/sh
which is needed for most of the commands. However, I would like to also have a make command to activate my virtual env, which is on a different path.
Here is the code that I wrote for it:
activate:
source ~/.envs/$(APP)/bin/activate; \
The problem with this is, that this just prints out what is written here, and it doesn't get executed. I read that it might have something todo with only bash knowing about source, but I can't figure out how to temporarily switch modes within the activate command.
How would I have to write this method, so that it activates my virtualenv?
It does get executed.
Virtualenv works by modifying your current process's environment (that's why you have to "source" it). However, one process cannot modify the environment of the other process. So, to run your recipe make invokes a shell and passes it your virtualenv command, it works, then the shell exits, and your virtualenv is gone.
In short, there's no easy way to do this in a makefile. The simplest thing to do is create a script that first sources the virtualenv then runs make, and run that instead of running make.
Create a file called "make-venv" like this:
#!/bin/bash
source ./.venv/bin/activate
$2
Then add this to the first line of your Makefile
SHELL=./make-venv
Now, make-venv activates virtualenv before every command runs. Probably inefficient, but functional.
You can do it by using set, which allows you to set or unset values of shell options and positional parameters:
set -a && . venv/bin/activate && set +a
What does 'export' do when used in a command line.
For example, and this is only one example, I build a number of C++ libraries and for a library such as zlib-1.2.8 I need to specify the install directories.
To do this I need to do the following in MSYS command line interface. This is just one example
export LIBRARY_PATH="c/libraries/libs;$LIBRARY_PATH"
Would anyone know what the command 'export' actually does in this instance?
Does it permanently install a record for MSYS to user later on when looking for dependencies such as ZLIB . My using make install the zlib library file is placed in this directory.
OR, when I close MSYS is this LIBRARY_PATH lost from MSYS memory?
Thanks
This is the bash syntax to set an environment variable. Using export allows the variable to be seen outside the script in which it's defined.
Environment variables only affect the msys process and any child processes started from that shell. If you want it to persist after you close the command line and start a new one, you will need to put it into a script such as .bashrc
Following is the issue, I am encountering
I have a shell script named my_script.sh.IN. I use configure_file for expanding script and thus creating my_script.sh.
I then need to run my_script.sh. For this purpose, I am using execute_process().
I need all of this at CMake time.
Issue: Problem is that when I run "cmake", system complains that he could not find "my_script.sh". I think that execute_process dependencies seem to be calculated before configure_file() function runs.
When I run "cmake" command second time, everything goes fine. Does anybody knows that how can I able to execute configure_file before execute_process?
You should try something like that:
set_source_files_properties("pat/to/my_script.sh" PROPERTIES GENERATED true)
It tells cmake to not check the existency of the file too early. You will probably have to use the variable containing the path of your generated shell script instead of typing directly its path.
But your issue is more probably related to order of the executed cmake commands. You should ensure configure_file() is run BEFORE execute_process() by CMake parser.
I am writing installation in a Makefile in which I need to set the PATH env. variable.
In the windows part of it, I found the following:
set: With set PATH="%PATH%;%CD%" I can change the PATH inside the running environment. There are two problems with this:
The environment is a spawned cmd.exe by make which gets its variable affected and the effect removed as soon as it closes
Even if the previous problem could be solved, still the cmd.exe that calls make would close one day and the modified PATH lost.
setx: A microsoft tool that can permanently change env. variables. According to microsoft itself, this is the only command-line option to do this. Using setx PATH "%PATH%;%CD%" -m however, turns path into the literal %PATH%;%CD% and doesn't replace the variables by their contents!
Note that I am calling make from cmd.exe not cygwin or other modified windows shells that act more like linux. What I'm saying is that, although I can use $(PATH) in my makefile (instead of %PATH%), I can't use pwd (instead of %CD%)
Also note that if in cmd itself I run:
setx PATH "%PATH%;%CD%" -m
it works perfectly. Somehow I need to make make execute this command.
Do you have any idea how to fix this, or what workaround do I have?
P.S. Just for the record, echo "%PATH%;%CD%" in the Makefile also echoes the literal "%PATH%;%CD%" rather than let cmd.exe handle it
Back in the day i Borland C++ Free Command Line tools included a version of make which played well with the dos/windows command line. Probably still floating around somewhere.
Workaround:
Create a .bat file, put the command there, and invoke it from the Makefile.
I still am interested in a direct fix in the Makefile though.