C/C++ dev -- IDE versus command line

[j_g]

In another thread (that has been closed), someone asked about using an IDE versus just invoking the compiler/linker via a command line. Since I just started Linux C programming a few weeks ago, I'd like to give my own observations/opinions to a fellow programming newbie. I realize that others may disagree with these observations/opinions, but that doesn't make my own invalid. In fact, since the OP has already expressed a frustration over some of the very same things I found frustrating, it's likely that my observations/opinions would be more applicable to him than the opinions of someone who would simply disagree without having any empathy/understanding for the OP's point of view.

I have to say that I love IDEs. A good IDE should have a logical, easily-navigated UI to create applications. The UI should allow the enduser to easily enter all of the data needed to compile/link the app, and the IDE _should_ do whatever needs to be done to successfully invoke the compiler/linker to create the app.

An example of a good IDE that does exactly that is Microsoft's Visual Studio. It uses fully complete wizards to guide the process, and its underlying tools are well integrated with the IDE. When you finish the wizard, Visual Studio directly creates the needed makefile. It's easy and painless to develop Win32 apps using MS tools.

An example of a bad IDE that doesn't do this very well is Anjuta. Anjuta's wizard takes you only half-way gathering all the info it needs, then it runs some not-so-well-integrated GNU tools which, too independently of Anjuta, try to analyze your system and come up with the remaining necessary info to create the makefile. It's painful and difficult to develop Linux apps with Anjuta.

Part of the problem is that Anjuta is buggy. It recently got a _long-overdue_ update, but I get the impression that too little development time is being devoted to a tool that needs much more attention than it gets. Sometimes Anjuta works and sometimes it doesn't. For example, once I got the scintella editor to work on editing source files, but usually that locked up Anjuta as soon as I selected it, and I had to use the GtkTextEditor (or whatever it was called) instead. Of course, I haven't used the latest Anjuta version because I couldn't get the thing to compile on my system, using the previous version of Anjuta, and the "Anjuta project file" with the newer sources. When an IDE can't even make a new version of itself, given its own project file, that's a really bad sign. The Ubuntu repository still doesn't have the newer Anjuta. And I needed the newer Anjuta because I used Glade2 to create my UI, and the older version of Anjuta didn't support it.

So right there, I'd advise you to swear off of Anjuta, because I don't believe the support is as good as it needs to be for hassle-free development.

Another part of the problem is that Anjuta uses a lot of the GNU tools (autoconf, automake, etc), which strive to create "universal" dev files that take into consideration every possible configuration quirk of the thousands of Linux distributions made by Tom, ****, Harry, and their dogs Spike, Fido, and Spot. But this is a nightmare for a newbie who wants to just compile, link, and run his C/C++ program on his single installation of Ubuntu. He doesn't need to take into consideration some quirk of "Martian Christian Linux", yet another pointlessly trivial variation of Linux which, for god knows what reason, is supposedly better for Martians who also happen to be christians. The GNU tools spout out dev files that are humanly unreadable and uneditable by all but the extraterrestrial beings who devised the incomprehensible, needlessly convoluted alien "language" that these tools use. This is bad news if you need to hand modify one of these files because Anjuta didn't quite get something right (and believe me, it's a good bet that Anjuta's "output window" will demonstrate blissful ignorance as it chuffs out autoconf error messages telling you to hand edit your configure file to add this or that). Anjuta isn't smart enough to parse the error output of the GNU tools and follow the instructions given to you, even though it's supposed to be the job of a good IDE to maintain and "edit" the underlying compiler/linker support files instead of telling you to do so. Otherwise, what's the point of an IDE?

For this reason, I opted to get rid of Anjuta. I simply installed gcc, and all the dev libraries I personally needed, such as libglade2, gtk2, etc. Then I wrote my code with gedit, created a simple makefile for my needs, and just ran the make utility for a terminal window. It worked for me much better for me than Anjuta did.

One of the real breakthroughs I made with regards to specifying libraries in a makefile is use of the utility pkg-config, with its --cflags and --libs options. These options will look up the Include path, and library path of a particular package. For example, open a terminal window and type:

pkg-config --list-all

This will list all of the packages installed on your system. Let's assume that you've installed gdk2 (Gnome) package, and so "gdk-2.0" appears in the list. Now type

pkg-config --cflags gdk-2.0

This will spit out a line such as:

-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include ... etc.

It is essentially what you supply to gcc when you want to tell it all the paths to the include files for an app that uses gdk2.

Now type

pkg-config --libs gdk-2.0

This spits out a line that is what you supply to gcc when you want to tell it all the libs to link to for an app that uses gdk2.

