C++ development on linux - where do I start?

Question

I decided to leave my windows install behind and am now running Debian as my default OS. I have always coded in Windows and specifically with Visual Studio. I am currently t

Answer 1

• Recommendations for code editors? I am currently using nano and I've heard of vim and emacs, but don't know what the benefits of them are over eachother. Are there any others, and why would I consider them over any of the previous three? Note: I am not looking for an IDE.

If you're using Linux with a window manager (KDE, Gnome, etc.) you could also consider using the standard text editor for your window manager. The main benefit it would have over vim/emacs/nano is that it would seem more familiar to one coming from a Windows environment - an editor written to run on the window manager has a menu bar, file open/save dialogs, undo/redo, and plenty of other neat features that console editors probably can't match. (Though emacs and vim are pretty sophisticated these days, so who knows ;-P)

On KDE (which is what I use) I can recommend KWrite, which is a well-featured but fairly basic text editor with syntax highlighting; or Kate, which is a fancier text editor with some extra features: session management, a builtin terminal panel, automatic invocation of make, and several plugins including a C/C++ symbol viewer. I usually use Kate for my C++ work when I don't want to bother with setting up a full IDE project. (FYI the IDE for KDE is KDevelop)

Answer 2

Your question is a bit too general, but here is what I would recomment:

• Editor: vim and emacs are popular. What matters the most, as with most tools, is to master one. I like using vim because vi (its descendant) is available everywhere, but that may not be very relevant, specially if you stay on Linux. Any programming editor is fine.

• configure: unless you do big projects, don't bother with it. It is a nightmare to use and debug. It only makes sense if you intend to distribute your project - in that case, read the autobook: http://sources.redhat.com/autobook/. As other said, there are alternatives (cmake, scons, etc...). I am quite familiar with both scons and autotools, but I still use make for small (couple of files) projects.

Concerning shared library: it is almost as windows, except that you link against the shared library directly - there is no .lib vs .dll distinction in Linux. For example. for one library foo with a function foo:

int foo(void)
{
     return 1;
}

You would build it as follows:

gcc -fPIC -c foo.c -o foo.o
gcc -shared foo.o -o libfoo.so

A main (of course in real life you put the API in a header file):

int foo(void);

int main(void)
{
    foo();
    return 0;
}

And then, you link it as:

gcc -c main.c -o main.o
gcc main.o -o main -L. -lfoo 

The -L. is here to say that you want the linker to look in the current directory (contrary to windows, this is never done by default in Linux), the -lfoo says to link against the library foo.

Answer 3

So to get you started I will first point you to this guide for makefiles, it also covers some linking stuff too.
It's just a little something my university Computer Science prof gave us I found it to be very clear and concise, very helpful.

And as for an IDE, I use eclipse usually because it handles the makefile as well. Not to mention compile and standard output are right at your fingertips in the program.
It was mainly intended for Java developing, but there is a C/C++ plugin too!

Answer 4

Just a note to go with MandyK's answers.

Creating make files by hand is usually a very unportable way of building across linux distro's/unix variants. There are many build systems for auto generating make files, building without make files. GNU Autotools, Cmake, Scons, jam, etc.

Also to go more in depth about configure.

• Checks available compilers, libraries, system architecture.
• Makes sure your system matches the appropriate compatible package list.
• Lets you specify command line arguments to specialize your build, install path, option packages etc.
• Configure then generates an appropriate Makefile specific to your system.

Answer 5

What are recommended guides on creating a make file, how do I compile from this makefile (do I call g++ myself, do I use 'make'?)

I learned how to write makefiles by reading the GNU Make manual.

Looking at other linux software, they almost always seem to have a 'configure' file. What exactly does it do? Does it only check if the required libraries are installed or does it more than just checking requirements?

The configure file is usually associated with autotools. As the name of the script suggests, it allows you to configure the software. From the perspective of the developer this mostly means setting macros, which determine variables, which libraries are available, and such. It also tests for the availability of libraries. In the end the script generates a GNU Makefile, which you can then use to actually build and install the software.

The GNU build system is only one of many. I don't particularly like the GNU build system as it tends to be slower than others, and generates an ugly Makefile. Some of the more popular ones are CMake, Jam (Boost Jam might be of interest for C++) and waf. Some build systems simply generate Makefiles, while others provide a completely new build system. For simple projects writing a Makefile by hand would be easy, but "dependency checking" (for libraries, etc) would also have to be done manually.

Edit: Brian Gianforcaro also pointed this out.

Answer 6

I advise using SCons in place of Make, it does the same job but it's easier to use and handle out of the box how to make dynamic libraries, dependencies, etc. Here it is a real life example for a simple prog

env = Environment()
env.Append(CCFLAGS='-Wall')
env.Append(CPPPATH = ['./include/'])

env.MergeFlags('-ljpeg')
env.ParseConfig("sdl-config --cflags --libs")
env.ParseConfig("curl-config --cflags --libs")
env.ParseConfig("pkg-config cairo --cflags --libs")

env.Program('rovio-pilot', Glob('./src/*.cpp'))

As a text editor, I'm happy with JEdit for coding, but it's a matter of taste.