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.
Related
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.
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.
EDIT: I figured out that there is an option in Project properties to set a custom make file. Now the project build fine. Now, I am stumbled on how to specify the target executable to run when I click "Run".
Code::Blocks is an IDE (a buzzword for an editor capable of running other tools, including debuggers and compilers and probably some build automation tool), not a compiler (like GCC is) or a build automation tool (like make or ninja, etc... are).
You don't have to use Code::Blocks to work on your C project. You could use any other source code editor (I recommend GNU emacs, but the choice is ours) with other tools (compilers, linkers, build automation tool), that you can easily choose.
But if you do use Code::Blocks, be sure to read its user manual. Apparently, it is flexible enough to be configurable for your needs.
You can probably configure Code::Blocks to specify your project's executable. You probably want to configure it so that "build" means "run make". And since Code::Blocks is free software, if that configuration is not possible, you could patch and improve Code::Blocks (work on Code::Blocks' source code!) to add that feature. And since Code::Blocks may have plugins, you might code your own plugin to add new features.
My recommendation, if you discover that you have to patch the source code of Code::Blocks to add some missing feature: switch to another editor; with emacs configuring what is running, etc... is a matter of a few lines in my .emacs; you can write your own Makefile after having read the documentation of make and build your program by running make in a terminal; you probably can configure your IDE or source code editor to run that make command for you. Of course, you can run your gdb debugger and your program in a terminal too....
Of course you have to configure your operating system correctly so that make works in a terminal. That could involve setting correctly your PATH variable (and perhaps even installing GNU make on your system). How to do that is a different (and OS specific) question (unrelated to Code::Blocks).
Take the habit of reading the documentation of whatever software tools you are using.
In [Project -> Properties... -> Build targets -> Output filename] you may specify the executable.
[Project -> Set programs' arguments...] allows to select a host application and command-line parameters.
What we need in our firm is a sort of release management tool for Linux/C++. Our products consist of multiple libraries and config files. Here I will list the basic features we want such system to have:
Ability to track dependencies, easily increase major versions of libraries whose dependencies got their major version increased. It should build some sort of dependency graph internally so it can know who is affected by an update.
Know how to build the products it handle. Either a specific build file or even better - ability to read and understand makefiles.
Work with SVN so it can check for new releases from there and does the build.
Generate some installers - in rpm or tar.gz format. For that purpose it should be able to understand the rpm spec file format.
Currently we are working on such tool which is already pretty usable. However I believe that our task is not unique and there should be some tool out there which does the job.
You should look into using a mix between Hudson, Maven (for build management), Ivy (for dependencies management) and Archiva (for artifacts archival).
Also, if you are looking into cross.compilation, take a look at Make Project Creator (MPC) and Bakefile.
Have fun!!
In the project I'm currently working on we use cmake and other Kitware tools to handle most of this issues for native code (C++). Answering point by point:
The cmake scripts handle the dependencies for our different projects. We have a dependency graph but I don't know if is a home-made script or it is a functionality that cmake provides.
Well cmake generates the makefiles regarding the platform. I generates projects for eclipse cdt and visual studio if it is asked to do so in case of developing.
Cmake has a couple of tools, ctest and cdash that we use to do the daily build and see how the test are doing.
In order to create the installer cmake has cpack. From just one script it can generate tar.gz, deb or rpm files in Linux or an automatically generated NSIS script to generate installers in windows.
For Java code we use maven and hudson that have been already mentioned here.
Take a look at this article from DDJ, in which a more robust build system concept (than make) is presented and implemented. Not sure it will fit well to your requirements, but it's the closest I've ever seen. I was looking for the same thing months ago, and then I discovered the article.
http://www.drdobbs.com/architect/218400678
Maven has a native code plugin. I don't think it'll do everything you want, but it's good at tracking version numbers of dependencies, will build artefacts and it'll work with your VCS.
No idea
cmake/scons: I have used cmake but I don't exactly love it, but I have heard really good things about scons. But scons is python-based, so you need to have python installed on the build/dev machines.
I use Hudson, which has a plugin to fetch from svn. It performs intelligently in general, and in particular builds only if some file has changed in an svn update. Hudson is easy to get started with. Hudson is java-based and is pretty popular with the Java community. This means it is quite cross-platform, but you need to have JRE installed on the build machine.
Probably can call some rpm tool within hudson.
Is there a standalone tool, that can be ran from a shell script, to generate a makefile from the .cproject? Actually, the same functionality as the CDT itself, but that can be non-interactive.
As is probably obvious, I want to be able to run a script that checkouts and builds the software, comprising from several C++ project. I am trying to avoid moving to a build system like maven, as it seems as like an overhead in this early stage of our project. thanks!
I know that there was discussions on the CDT-dev mailinglist a few months back about having a command-line tool for building CDT projects. Writing such a tool is really not very difficult (there was an example mentioned), it is simply a matter of defining your own Eclipse-application, load the project, and build it. Searching the CDT-dev list on "standalone build" should give you some relevant hits.