What is done when we import an existing project(maybe a visual studio project)?
Which files are used for configuration?
Try this one, you may get some information.
Migrate Visual Studio C and C++ projects to Eclipse CDT
Eclipse manages files completely differently than Visual Studio, files are managed by Eclipse and placed into the project workspace. Adding existing files has the aggravating effect of copying the files from their location into the workspace. There are workarounds for this (adding a link to existing file, makefile-only projects) but the default is to copy files around.
This is great if your project is managed by Eclipse alone, not great if you want a VS project AND an Eclipse project for the same codebase.
I'm don't think you can import a VS project into Eclipse CDT, at least not the way you're thinking.
The files used for configuration are stored in (path to workspace)/.metadata, there are a LOT of files that change constantly and can contain absolute paths. Caveat emptor.
There is no explicit wizard for importing visual studio project files. What you import is a directory tree full of source code files. Basic information about this is worked out and stored in a file called .project, which contains the settings from Project/properties.
If, when you create or import the project, 'use default location' is specified, the tree is copied into a workspace directory. If not, it is left where it is.
If the project type is 'makefile project', the only real assumption is that there is some external command to be run to build the software. Project properties/C++ build can be used to specify this command - by default, it is 'make'.
DevStudio can export a makefile for one of it's projects - from the Project menu, select 'Export Makefile'. Or you can just write one by hand, or use some other build tool such as ant.
If all else fails, set the build command to 'cat' (e.g. from cygwin) and the build argument to the name of a file that contains the output log from however the software was built.
Eclipse itself has two kinds of projects - those with makefiles, and those that it manages itself.
Makefile projects have a separate make file that you generally write on your own.
Eclipse managed projects have a .project file that is used by the IDE to create make files on the fly, when you build your project.
Are you asking specifically for visual studio projects, or is that just an example?
Related
I have two projects in C++ that I need to run and build both in Windows and Linux.
We are using Microsoft TFS for source control.
For windows we are using Visual Studio.
For Linux we are using Eclipse. (I don't have much experience with Eclipse)
I had managed to configure and build properly the projects in both platforms.
I checked in TFS the .cproject and .project from eclipse, so I can use it in another computer.
Now I am trying to get the projects in another Linux computer and I don't know how to do it.
I tried following this instructions, but I don't have my source code zipped.
Other places like here suggest creating a new project.
Isn't there a way to open an existing project in Eclipse similar to Visual Studio?
Do I have to create a new project? If so, how can I keep the configurations I did to be able to build the project so other developer can use them?
File > Import... > General > Existing projects into workspace
Don't select an archive file. Set the root directory to where your .project and .cproject files are located. Your project should show up in the list. Make sure you don't forget to check the checkbox in front of your project.
Committing eclipse project files to a version control system is perfectly fine as long as you don't use absolute paths in your project settings. Use environment variables to specify paths which differ between developer machines.
I would love to import a Makefile project from Eclipse, and have all the different includes path that the compiler uses to create correctly my Eclipse project.
Unfortunately, those path, specified on the command line by a "-I" don't show up in Project Explorer and I have to add them by hand.
I am currently importing the project using the standard "Import project from Makefile" built in Eclipse.
If I'm not wrong there was an autodiscovery option in older versions of Eclipse, but it's not there anymore.
How do you do for having all your include paths set up without too much hassle?
The trick is NOT to use
File->New->Makefile Project with Existing Code
but to use
File->New->C++ Project
and then to select
Makefile project->Empty project.
After you set up such a dummy project, you simply copy your existing source to that project directory, hit F5 (i.e. Refresh) and change the build command to use your Makefile.
I was able to get this to work using Luna. I imported using File->New->C++->Makefile Project with Existing Code.
Prior to launching eclipse, you have to be sure to source any files that set required environment variables.
I did have some build options which were not the standard all and clean, so I had to add those configurations individually.
source files to setup your environment.
Launch Eclipse
Import C++ Makefile project
Setup Build options.
Click the hammer.
I have been following some tutorials for c++ game programing. I am kind of new to c++ and I'm using Microsoft Visual C++ 2010 Express IDE. I'm working on creating a game, and when I run the program through the IDE, it shows the grass sprites as expected. But when I run the .exe file from the Release folder, it shows weird images. and when I run the .exe file from the debug folder I get a grey screen. Can anybody tell me why this is happening?
I hazard to guess that your sprite images are kept as data files in your project folder. With that I offer the following premise:
The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the release folder, it is highly likely you are relying on project data files (images in your case) that are kept along side your source files in the project folder. When run from the Release folder, those files are no longer visible because your the Release folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.
I use VS2008 and try to answer your question. Right click on the project and select properties on the bottom of popup, then go to Debugging under Configuration properties. You can see command you run and arguments you pass in IDE. I guess you miss some parameters.
I have a tool that generates most (but not all) files that need to be compiled in Visual Studio. The tool reads a configuration file and generates c++ files afterwards. This list can differ from one call to another when the configuration is altered.
I am wondering whether it would be possible to adapt the compiling process to my needs, which would be :
Launch the tool (not needed if configuration file has been modified)
Retrieve new list of C++ files to be compiled (ideally isolated in a folder inside the project)
Compile C++ files
EDIT: Having to close Visual Studio for this process to work is a no-go for me. The idea would be to have cpp files dynamically added as the first step of the compilation process.
Use a pre-build step to run your tool.
Also, create a file containing the list of includes and sources
This file name should be fixed (so that you don't have to change project properties or the vcproj file) -- add it to the project. E.g:
Project Properties > Command Line > Additional Options > #headerListingFile
You are not trying to integrate lex/yacc output with VS, are you?
Would CMake help? It's an automated project manager that generates Makefiles and VS projects for projects you define. Just add a source file, re-run CMake and you're done.
I think what you should do is create a custom makefile and use that for builds.
Please see this page for more information.
I have a project in a c++ solution. For that project, I have some config files that I would like to manage from within the project and when I build the project, have those config files added to the executable build path in the proper directory structure.
Example:
test.exe references config/myconfig.txt
Is there a way to setup myconfig.txt and my project so when I build test.exe, I get
/
as well as
//config/config.txt
so when I run test, all paths stay in the proper order without me having to go in and manually create those directories.
I'm not sure I'm making sense here, but maybe one of you will understand where I'm going.
You could use pre-build events to create the directories and copy the files.
In Visual Studio's Solution Explorer, you can right-click on the non-code files, select "Properties" and set the "Copy To Output Directory" property.
This creates a rule in the build file to (1) include the file, and (2) to copy that file as part of the build process. In other words, it's possible to get this behavior without Visual Studio, but a little more work.