Does it make a difference (and if so, what difference) where I add the make install step?
In some posts they say to add it under Build like in the first screenshot. Others say it needs to go under Run/Deployment like in the 2nd.
Are both ways equivalent?
If it is part of Build Settings, it will be done every time you do a build under Qt Creator (assuming previous steps succeeded).
If it is part of Run Settings, it will only be run when you actually run the app under Qt Creator.
It depends on the case, which on you want. If it is part of Run Settings, then logically it should be configured to run the installed/deployed binary. If it is just for checking that make install succeeds, as part of the build, even though it will run the application from build directory when you run it under Qt Creator, then it should be part of build.
In your case, it sounds like make install is needed for running the app, so maybe it could be part of Run settings, to make normal builds just a bit faster.
Related
In gRPC, when building for arm, I need to disable those three variables:
-DRUN_HAVE_STD_REGEX=OFF
-DRUN_HAVE_POSIX_REGEX=OFF
-DRUN_HAVE_STEADY_CLOCK=OFF
It is not super clear to me what they do, so I wonder:
Why is it that CMake cannot detect them automatically when cross-compiling?
What is the impact of disabling them, say on a system that does support them? Will it sometimes crash? Reduce performances in some situations?
Because they are not auto-detected by CMake, it would be easier for me to always disable them if that works everywhere without major issues for my use-case.
gRPC uses CMake's try_run to automatically detect if the platform supports a feature when cross-compiling. However, some variables need to be supplied manually. From the documentation (emphasis added):
When cross compiling, the executable compiled in the first step usually cannot be run on the build host. The try_run command checks the CMAKE_CROSSCOMPILING variable to detect whether CMake is in cross-compiling mode. If that is the case, it will still try to compile the executable, but it will not try to run the executable unless the CMAKE_CROSSCOMPILING_EMULATOR variable is set. Instead it will create cache variables which must be filled by the user or by presetting them in some CMake script file to the values the executable would have produced if it had been run on its actual target platform.
Basically, it's saying that CMake won't try to run the compiled executable on the build machine unless some test results are specified manually (test which would have been run on the target machine). The below tests will usually cause problems:
-DRUN_HAVE_STD_REGEX
-DRUN_HAVE_GNU_POSIX_REGEX
-DRUN_HAVE_POSIX_REGEX
-DRUN_HAVE_STEADY_CLOCK
Hopefully that answers your first question. I do not know how to answer your second question, as I have always just set those variables manually to match the features of whatever system I've compiled for.
I have downloaded angular 2 application from this link:
https://github.com/aravindfz/firstAngular2App
How to run this application?
Which angular cli version install to run angular 2 application?
I tried from some questions stackoverflow but not working properly.guys this question is not duplicate..Please understand.
Anyone can give clear details?
I need step by step procedure.
If you cloned the repo and did nothing else, there are a few things you need to do before you can run the app. Since I don't know how much web development you have done, I'm going to include things some people will think unnecessary.
Install node.js, if you haven't yet. Grab the LTS release from https://nodejs.org/en/. Do not use the "Current" version, because that may not be compatible with Angular just yet. If you have and older version of Node, upgrade. If you already have the LTS version, skip this step.
Now open a new command prompt or terminal and change to the directory where you cloned the repo. To be sure you're in the right place, make sure you can see a file named package.json.
In this command prompt/terminal window, execute this command: npm install. This will download and install all the dependencies (which could rather disturbingly add up to a few hundred Megabytes). You may experience timeout errors if you're behind a corporate proxy server. That's not something you can fix as of 2018. Just connect using something else and try again.
Once everything is installed, you should be able to run the Angular app. Everything I mentioned already only need to be done before you run it the first time. To ensure you are in the right folder, navigate to where your index.html is located and run this command: ng serve. If ng cannot be found, you may need to install it. To do so, execute npm install --save-dev #angular/cli. Now it should work. If not, close your command prompt/terminal window, open a new one and try ng serve again.
Once ng serve is finished compiling, you should be able to view your app by opening http://localhost:4200 in your favourite browser.
And that's it!
Here's a bonus tip: Take the time to work through the official Angular Quick Start. It really is a fantastic guide and will get you skilled up much quicker than just hacking it ever will.
Good luck.
Up until a couple hours ago pressing CTRL+R while in Qt would build and run my code. However something changed that I am unaware of that doesn't commit the changes that I make to the GUI. If I move a button for example then rebuild and run, the application will display its previous location. Something to note however, if I run "qmake && make" in a terminal, then rebuild from the GUI it will work. It's a bit of a hassle to keep doing that and thus a solution would be appreciated.
I'm using Qt5 in a Debian 7.0 based environment
Update: I had to disable shadow build to get it to build properly, but I cannot build in another directory
I'm getting crazy with a bad memory access in a qt program when i'm using qglwidget::rendertext function. My program is super simple, I'm only one pointer, but the crash doesn't seem relate to that because the debugger stops sometimes when i call rendertext, sometimes when i close the programs. i'm not experienced c++ programmer and this is getting me crazy.
but i've found this BUG REPORT. It seems recent (Updated: 25/Apr/13 8:47 AM) and due to the fact I don't know what to do with this bad memory access i think it worths to give it a try.
the solution patch is posted here but i don't know what to do.. do i have to recompile all qt 4.8? only the opengl part? can i avoid to recompile everything?
Go to the directory where you compiled Qt and change the file qt/src/opengl/qpaintengine_opengl.cpp. Make the changes that the author made, or download the author's file and replace it in your source directory. Change directory to the main qt directory and run make. Be sure not to re-run ./configure before you do the make or it will rebuild the whole thing.
After make has finished, run sudo make install and it will put the newly compiled QPaintEngine module into your install directory. Unfortunately, I don't know if this will work if you have a number of configurations (like static libraries), but it's worth a try.
I have done this with modules in QtMobility hundreds of times. You also have to remember that you have a Frankenstein's Monster version of Qt now, and when you upgrade remember to re-patch if the change was not committed to the newest build.
Hope this helps.
I've been working on a program called RoboJournal for a long time. The next release has full documentation included; Whenever the user presses F1 or clicks the Help item in the RoboJournal program, the help file is displayed in Qt Assistant (way classier than simply opening a browser window to some online documentation).
In its base form, the documentation consists of lots of loose HTML and image files included in the source package. These loose files are supposed to be compiled into a QCH compiled help file and QHC collection file during build time so Qt Assistant can display the documentation properly. On Windows, this was fairly easy because I was able to write a batch script to automate the entire build process (including compiling the documentation and moving the output files to the right place).
On Linux, it's a bit more complicated. True, I could write a Bash or Perl script that compiles the documentation along with the rest of the program but I have no guarantee that the people who will eventually create my app's Debian packages from the source package I give them will use the script. The source package is used to create all the Debian packages so everything has to work flawlessly with the standard build procedure (or the source package is worthless). Therefore, I need the compile process to produce the same results whether the user runs the script or not. As it is now, the user has to build and install the documentation manually. Surely there's some way to automate this.
Is it possible to have Qmake add instructions to run qcollectiongenerator to the makefile (in order to build my application's help files) so it gets handled properly during the "make" step? That way, the QHC and QCH files will be ready to install to their proper locations (in my case, /usr/share/doc/robojournal-0.4.1) along with everything else when the user runs "make install". I've considered compiling the QCH and QHC files in advance and providing them in the source package but the whole point of building from source is to be able to re-create the entire app from its base components.
I know I probably have to add additional instructions to my .PRO file but I’m not sure what or how. I've found something that looks promising (http://www.qtcentre.org/archive/index.php/t-49484.html) and gives me hope that it's possible for Qmake to do what I need but I’m not sure how applicable those instructions are to my situation. Do I have to create a PRI file just for this or can I add the instructions directly to the main project file?
You can try to use the QMAKE_POST_LINK variable:
QMAKE_POST_LINK += build_help.sh
P.S.
I have no guarantee that the people who will eventually create my
app's Debian packages from the source package I give them will use the
script.
I think this is really not your problem :) It's up to them to properly build the package.