Recently my project group bought a C/C++ codebase from a contractor which does not use Eclipse. Basically a big /src tree organized for building with Autotools, with a few top-level build scripts masking some of the Autotools complexity.
Developers on our project team have managed to set up the code in Eclipse (Luna) as an Autotools project...but what is currently causing grief, is that as we begin to work with this code, project CM is also moving to Jazz / RTC 5 (Formal process, not Agile) from ClearCase/ClearQuest.
None of us are clear about whether the code should go into the RTC repository in the form of a fully configured Eclipse project ready for developers to use.
My reading as a developer is that it must: if it doesn't, when I download the code to my repository workspace, I have to begin by bringing in new .project, .cproject, and .autotools files "behind the scenes" to get to a project that specifies the include paths I need, allows for C/C++ code analysis, and (hopefully) can be re-tweaked for Autotools building from within Eclipse. It also means when I deliver change sets back, it is likely to take a variety of error-prone workarounds to avoid delivering project-specific settings that aren't part of the codebase as conceived by CM. Right now, that's being held as close as possible to the contractor's delivered (non-Eclipse) package.
What I'm hoping, is that anyone can tell me if it is standard practice when using RTC with Eclipse, to set up one's code in RTC in the form of fully configured, ready-to-use Eclipse projects. The language used in the articles I'm finding suggests it, eg., talking about "Find and load Eclipse projects", but nothing I'm seeing makes this explicit.
is that anyone can tell me if it is standard practice when using RTC with Eclipse, to set up one's code in RTC in the form of fully configured, ready-to-use Eclipse projects.
That is a standard with any source control tool.
See "Shoul I keep my project files under version control?" or ".classpath and .project - check into version control or not?".
RTC simply suggest to create a .project just to reference the files of the component in the Eclipse workspace (as a convenience, to facilitate the file exploration of a given RTC component).
But that is separate from having a full-fledged .project, with many additional settings configured there.
I do not keep IDE specific files under version control.
You basically have an autotools project so what I do with that is put all the source autotool files (autogen.sh, configure.ac, Automake.am) under version control.
I also have a couple of scripts to setup autotools under different basic configurations (configure-debug.sh, configure-release.sh).
Then each developer simply runs the scripts which produce Makefiles.
Now they can use any IDE they wish based on the Makefiles. Each developer should be capable of working from a Makefile at least.
In eclipse I create an unmanaged "Makefile" style project and plug in the Makefiles that autotools produces.
But the project is not bound to eclipse, it is bound to any environment that runs autotools. Developers can use whatever IDE they prefer.
Related
I work in the embedded C programming domain and someone asked me what's the build system of my project. I am working in STM32CubeIDE using |GNU Tools for STM32| toolchain. I didn't have to create a Makefile for my project as it's automatically generated by the IDE. So what is build-system? Is it referring to how I build the project?
Does the image below have any relevance of the build-system?
Any information will be helpful.
Thanks.
Since it is set to "external builder" and GNU tools, then presumably make - though not necessarily - the IDE could implement its own management rather then explicitly generating and executing a makefile.
If you are exclusively using the IDE to manage and generate the build for you then "STM32CubeIDE with GNU Tools" is probably a reasonable answer too regardless of how it actually implements it. Knowing what tool it uses under the hood is useful if you have to do command line builds for continuous integration or automated release for example.
He asked you how you build your project. Is it make, cmake, VSbuild or something else.
Maybe you use autotools or another project generation system.
Simply put:
In eclipse how do I run a shell/batch script when I build? I have an external tool that can be run by hand but I want to trigger it when the project is built. Using build variables in the script would be an added bonus.
Why I want this:
I work on multi-platform games for mobile. The teams in the company I'm at use X-Code, Visual Studio, and Eclipse (Momentics) for our games. We want to be able to pick up a phone and see overlay on-top of it with information such as who built it, when it was built, what branch and revision it's from, and what library versions are being used. I've done this with X-Code by running a script on build that dumps some of that information to the resource directory of my game that I can then parse at runtime. It's really simple and I'm up for alternate suggestions if you have them; keeping in mind it must work for the three IDE's our developers use.
Bonus Sugar:
In X-Code we can use build variables which would be super nice to have for eclipse as well. I use them to change to the active cocos2d-x repository and get a git log to tell us when the last commit to that repository was made and by who. If that isn't possible in eclipse I can figure something out.
Thanks in advance!
Add a custom builder to your project: open Project properties from the popup menu, on the builders page add a new Program. That will open a "External tool configuration" page.
There you can define a script to run, and also add parameters, where you can add Eclipse variables, such as ${workspace}, etc.
Be careful though: this will run every time when the incremental project builder runs, and the configuration is shared through version control (so beware of absolute paths).
I am currently working on an opensource C++ project. I don't have much experience in C++ as my daily job mainly involves with Java. I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project. E.g, in Java, all the class files are packaged into jar file. So what is the equivalent approach in C++? Is there any good practise for organizing the source code/binary? My target platform is Linux by the way.
Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project and use it as generic build script? Is there any good reference regarding C++ build/packaging? Thanks in advance.
Edited
To clarify a bit more, I think the release of my project can be considered as an application. It's a command line tool for software configuration management.
I am currently working on an opensource C++ project.
That simplifies many things. You should supply the build scripts for you project and support them for different use cases (learn about Makefiles, there are similar concepts like "target").
I don't have much experience in C++ as my daily job mainly involves with Java.
Most of the things you're used to have (and ask for right now) in Java are invented because they lack in C/C++. Learn at least something about dynamic(shared)/static libraries (.so and .a files to be simple).
I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project.
The "packaging of a C++ project" is something informal. You may supply the sources, build scripts and some project-files for the well-known IDEs.
EDIT: you've specified that you're building the command-line application. I believe all you need is to start from a simple Makfile for that application. The reference Makefile can be automatically generated by Eclipse. If you are planning to deploy your application as a stand-alone software, then you have to earn about packaging (rpm, deb, tgz).
E.g, in Java, all the class files are packaged into jar file.
There are no such thing as a C++ "package" compatible accross compilers (even the "modules" were rejected in the latest C++11 standard)
because there is no binary standard to encode C++ classes (ABI). On linux you're most likely going to use GCC (or Intel's compiler, or LLVM's CLang, or custom build of OpenWatcom or...),
but the version of standard library you are linking to makes the release of binary builds close to useless.
That is the reason for redistibuting source code.
So what is the equivalent approach in C++?
No clear answer here.
Is there any good practise for organizing the source code/binary?
Look at the large-scale projects, see the way they organize their builds. The term "build engineer" as an occupation emphasizes the difficulties of large-scale projects compilation/linking.
My target platform is Linux by the way.
This is also something of an incomplete description. "Linux" is a blurry term. You should speak about the Linux distribution, compiler toolchain and package manager. E.g., Ubuntu 12, amd64, GCC 4.6 toolchain, APT package manager.
There are different "linuxes" built around the same kernel source. There are different compilers. There are at least three major package managers to consider: Debian/Ubuntu(deb,apt), Red Hat(rpm), Slackware(tgz).
Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project
There's a sort of "meta-technique": you write a "description" of your project and then a tool generates the project-file and build scripts for your sources. Have a look at CMake. Since you're on "linux", try looking at the somewhat standard way of autotools (autoconf).
Is there any good reference regarding C++ build/packaging?
You should start by building your application and then move on to the deployment issues. C/C++ is a hard-to-learn legacy with a lot of subtleties which are avoided in Java.
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.
I haven't done much "front-end" development in about 15 years since moving to database development. I'm planning to start work on a personal project using C++ and since I already have MSDN I'll probably end up doing it in Visual Studio 2010. I'm thinking about using Subversion as a version control system eventually. Of course, I'd like to get up and running as quickly as I can, but I'd also like to avoid any pitfalls from a poorly organized project environment.
So, my question is, are there any good resources with common best practices for setting up a development environment? I'm thinking along the lines of where to break down a solution into multiple projects if necessary, how to set up a unit testing process, organizing resources, directories, etc.
Are there any great add-ons that I should make sure I have set up from the start?
Most tutorials just have one simple project, type in your code and click on build to see that your new application says, "Hello World!".
This will be a Windows application with several DLLs as well (no web development), so there doesn't need to be a deploy to a web server kind of process.
Mostly I just want to make sure that I don't miss anything big and then have to extensively refactor because of it.
Thanks!
I would also like a good answer to this question. What I've done is set it up so that each solution makes reference to a $(SolutionDir)\build directory for includes and libraries. That way each project that has dependencies on other projects can access them and versions won't compete. Then there are post-build commands to package up headers and .lib files into a "distribution" folder. I use CC.net to build each package on checkin. When we decide to update a dependency project we "release" it to ourselves, which requires manual tagging, manual copying current.zip into a releases area and giving it a version number, and copying that into the /build of the projects that depend on the upgrade.
Everything works pretty great except this manual process at the end. I'd really love to get rid of it but can't seem to. Read an article from ACM about "Continuous Release" that would be really nice to have an implementation of but there isn't any. I keep telling myself I'll make one.
If I use "junctions" in the windows filesystem I can link "distribute" to "build" and then build a secondary solution that includes all the projects that are dependent on each other to build a product. When I did that though it encouraged developers to use it for active development, which discouraged TDD and proper releasing.