For a particular project, QtCreator stores information about the build configurations for each kit that project uses in its *.creator.user file. Some kits are automatically detected; kits can also be manually defined by going to Options-->Build & Run-->Kits and selecting Add. However, I can't figure out where QtCreator actually stores information about available kits. Deleting all *.creator.user files that make use of a particular kit does not remove the kit from the list of kits, and I can't find the names of any custom kits I've defined anywhere in the Qt folder on my computer (I'm using Qt5 RC2, so I'm looking in Qt5/QtCommercial5.0.0-rc2/Tools/QtCreator/share and subdirectories thereof). Any suggestions?
The SDK stores a set of files in $CREATOR_INSTALL_DIR/share/QtProject/qtcreator. These are used by everybody using this instance of creator.
The user-specific files are in your home directory in ~/.config/QtProject/qtcreator (or %APPDATA%/QtProject/qtcreator on windows, don't know about Mac).
The kits are in a file called profiles.xml (I first called this whole thing profiles, but since that conflicts with the .pro-files qmake uses it got renamed). Toolchains are in toolchains.xml, Qt versions in qtversions.xml.
The .user-files only contain data for the project it is related to. Basically everything set in "Projects" mode ends up in the .user file.
Related
I have solved the GL and GLUT part by installing NVidia CG toolkit. But, having continuous trouble with GLEW, GLFW, GL WTF W, etc.....
I want to install .h, .lib,and, .dll files related to GLUT, GLUI, GLEW, and, GLFW in such a location so that I don't need to pull my hairs every time I create a new project in Visual Studio 2003/2005/2008/2010/2012/20....... .
I am using 64 bit Windows-7.
But, others are bothering and confusing me every time I create a new project.
Create an empty project in which you will once setup once all necessary properties in:
C/C++ -> General -> Additional Include Directories
Linker -> General -> Additional Library Directories
Linker -> Input -> Additional Dependencies
All additional properties if any are required ...
Then, use File -> Export Template from the VS menu to export project template, so you can use it every time you are creating a new project. More information about project templates can be found here:
https://msdn.microsoft.com/library/xkh1wxd8(v=vs.100).aspx
EDIT:
Create an environment variable that will hold the path to your directory which contains the necessary libraries and headers (for example, GL_LIBS). Then, when setting up properties of the project to be exported, use this variable value instead an absolute path (for example: %GL_LIBS%\xyz_headers_dir). This way, if you want to change the location of the libraries, the only thing necessary is to change the environment variable and it will work. This is also helpful in situations when several team members work on the same project and don't want to keep these files in the same location.
One more thing, since "Export template" does not work on VS2010 or older, you will have to do additional steps. In case you are using VS2010, it is only a small issue since there is a VS extension which you can use to export project templates:
https://visualstudiogallery.msdn.microsoft.com/57320b20-34a2-42e4-b97e-e615c71aca24/
If you are using an even older version, then you will have to create a custom wizard which enables you to export a VC++ project template:
https://msdn.microsoft.com/en-IN/library/96xz4cw2(v=vs.90).aspx
I do not advise this at all, since if you want to build a project without these libraries, you'll still have them cluttering up your include paths. This can cause conflicts with other libraries if they happen to use the same include files as one of these. But if you insist...
Visual studio has default paths that every project gets. You can simply add the include and library paths of your choice to these paths. In older versions of Visual Studio, they live in Tools->Options->Projects and Solutions->VC++ Directories or something like that. In newer Visual Studio versions, they live in the VC++ Directories property page of the project/solutions property sheet.
How do you configure (i.e. set paths/libs/whatever) for libraries you use in your project (big ones, like boost/qt, which you can't just include in the project files) in Visual Studio when you work with other team members through e.g. SVN? I mean, everyone can have their libraries installed in different paths on their computers, so how do you configure all that to work everywhere?
Right now I'm working on a C++ project so I would like to know about C++ but probably the problem is general.
Basically two options:
Put path to them into an environment variable, you can use then it in project properties
Create a VS user macros with predefined name with path to installed libraries, again it can be used in project properties
To me #1 seems to be simpler and more universal, but no clear winner.
You may also want to include library version into name of variable, so that information about required version of third-party components is versioned as well instead of "whatever is installed on computer".
I would like to automatically generate *.creator, *.files, *.includes, and *.config files for each of several hundred projects in a large workspace. I would like each project to build using an external tool via a custom build kit and set of build configurations. From what I've read about QtCreator, it seems to me that the only way to do this would be either to generate the *.creator.user file for each project in advance and include the necessary build configurations, or to open each project, allow QtCreator to generate the *.creator.user file for that project, and then insert the build configuration information into the file. Rather than generating or retroactively editing an entire *.creator.user file, I'd like to generate something like a *.pro.shared file (http://doc.qt.digia.com/qtcreator-2.4/creator-sharing-project-settings.html) that could be identical for every project and wouldn't require messing with all the other user settings. Unfortunately, it doesn't appear that there is any analogous *.creator.shared file that can be used by QtCreator to incorporate shared settings. Is there a better way to approach this problem?
The build settings are basically the reason why you can not share a .user file: They contain references to data that is specific to one Qt Creator instance. These are mostly ids for Qt versions, tool chains and kits.
You can create .user files, there should be no problem with that, provided you insert the ids that are used in your creator instance. If you do it wrong, then creator will just throw away those settings and then regenerate them using default values.
Make sure to include ProjectExplorer.Project.Updater.FileVersion or creator will update your configuration using a series of transformation steps, which will most likely break everything (provided you did not start out with data compatible with Qt Creator version 1.3:-).
There are many open-source libraries that can be compiled with Visual Studio. I'm porting a program from Linux to Windows, but it depends on a number of libraries. I don't know what the best practices regarding libraries are on Windows.
On Linux, these libraries are typically part of the distribution. To use sqlite on Debian, for example, you need only to install libsqlite3-dev and the include files and libraries (both static and dynamic) are automatically installed and available to your program.
If you need a different version than your distribution supplies, you can compile it in your home directory, install it to ~/include and ~/lib, and set the appropriate environment variables so that your compiler includes those directories in its search path.
What is the best way to use libraries that are distributed as source on Windows? If I link dynamically rather than statically, is there an easy way to copy required DLLs into the output directory to ease redistribution (assuming license requirements are met)?
Option 1 - Projects that have binary distributions for windows / do not build in DevStudio.
E.g. OpenSSL.
Projects like OpenSSL are best downloaded to their own folder and built using their own scripts. OpenSSL typically installs itself to C:\OpenSSL on windows builds, so one done, you can add C:\OpenSSL\include and C:\OpenSSL\lib to your project environment to access the OpenSSL headers and Libs. The actual dll files you will need to copy from C:\OpenSSL\bin into your projects staging folder (normally your SolutionDir\Debug or Release).
Once youve gone through the hassle of building OpenSSL once, you don't want to do it again. Or, if you've downloaded the binary distribution, its best left alone. Just document to others which binary distribution you used so they can set up their Visual Studio build environment appropriately.
Option 2 - Small libraries that are easy to create Visual Studio Projects for (or already have). Lua and sqllite fall into this category.
For projects that are small enough, it is not inconvenient to simply add them to your solution in a sub folder. This way you can get their outputs built directly to the solutions output folder, and you do not have to bundle pre-build binary files in your solution making it far easier to share the project with others.
Option 3 - As an alternative you could create your own standardized folder for the products of open source projects. Create C:\oss\include, c:\oss\lib, c:\oss\bin etc, add these paths to DevStudios lib and include paths, add c:\oss\bin to the systems PATH variable, as you build each OSS project, copy the appropriate files to these locations.
Again, while convenient, this setup makes it diffucult to replicate the build environment on a 2nd PC, so you might want to keep the entire C:\oss tree in source control as well.
On windows the easiest way is to build your own DLLs and include them in the program directory.
Yes it uses a bit more space, but HD are large these days and avoids a lot of headaches of incompatible versions (DLL hell). Windows also suffers a few more wrinkles with versions of libs built with different compilers so shipping your own builds is safest
We have a a product developed on Windows for years. The product is composed of one Eclipse workspace and about 20 projects.
On Windows, we ask every developer check out projects into d:\dev\product folder, and copy a unified Workspace to d:\dev\prod_workspace. This way, whenever a new machine is set, we simply copy files to the same folder, and we can start working immediately.
Now we need to move our development environment to Linux and Mac. But there's no D:\ on Unix. And home folder for Linux is mostly like /home/username and /Users/username for Mac. We found Eclipse keeps absolute path in workspace when referring to projects, so simply copy workspace over does not work anymore. Even when we manually create/configure workspace on a Linux machine, it still cannot be copied over to another user, because the absolute path is changed.
I guess our goal is to allow easy setup of development environment. Do you have any suggestion to move eclipse workspace around?
I develop an Eclipse based product for Mac and WIndows (haven't tried Linux).
The solution I found to work best is to actually go and manually check out the projects in the workspace on each machine directly from source control. While the project structure does convert between platforms, any attaches, such as version-control stuff does not. I am not sure why, but I guess each thing has its kinks.
You may be able to able to hasten things a little by creating a project working set (or whatever it's called, I think it's a PSF file) for a platform, and then reuse it on all platforms.
Another problem is that Eclipse versions are not 100% compatible. One of the problems I have is with manifest files for plugins, which have different semantics (e.g., what to do with exported packages that don't actually exist) in each platform, causing a headache.
Finally, be away that Java on Mac and PC are not identical. In fact, Eclipse has two versions for the Mac. I usually end up running and compiling on Java 5 on the mac, which does have some incompatibilities with Java 6.
I have ported my eclipse project from windows xp to RHEL(never tried Mac)
Your task can be accomplished in the following steps :-
Use workspace variables in your project code rather than absolute path.
Shift your workspace to some location in linux as /Workspace or if you want to keep it user specific make the workspace folder as /home/user_name/Workspace.
There is an option to change all the \ of windows to / in linux. The option can be found under the file menu in eclipse.
Change the settings of where to find classpath directories, the options can be found by just right clicking on the project menu in the project viewer panel.
There is an option to build the project clean from scratch. You just have to click on the option and eclipse would re-compile the project.
Once all this is done, and all your database connections have been successfully ported to linux, you would have a working project running in linux as well.
I can think of two ways to do this:
Use workspace variables in Eclipse to point to the exact location where the workspace sits, if you need that. Then the developer can put everything in the workspace on Windows, Unix, whatever, then define the variable and you're done, or
If compilation is always done from within Eclipse, meaning you don't truly need any absolute paths anywhere, then change the projects to all use relative paths and check the Eclipse classpaths, etc, into source control. Thus, when a developer checks out everything in Eclipse, the classpath and .project file will be at the root level in the project and all paths will be pre-defined.
For option #2, you may need to have multiple .project or .classpath files, and have the developer copy the appropriate one into location. That is, copy .classpath.win into .classpath for Eclipse's use.
If you check out the projects from a source repository, then consider using Team -> ProjectSets to handle these.
Preferences can be saved in a file and loaded.
We tried classpath variables and loathed them. Now we just have everything in single projects in the source repository.
Use the Workspace Preference Transferrer plugin
This allows you to transfer the workspace settings from a given workspace to another via new options in the 'switch workspaces' dialog.
I'll share my own solution:
Zip the workspace. Just zip the entire file and then transfer it over. Then, all you need to do is delete the default drive reference:D:\ ...or whatever ends up appearing in the beginning of your file name. Then all you need to do is drag it over to the new empty workspace on your newly downloaded Eclipse.