So to put it all together, here's how you'd specify a makefile to use pkg-config to compile a source file named MySource.c into MySource executable, specifying include files and libraries for the gtk2, and libglade2 packages. Note that you need to surround each pkg-config invocation with ` characters.

CFLAGS=`pkg-config --cflags libglade-2.0` `pkg-config --cflags gtk+-2.0`
LIBS=`pkg-config --libs libglade-2.0` `pkg-config --libs gtk+-2.0`
OBJECTS=MySource.o
# Comment the next line to create a version without debugging
LDFLAGS=-g

MySource: $(OBJECTS)
gcc $(LDFLAGS) -o $@ $(OBJECTS) $(LIBS)

MySource.o: MySource.c
gcc -Wall -c $^ $(CFLAGS)


And that's it. Just name the above file "makefile" (in the same directory as MySource,c), and type "make" at the terminal. This is a hell of a lot less painful than dealing with an IDE that isn't quite up to the task of hassle-free development.

[cybrid]

I cannot make a response according to your statements since I haven't tested anjuta that deeply, but I must say that a lot more of attention should be put on it since I belive that gnome needs a good, solid, fast IDE, that way I think that much more programmers would be interested in doing GTK bassed apps. Personally I feel a lot more confortable programming in the windows enviroment using MS VS.NET, and I really would like to develop apps for Gnome but setting it up everything is a pain in the *** and so it's using anjuta

[lnostdal]

ok, i'll put up a third writing ( http://nostdal.org/~lars/writings/ ) by the end of the day and i'll show that it is really-really simple and fast to do GTK+ development .. and no anjuta is needed (or you can bypass all the problems in anjuta by making anjuta use your own simple build-tools/scripts)

..will post here again when it is done..

[lnostdal]

Ok, `ubuntu-programming3.pdf' is up at http://nostdal.org/~lars/writings/

..can anyone confirm that Anjuta is able to use Scons directly in the manner described (very briefly) at the end? I'm hoping that would solve some problems as Scons is "good enough"(#1) in most cases while still being simpler and more human-readable than most of the autoconf/makefile hair produced by Anjuta (IMHO YMMV ..etc.).

#1: Heck; Doom 3 was compiled using it!

[cybrid]

Damn, there is a myriad of buld/conf tools around, Inostdal since you seem to know what you're doing, could you put a list of tools? and what they're for?, it would be great not having to search for them, you know, autoconf, autobuild, scons, automake, auto . . . .

[j_g]

I read your PDFs, but to be honest, I didn't care for some of the tools you picked out, starting with your choice of text editor, and ending with your choice of frontend for gdb. Using those tools makes me feel like I'm back in 1986 using my Amiga 1000. They have very dated UI's. Although they may work fine for you now that you've spent a lot of time getting accustomed to them and setting up your own environment, I don't think that the UI's of the tools you're using are apropos for beginners who weaned themselves on modern UI's. And I fail to see the point of using tools with arcane UI's to develop apps for a modern UI with modern UI toolkits such as GTK+ and libglade.

I would recommend that a beginner use a more modern text editor such as gedit. I also found kdbg to be a fairly serviceable frontend to dbg. It's definitely not as nice as Visual Studio's debugger, but it at least has a serviceable UI including such things as Watch windows, and unlike Anjuta's dbg frontend, it isn't buggy as hell. I haven't been able to find a decent dbg frontend for Gnome, but kdbg works.

I looked over SCons, but my reaction is that it is definitely no substitute for an IDE frontend to a compiler/linker. It is therefore simply yet another variation of the same approach taken by GNU's dev tools (ie, the programmer must learn yet another "programming syntax" in order to write a hand-written "make file"). For this reason, I don't consider it any more or less useful to a newbie programmer. There are things about it that may make it easier to hand write/edit the make file than with the GNU tools, but it's still a complex and error-prone task for a newbie. I would neither recommend nor dissuade a new programmer from using it. I would simply say that it is an alternative to the assortment of complex "make tools". SCons may have some advantages in some ways, but nevertheless is complex and difficult for a new programmer to use.

