I am currently developing a software with some partners. We are using Codeblocks to manage the project, and are likely going to be using SVN as a versioning tool.
However, as I already used SVN to work on a report with latex, I'm aware that some files are completely unnecessary.
My question is therefore a little bit broad. How do you think we should proceed using the SVN repository ?
Should we put the C::B project directory directly inside the SVN repository ? (I assume we will have some problem with the project options, as the library are not in the same place for everyone)
Should we put only the source files in the directory and "link" the source files to a codeblocks project outside the SVN repository ? This solution may allow other IDE to be used with the same source files, right ?
Best regards,
Al_th
i think you shouldnt stick to one IDE. Better solution is to create universal build system like Makefile or Cmake. With MakeFile you can easy import project to all decent IDE's.( more of them even support to download project from remote repository)
With universal build system you can use it with your own favourite IDE or even compiler.
I would also consider to change C::B to kdevelop it is fully suporrted with SVN/GIT/Cmake/Make. Also there is support for c++11x.
Isnt it more related to programmers than c++ stackoverflow?
Related
We have a team of several members using Eclipse for a C & C++ application that we commit the make files it generates as part of the package build. I have added and committed a library to the project then we decide against using it. So I remove it from my project and commit the change to git for the rest of the team. When anyone else pulls the change their Eclipse reverts the removal to the .cproject file preventing the removal of the unwanted library, include paths, and toolchain paths. The only thing that seems to work is to blow away the project metadata and re-import the project, which is a hassle.
How do I easily get everyone else's Eclipse to accept the removal and stop adding it back in?
Thanks.
The issue comes from not committing the .metadata folder. Eclipse keeps a backup of the project somewhere in there and continually changes these file making it unreasonable to commit to source control.
The only thing I've found to always work is to delete the project from the workspace, but do not remove the files, and import the updated project after pulling the updates from source control.
You and your team may not be able or willing to do this, but it is easier to not check in IDE specific files at all and allow a build tool plugin like Maven or Gradle to handle the project structure and classpath. This is how I've worked with team members for years without experiencing this problem.
There is quite a bit of a paradigm shift doing this, and depending on the flexibility of your project it may not be feasible.
Edit:
I noticed you are of the C persuasion. I don't recommend Maven, but consider Gradle.
https://docs.gradle.org/3.5/userguide/native_software.html
I do a fair amount of personal development on my computer and have used TortoiseSVN (I'm on windows) for web projects, but haven't used any version control for other languages. Anyways, soon I will be starting a decent sized C++ project and was going to try using SVN for it.
For web development, I normally just used notepad++ and it was really easy to manage it with SVN (just commit the whole source folder). However, for this project I will be using an IDE (most likely Eclipse CDT or Visual Studio) and was wondering what the best practice is to manage all of the IDE, project, and binary files. My guess was to make the IDE project outside of the version control, and just point to all of the source files into the SVN so all of the build and project files aren't committed. This way the only files in the SVN would be the .cpp and .h files.
However, if I wanted to switch to a new branch, then I would need to update the location of all of the source and headers to the new folder which seems like it would be a huge hassle.
Whats the best way to handle this?
Thanks
Ok, it seem I misgot the aim of the question in the first round. Now I'm assuming what is asked really to what to put under source control and what not.
Well, naturally everything but temporary/transient files.
If you install GitExtensions, it right away has a feature to populate the .gitignore file. Certainly depending on language you adjust it. Sure, solution, project, make files belong under control. .USER files storing some IDE preferences do not. As both IDEs and source control is ubiquitously used the content is fairly separated for many years, and should be pretty obvious as you do it.
External dependencies normally also shall be in a repo, though choice shall be made in which one. Some store everything together, others keep one dependency repo, others separate repos per component -- all depends on actual components and workflow. And you can replace physical storage of deps by an info file with stable links to the used version. It may also be covered later on the first change in dependencies.
For Visual Studio, there is a plugin that manages your files for you. As long as the files are part of the project, then they will be put into source control by the plugin. See ankhsvn for plugin info. Note that the express versions of Visual Studio are not supported.
I am sure eclipse has a plugin for SVN as well.
i have source code of vc++ project. Now I am using linux.
i know how compile a single file .cpp not a whole project. So how to compile a VC project using g++ ?
A slight advantage of Makefiles would be possible integration with autotools (cough - It might prove handy to get the starting point for feature macros).[2]
There is a tool as part of winemaker that is EXCEEDINGLY helpful with fixing up a source tree that was assuming case insensitive names to work on a case-sensitive filesystem. (_it was intended mainly in order to build against winelib but that is not required)
If you want to keep using windows API's for some parts of the code, you can consider compiling with winelib (and use winegcc, producing WIN32 executables; I'm not sure whether this is what you want)
[2]: SCons is a very nice tool though
First step would be to generate Makefile out of vcproj file.
There are (obviously) some tools for that:
http://www.codeproject.com/KB/cross-platform/sln2mak.aspx
There is no easy way to do it. As others have suggested you can figure out how the build process works for this project (maybe by reading the build output in VS) and recreate that using your favorite linux build tool (scons, cmake, autotools etc.). The alternative is to use a converter tool. Aside from the below mentioned sln2mak, there is also winemaker. The docs for winemaker have a lot of old info like most linux tools docs but it can convert a .sln to a makefile. I am not sure about newer vs .sln files.
I am trying to open an existing C++ open-source library in Xcode to publish it with my own modification/additions. The library is Tesseract-OCR, which does not include a .xcodeproj file.
Since Xcode can function as an IDE, is it possible to open a bunch of files as a single project in Xcode? Is there an easy way to produce an Xcode project?
There are several ways you could do it, depending on the level of IDE integration you want. There's no direct way of importing a Makefile-based project into Xcode. You can create a project that builds via the Makefile, but you wouldn't get many of the benefits of using an IDE, since the editor features such as word completion rely on Xcode being able to parse the files in the project. You will be able to use the debugger though. To do this, create a new project and add a custom target with a script build phase that just calls down to Makefile.
If however the project you're building compiles very easily, ie without requiring a lot of macros to be set up, include paths, etc, then it may be simple to just create an empty project and merely add all source files to it. I've used this method extensively for building boost libraries. If this is a configure && make type project then you will probably have to run the configure step first, and ensure any top level config.h files are included in the project.
If the project has a complex makefile then it is likely to be an involved task to create a useful Xcode project
I realise you asked explicitly for Xcode, but in case you were actually trying to solve the problem of "I have existing C++ code which builds and runs fine from the command line, and I'd like to code and debug it in an IDE, what should I do?" my firm recommendation would be to avoid Xcode and go for Eclipse.
The reason is that as far as I can tell, Xcode has no way of ingesting the command line build environment and effectively requires you to recreate the make process inside Xcode from scratch. Fine for tiny projects, but anything with more than a few source files and it quickly becomes painful. Whereas in Eclipse everything is built around Makefiles. So in my case I got to the "step through code with working code completion" in Eclipse a lot quicker vs. never in Xcode. This of course could be because I'm an Xcode noob, but my 2c.
To create an Xcode project from an existing cmake project, you can run cmake -G Xcode. It produces some folders and files apart from the project file, so it might be better to create a folder for it first. For example:
mkdir -p build/xcode
cd build/xcode
cmake -G Xcode ../..
Xcode is a useable IDE for library creation.
Of course a good first step is to see if the one source code will build on its own with configure scripts that are included.
If not, it becomes a question of how many libraries you need to link in.
There are resources online (or at least there used to be) for using Xcode (or perhaps it's forerunner Product builder) for porting Unix projects to Mac.
Good tutorial at: http://www.macresearch.org/tutorial-introducing-xcode-30-organizer
Another good reference is Darwin Ports.
As for doing this on your own. You can build c++ based libraries in XCode. People do that every day. You can even use one of the Xcode templates to get you started.
However, library dev requires more experience with Xcode then say a simple Cocoa "Hello World" app.
The remaining questions will be assuring that the source code's dependencies are already built into the Mac's SDK. (Don't hold your breath for linking to MFC)
It's a general question... So it's a general answer.
In Xcode8,there is "Xcode->file->add files to...",then choose your files.If you want to add several files at a time,press "Cmd" when you are choosing.
Is it possible to combine the following properties, and if so, how?
Store in our version control system some Visual Studio 2008 native C++ (VCPROJ) project files for the developers in our team that use this IDE.
Allow some of those developers to tweak their projects (e.g. using debug version of third-party libraries instead of the usual ones).
Make sure these modifications are done in files that are not versioned.
In other words, I would like to allow developers to tweak some settings in their projects without risking that these changes are committed.
An 'optional VSPROP' file approach seems doomed to fail, as VS2008 refuses to load projects that refer to non-existent VSPROP files...
Any other suggestion? Is this possible with VS2010?
You may not be able to do this but using a solution that generates the vcproj like CMake for example would let you do this. Scripts all your project with CMake and literally conditionally include a config file(if present for example) that developers can change on their setup.
Branches could solve this problem: you create a branch, play with different versions of third-party, merge changes to trunk if results are good.
Well, as a preliminary solution you could put the project file into something like .hgignore or .gitignore after its initial commit.
This way changes to it can't be done accidentally.
At least that's how I handle .hgignore itself.
We use a versionned "common_configuration" folder, and a script which copies project files from this "common_configuration" folder towards the "project" folder.
We have another script to copy the configuration backwards, so the developpers need to make a conscious action to commit their local changes to the global version control system.
It answers partly your needs :
The upside : we have a way to keep a common configuration for everyone, and no accidental committing of local configuration
The downside : blindly copying the files actually crushes local changes. We live with it. We could write some more clever merger tool (using diff, or xml specific manipulations), but don't want to spend to much time on supporting the deployment tools.