via: https://github.com/raysan5/raylib/wiki/Working-on-Windows
I installed mingw to build raylib. The instructions as noted above said to use the 1st command. I used the second one by accident. So I deleted the entire raylib folder and extracted out a second one and then used the proper command to compile. My question is: was that the proper way to uninstall my mistake? Or did it create something somewhere else I needed to delete? Comparing the /src of the unbuilt and built versions the difference was a few .o files....does the mingw command just compile code 'for the folder in question'? so everything i did with that mistaken command woulda been held in the /src folder? And if everyone is contained to the raylib folder...then I can freely change the directory that raylib folder inhabits? i.e. I can move it from downloads to c
Related
I've just installed Golang on my machine, and I set up GOPATH.
But when I navigate to my go/src I see that src folder contains ./sourcegraph.com, ./golang.org and ./github.com. Also GOPATH/bin and GOPATH/pkg also no empty.
So I have several questions:
1) I know how to use ./github.com folder for pushing my code to github, but why it contains , from box, some other not mine projects inside such as acroca, cweil ... and other ? Can I clear this folder?
2) What I should do with golang.org folder, can I remove it ?
3) What I should do with sourcegraph.com folder, can I remove it ?
4) Can I clear bin and pkg from preinstalled binaries and packages?
I think you not only installed the Golang but also install/configure Visual Studio Code IDE with Go Extension. Those alien repositories were created when the extension installs needed tools. The full list of tools can be found here. Or probably other similar IDE/extension which depends on those tools.
Yes you can clear the sources, since the IDE depends only on the compiled binary, and the sources are only needed during compilation.
Same as (1). Refers to Golang SubRepositories
Same as (1)
For now, you can clear the content of pkg directory but don't remove the directory. In the future, when you install some packages/libraries, the compiled version may be created under the directories, so don't remove it. For bin directory, don't remove the files inside it, because the IDE (Go Extension) depends on them.
But, since I don't know exactly what else you've done, I think before you completely remove them, try just to move them outside your GOPATH or take a backup and see whether your dev environment works as expected.
After installing cmake-3.8.1-win64-x64 I got thisenter image description here
So what can I do with this? Thanks.
cmake-gui does not help you create cmake configuration files, it parses these files to generate and configure projects.
In your source code directory, you should have a CMakeLists.txt file which defines the rules for CMAKE to configure your problem. That directory should be entered into the first box.
Next, you get to decide where to build the binaries. We could do it in the source directory, but the generated artifacts could pollute what is already there. "Cleaning" the build by deleting all of those artifacts while keeping the original sources is tedious at best, so it's a good idea to make an empty directory and use that as your binaries path.
Once you have those fields entered, you should be able to "Generate" or "Configure" your project. If you need help creating a CMakeLists.txt file (that's really the complicated part), then check out their tutorial.
I'm using Bison and Flex in an Xcode project. I didn't want to put the generated files under source control, so I was happy to find that Xcode natively supports Bison/Flex files, generating the parsers on-the-fly in its derived data folder. So far so good.
However, Xcode uses an embedded old Bison version (2.3):
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/yacc
which doesn't yet support the %define api.pure full directive. Since this bison executable is under the Xcode.app bundle I can't replace it, so I installed the latest version via Brew and added it to my $PATH through ~/.bash_profile (~/.bashrc also sources my bash profile). So in bash I can say:
$ which bison
/usr/local/Cellar/bison/3.0.4/bin//bison
However, Xcode still uses it's own version... I suppose the path to the internal bison is hardcoded.
My second approach was to create a custom build rule for Yacc files, and run the correct version of bison from there. This time the problem was that as Xcode ran my custom build rule, it immediately tried to build the resulting C files. The generated C files would however depend on the header file yet to be generated by Flex, because that's where e.g. yyscan_t is declared (used by Bison in the generated C file). But on the other hand, Flex-generated C files also include the Bison-generated header, so compiling with Flex first doesn't help...
What I need is to first only generate the Flex and Bison headers/sources and then build them along with the rest of the project.
How can I achieve this?
I've managed to solve the issue by putting the *.l and *.y files under a *.parser folder and adding that folder to the project. Then I removed the *.l and *.y files added the folder to the compiled sources:
And then made a Build Rule for *.parser like this:
This enables me to first run yacc and lex and only then will the resulting *.cpp files be passed to the compilation step.
If you go to your build target, Build Phases, and click the + on the bar with the search box on it, you can add a New Run Script Phase. You can then drag that above your current Compile Sources phase. You can do whatever you want in that script phase, and it will run before compilation starts.
This is a bit of a Zombie, but if I ever come back here again, I will want to see the answer.
Certainly from XCode 12 (probably before) the answer is trivially easy.
(1) Go to build settings
(2a) Press the + for a brand new setting variable.
(2b) Change the NAME to YACC, and it's VALUE to /usr/local/bin/bison (or whatever path you need for brew).
(3a) Press the + for a brand new setting variable.
(3b) Change the NAME to LEX, and it's VALUE to /usr/local/bin/flex (or whatever path you need for brew).
(4+) use the YACC/LEX settings for flags that you want to use.
I've managed to do it with custom build rules, using bison installed from brew and flex that comes with macOS, not the one bundled with Xcode. I'm not sure if my problem was the same as yours, but if you want to take a look my project is on GitHub.
I'm working on my first project using cmake, and for the most part it's been going well but I've run into one problem I can't figure out.
Let's say I have my CMakeLists.txt file located at ~/project/build. I would like for the output from cmake (not the binaries, but the makefile/configuration files) to be independent of where I run cmake from.
As an example, if my terminal is sitting in the ~/project/build directory, calling cmake ~/project/build creates the makefile and everything else within the ~/project/build directory. This is the behaviour that I'd like. If I call cmake ~/project/build from anywhere else, it creates the makefile and everything else in whatever directory the terminal called the program from.
Is it possible to force cmake to generate its makefile and associated files in the same folder as the CMakeLists.txt file? I've taken a look through the documentation and I've had no problems figuring out how to change binary output directories, but I can't really find any mention of what I'm trying to do.
I realize this is a pretty minor annoyance (it's not that hard to move into my build folder before building the project) but I'm just wondering if it's possible and if there's some reason it wouldn't be advised.
You have to use 2 commands for this
1) cmake -B "Dest path(Any path in which u want to generate the output files)" -H"Source path(root CMakeLists.txt path)"
2) cmake --build "Dest path"
I can't find any information on how to install Qt built on Windows.
In wiki article How to set up shadow builds on Mac and Linux there's description of -prefix option in configure script but this option is not available on Windows.
I know I can use Qt right from the build folder but it does not seem the right thing not to perform an install step. One problem with this approach is size; Qt's build folder takes about 4GB space whereas after installing using binary installer Qt takes about 1GB space. I guess the difference is due to temporary files created during building. I hope some install procedure would install (copy) only needed files leaving temporary files in the build folder.
As İsmail said there's no install step for Qt on Windows.
However one can try to approximate it by performing the following operations.
Cleaning
Run make clean in the build folder to remove all temporary files.
Moving
Copy build folder to the place where you want Qt "installed". Let's call it INSTALL_DIR.
Fixing paths hardcoded in the qmake.exe executable
Run qmake -query to see what paths are compiled (hardcoded) into qmake and
a. Fix paths containing the build folder by replacing it with the INSTALL_DIR using qmake -set (1).
or
b. Create a qt.conf file in the bin subfolder of the INSTALL_DIR specifing new Qt paths inside it.
Adding current directory to include path
In Qt's provided binary distributions, the pwd is included in the QMAKE_INCDIR and thus ends up in your projects include path as ".". This does not happen by default in a custom built Qt, so you have to add the following line to mkspecs/YOUR-PLATFORM-HERE/qmake.conf file:
QMAKE_INCDIR += "."
Fixing prl files
When you add a Qt component to a project file (such as CONFIG += uitools), Qt looks in %QTDIR%/lib/QtUiTools.prl to find the library dependencies of that component. These files will have the hard coded path of the directory in which Qt was configured and built. You have to replace that build directory with the one to which you moved Qt for all lib/*.prl files.
Making source available
If you made a shadow build (build made inside folder other than the one containg sources), headers in the include subfolder only forward to the original headers. For example; BUILD_DIR\include\QtCore\qabstractanimation.h looks like this
#include "SRC_DIR/src/corelib/animation/qabstractanimation.h"
If you don't want to depend on the existence of the folder containg sources you have to copy SRC_DIR/src subfolder to your destination folder and fix all headers in the include folder so that they forward to the new location of src subfolder.
The bottom line:
The build process of Qt under Windows makes it really akward to move (install) Qt after building. You should do this only if ... well I can't find any good reason to go through all this trouble.
Remember
The easy way is to place Qt's sources in the folder where you want Qt to stay after building and make a build in this folder. This makes all steps but 1 and 4 above unnecessary.
1)
The variables you set with qmake -set are saved in the registry key
HKEY_CURRENT_USER\Software\Trolltech\QMake\<QMAKE_VERSION>.
Because of this you might have a problem when you would like to have different projects using different versions of Qt which happen to have the same version of qmake. In this case the better solution is to use qt.conf file (actually files as you need one file for each Qt installation) (option 3b).
Many of the information above come from the RelocationTricks wiki page authored by Gabe Rudy. Check out his Qt (Qt4) Opensource Windows Installers of Pre-built Binaries with MSVC 2008 project which gives you easy solution of above problems.
This answer is a replacement for steps 3 and 5 of Piotr's (currently top rated) answer above, but you may still need the other steps in his answer, depending what you're trying to achieve.
This is the operation which the official installer uses to fix the hardcoded paths during the installation: qt.520.win32_msvc2012.addons/meta/installscript.qs
This is how the operation is implemented: qtpatchoperation.cpp
This is the list of files that it fixes: files-to-patch-windows-qt5
And this shows how to invoke an installer operation as a standalone command from the commandline: Operations (Qt Installer Framework Manual)
To summarize: after moving your Qt directory to where you want it, download any one of the official Qt installers and run it with the following commandline arguments:
cd <path>
installer.exe --runoperation QtPatch windows <path> qt5
Replace <path> with the full path of your Qt directory after you moved it (the qtbase directory if you are using Qt 5). Omit the final qt5 argument if you are using Qt 4.
This will fix the hardcoded paths in qmake.exe, .prl files, and others. It gives you the exact same behaviour that the official installers have in that respect.
For the initial move, nmake "INSTALL_ROOT=\somewhere" install works for me. So that's steps 1 and 2 of Piotr's answer covered. And I haven't needed steps 4 or 6, FWIW.
I can configure QT 5 on WINDOWS (Visual Studio build) with the prefix option like:
configure -prefix C:\the\path\I\want ...
then call:
nmake
nmake install
and the latter will install Qt in C:\the\path\I\want.
I did it without problems with Qt 5.2.1 and 5.3.x, so far. So, any earlier problems seem to be fixed by now.
It's very odd people claim that there is no "make install" on Windows.
I have used it many times, and I agree that it's not what it is on other platforms, but it serves its purpose.
How I use Qt's make install on Windows (from cmd):
configure
(n/mingw32-)make
(n/mingw32-)make docs
(n/mingw32-)make install
The make install bit copies all necessary headers to be able to delete your source directory. Delete all objects and unecessary stuff:
del /S /Q *.obj lib\*.dll
rmdir /S /Q docs-build qmake tools src
This allows you to remove the source directory. I don't know what impact this has on debugging Qt source code, but it sure reduces the size of a shadow build. I use it to maintain 32 and 64 bit builds with minimal size.
Qt on Windows is not installable with make install, you will notice that Qt installer for Windows just patches dlls & pdbs for the new install location.
What I would suggest is to do a shadow build in the place you would like to install it. You can manually remove *.obj files to save up space.
Qt's own build instructions show how this is done, by search/replace within each Makefile. Assuming the source was extracted to C:\qt-4.8.3 and build was performed within that directory, then do this:
fart -c -i -r Makefile* $(INSTALL_ROOT)\qt-4.8.3 $(INSTALL_ROOT)\my-install-dir
set INSTALL_ROOT=
mingw32-make install
Then create a config file that tells qmake about its new installation path. Create a textfile C:\my-install-dir\bin\qt.conf:
[Paths]
Prefix=C:/my-install-dir
Translations = translations
Then as a final step (as Randy kindly pointed out) you need to patch qmake.exe, which can be done using a simple utility called QtMove. This same tool also automatically updates all the prl files.
Step 1: Move Qt
Cut and Paste
Current directory - C:\tools\Qt
Destination directory -C:\sim\dep\Qt
Step 2: Get Old Qt Directory
Go to C:\sim\dep\Qt\2010.02.1\Qt
Open .qmake.cache
Find variable QT_SOURCE_TREE
Note the value of QT_SOURCE_TREE
Mine was C:\tools\Qt\2010.02.1\Qt
Step 3: Patch Qt
Go to C:\sim\dep\Qt\2010.02.1\bin
The syntax is qpatch.exe list oldDir newDir
qpatch.exe files-to-patch-windows C:\tools\Qt\2010.02.1\Qt C:\sim\dep\Qt\2010.02.1\Qt
Step 4: Set Environment Variables
set QTDIR=C:\sim\dep\Qt\2010.02.1\Qt
set QMAKESPEC=C:\sim\dep\Qt\2010.02.1\Qt\mkspecs\win32-g++
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\Qt\bin
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\bin
You can do all of this with a batch file. This took me a fair while to work out and it has saved me a lot of time since. It's a script to automatically update a Qt installation to new locations. The batch file is available here.
There is a simple utility QtMove (http://www.runfastsoft.com) can do this easily.
Runs the relocated qmake.exe build your .pro file and everything should be linked with new Qt libs.