(As an aside, in looking over the SCons docs, I noticed that the SharedLibrary example does not issue the -fPIC compiler option. I'm not sure if this tool is designed for creating dynamically loaded shared libs. Furthermore, the docs completely neglect detailing how SCons would be used in conjunction with a packaging tool like rpmbuild. Therefore, it may not be appropriate for a programmer wishing to package his software for a "repository". So there may be disadvantages to this tool, compared to GNU alternatives).

[lnostdal]

I read your PDFs, but to be honest, I didn't care for some of the tools you picked out, starting with your choice of text editor,

That choice doesn't really matter. Any editor that can call external tools and parse output could be used there.

Main point is to show usage/setup of a distributed set of tools that are able to communicate instead of an integrated set of tools. But pick your set of tools as you wish here.

And I fail to see the point of using tools with arcane UI's to develop apps for a modern UI with modern UI toolkits such as GTK+ and libglade.

Hm, is there any point in-itself in only using a single UI-toolkit when there are tools out there using a different UI-toolkit that _might_ (imagine this even if you feel this isn't so in reality) be better? For instance, I use both Motif, QT and GTK+ applications under Ubuntu. I do not view that as a "point", as if I "must" use tools that use different UI-toolkits - or even a real problem(#1).

The only "point" for me is to use good tools that work -- regardless of UI-toolkit. I prefer tools which do specialized tasks well: http://en.wikipedia.org/wiki/Unix_philosophy (but again make your own picks here)

What UI-toolkit the tool use doesn't really matter at all as long as it is _good_ at what it actually _does_. This immediately turn what UI-toolkit the tool uses barely noticeable -- at least for me.

I would recommend that a beginner use a more modern text editor such as gedit.

Well, can gedit parse the output of GCC and jump to the line/file the messages from GCC refers to? Can it split windows so you can view multiple files at the same time? Can it fold code? Does it have an auto-complete feature? Class/symbol/function-browsing? ..etc..

I don't really know the answer to those questions; that's probably why I picked the tools I did. But about the "modern"-part; gedit only has a fraction of the features Emacs has - that I am sure of. So modern can mean different things depending on how you look at it.

But again the main point with the articles is to try to show usage of a distributed set of tools that are able to communicate (GCC --compile-messages--> Emacs). Pick another editor if you like.

I also found kdbg to be a fairly serviceable frontend to dbg. It's definitely not as nice as Visual Studio's debugger, but it at least has a serviceable UI including such things as Watch windows, and unlike Anjuta's dbg frontend, it isn't buggy as hell. I haven't been able to find a decent dbg frontend for Gnome, but kdbg works.

I don't see what's wrong with DDD. You mention watch-windows; DDD has those of course!

Actually, at first sight - DDD seem to have a lot of features kdbg lack. But I might be wrong about that - and it doesn't really matter. You're free to pick any front end and that is a good thing IMHO.

I looked over SCons, but my reaction is that it is definitely no substitute for an IDE frontend to a compiler/linker.

Ok, I fully disagree here. I think this question is like the Vim vs. Emacs question.

So we disagreeing here doesn't matter(#2) in regards to the article as there are many people on "both sides". The article is for people who already want to take the distributed-tools approach and not the IDE-approach.

But just to make sure; you do not think using Scons means that you actually have to call Scons from the terminal? That is exactly what I'm trying to show how to avoid while still keeping tools separated!

It is therefore simply yet another variation of the same approach taken by GNU's dev tools (ie, the programmer must learn yet another "programming syntax" in order to write a hand-written "make file"). For this reason, I don't consider it any more or less useful to a newbie programmer. There are things about it that may make it easier to hand write/edit the make file than with the GNU tools,

Yes, and that's the whole point.

The other approach of using an IDE with everything "in it" is something I had no intention of criticizing(#3) or writing about - as I know almost nothing of those things.

The article was however posted as a reaction seeing as there has been a lot of people having problems getting started with GTK+/Glade using Anjuta or the IDE-approach in general(?) and there didn't seem to be _anyone_ who could help them with these problems(?). I couldn't really help them with these problems using their approach, so I chose to post an article that shows another approach. Feel free to post a response showing how to do these things in Anjuta or another IDE. I'd actually enjoy that as I haven't checked out Anjuta or KDevelop in many years.


#1: Actually this diversity in toolkits might have brought good things. The good tools might not have been created if the developers had only one choice in toolkit and would happen to not like that one toolkit.

#2: But I do understand the topic here of "approach as a whole" vs. "other approach as a whole". I'm just not very interested in discussing that. I'd like to leave that up to you guys if I can (yay .. no lord .. lol) while focusing on helping the people who might want to try this approach.

#3: Well, I did mention "hair" and "mess" in context with Anjuta .. but still :}

[lnostdal]

(As an aside, in looking over the SCons docs, I noticed that the SharedLibrary example does not issue the -fPIC compiler option.

env.SharedLibrary('lib/oxymora-util', Split(""" ..... """))
....
g++ -o oxymora/util/debug.os -c -g -Wall -fPIC oxymora/util/debug.cpp
....

It has both support for creation of static and dynamic libraries. It's not a problem.

Furthermore, the docs completely neglect detailing how SCons would be used in conjunction with a packaging tool like rpmbuild.

This shouldn't be a problem either, but I can't help you with this off-hand as I haven't used rpmbuild before.

[cybrid]

Hey, you both, this was begining to be a very helpfull thread about begining GTK with commandline tools, now it seems more like a rant GUI vs Command Line (well, that thread's title) and I think helping is better than ranting so. please Inostdal, could you continue with your tutorials?. They are helpful. If needed this could be moved to another separated thread

The fact is that since I began programming C/C++ under Windows and MS VS, I didn't know what a makefille was for untill today, after reading Inostdal tutorials, so thank you

[lnostdal]

thank you for your response ..any suggestions as to what i should write about next? (#1)

If needed this could be moved to another separated thread

yes, that might be a good idea .. i'll post the next tutorial in a separate thread dedicated to these little articles alone


#1: i had some sort of plan or a list of things i was going to write about (in response to often asked questions etc.) somewhere but i seem to have misplaced it ..