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

[cybrid]

I think that a small tutorial about "definitions" would be great, I think a lot of programmers comming from a windows enviroment get confused (like me) with the ton of tools GNU/Linux offers.

Maybe something explaining the difference between the different tools and things like what a makefile is, the packaging utilities and so...

[j_g]

I know _exactly_ where you're coming from. I'm a Windows developer. I've used various GUI driven dev tools such as VB.NET, MSVC, etc. I always knew what a makefile was for, even when I was using those tools. It's just that I never had to actually hand-edit any makefile, nor create _any_ other convoluted text file containing any kind of "macro/shell language" for the purpose of creating a make file. I never had to, because the IDEs were capable of completely managing the makefiles via data that I entered exclusively through the UI.

If you go to the GNU website, you'll find tons of "manuals" that explain to you in excruciating detail what each tool is for, and how it works. Here's a URL to get you started on your quest through dozens and dozens of pages:

http://www.gnu.org/manual/manual.html

Now I suppose someone can write even more detailed tutorials than these pages, and take you along the way at a slower pace (although it would probably take a person a few years of work to come up with such a volume of text), but here's the bottom line:

These are very complicated, convoluted, and frankly from a perspective such as yours and mine, unintuitive tools to use. You can read all these manuals until your eyes fall out, and your brain can maybe retain enough of the voluminous details of each tool such that you'll actually be able to do something useful with them. (I know, because I'm actually creating Linux software with them right now). But they will never be easy to use. They will never be as easy as VB.NET. Never. They will never be half as easy as VB.NET. They will never be a quarter as easy as VB.NET. These tools are designed to take into account so many variables/installations/quirks in the entire Linux universe, that they can never be anything but tremendously complicated and convoluted and unintuitive. Think about it. Someone somewhere at this very moment is taking a Linux distribution, and for god knows what reason, changing one damned thing about it supposedly to make it better, and releasing yet another distribution. And now the GNU tools have yet one more quirk to take into consideration. Let's see, shall we accomodate it by making yet another "implicit rule", or maybe a "macro", or how about an "environment variable"? How about all 3 of them? Hey, it's free software so it's not like you have to pay 3x as much for all 3 things. And wait, this is getting really hard to use what with all this stuff heaped on top of it. So let's make another utility that spits out a bash script that makes the data file needed by the first utility. And of course, let's not make this second utility UI based, with controls the programmer can click on to select his features, and enter filenames, and such. No, let's make this second utility text-based just like the first one, so that you need to learn yet another "macro/shell/syntax language" and have even more data files to keep track of. And of course, as more and more deviations happen in the Linux world, we'll add stuff to this second utility too.

Finally, someone gets the idea to make things "easier" than those tools. What does he do? He makes another text-based utility of course, with yet another macro/shell/syntax language that tries to cover the exact same ground as the first set of tools. Yep, this one is going to be all things to all people too, but somehow it's going to be better. Now we have two tool sets that essentially do the same thing, and even in essentially the same way, but they're different for the sake of being different. But wait. Now we need to transfer data between the two of them, so we need to make a utility to do that. And no, let's not make just one such utility. Let's divide our resources making dozens of them, each one doing essentially the same job, but in an arbitrarily different way that will somehow mean that support personnel will have to deal with yet more quirks/inconsistencies/variations on the exact same theme.

Madness. Sheer madness.

These dev tools are so complicated that even the IDE that tries to make them easier, is itself convoluted, complex, and ultimately unintuitive.

This is what you're dealing with in Linux. The only way to avoid it is to go back to my very first message in this thread. Fire up Gedit to write your C source. Go ahead and write a C file that compiles only on Ubuntu. What's that? Tom's distribution doesn't have a "sys/types.h" include file? And it puts its "socket.h" file in the "sys" directory instead of the main include directory? Too bad. Tom wants to use something that achieves essentially the same results, but arbitrarily chooses to do it differentl? Then, let Tom deal with the hassle of incompatibility.

Then use Gedit to write a very, very simple makefile like I described. Forget about all those "auto" utilities. Go ahead and write a makefile that works only on Ubuntu. Say no to every other Linux distribution quirk. Let's start forcing people to think twice before they create yet another package that is essentially the same thing as dozens of other packages, but just different for the sake of being different. Pick one UI toolkit, such as Gtk+, and stick with it. Say no to the plethora of alternatives that amount to essentially the same thing, except made by someone else, with a different way of achieving the exact same result. Install all the dev files for your chosen toolkit.

Name your makefile "makefile" and put it in the same directory as all your C sources. Open up a terminal, cd to that directory, and just type "make". Don't worry about "installing" it. You know where it is.

After all is said and done, this is as easy as it gets (under Linux).

[cybrid]

And I thought that a shell utility was maid for anyone could write a gui interface for it instead of being tied up to just one

[j_g]

Yeah, but this isn't just one "shell" (ie, text-based, command-line issued) program. You've got autoscan, which generates a text-based configure.scan file. Then, you've got automake, which takes a text-based makefile.am file and generates one or more text-based makefile.in files. Then, you've got autoconf, which takes a text-based makefile.in, and text-based configure.am file, and generates a very convoluted, text-based configure file. Then, the configure file generates a whole boatload of other text-based files.

You're an intelligent being capable of easily reading text and applying deductive reasoning to it. A computer can crunch numbers fast, but it's not so good at deductive reasoning and making complex choices by analyzing text. If you can barely make sense of the above tools and their output, what luck does an IDE have?

The problem isn't necessarily that an IDE is riding atop of text-based tools. Microsoft's Visual Studio does that too. The problem is that an IDE is riding atop of a whole mess of text-based tools that churn out way too much information, in a format that is way too free-flowing and poorly structured, all for the sake of trying to be all things to all people from the ancient past (in computer terms), to now, to the day that the last Linux guy ever forks another package and therefore causes another inconsistency to accomodate.

[Jimmy_r]

I am glad there are other people than me thinking about this...

In a perfect universe, I could start SuperIDE(oops the name is in use, nevermind), choose my programming language and write my code.
When finished, I would click the "Create Distributable packages" button and have it output a deb, a rpm, a tarball, an ebuild etc, which would be installable on all systems.
Even better, output one .package package, which would be installable everywhere...

In fact, to package a simple python program(see signature) properly I had to spend two days.

I even tried downloading an other packaged python project(alacarte) to see how it was packaged, but it was using some pycentral thing which I found no documentation about whatsoever...

And I was unsuccessful until I found this video: http://showmedo.com/videos/video?nam...romSeriesID=37
A 23 minute long video... That speaks for itself.

I just find it ridiculous that it is harder to learn how to compile and package software than it is to learn a new programming language.
I never needed a video to learn python, not even to learn C++...

[lnostdal]

While I agree with a lot of the problems you describe j_g, I'd like to mention that tools like for instance scons and cmake where actually added for a very good reason as there are some very real and fundamental flaws and problems with make.

But yeah, the differences between distros and the problem of distributing software because of this is something we're stuck with for the time being.

I take the easy "brute force" way out though; I do not bother with .deb, .rpm, automake, autoconf etc. at all. I make a simple `install-ubuntu.sh' file (and a `uninstall-ubuntu.sh' file for later) that calls apt-get and gets all the required dependencies before installing the software itself either in /usr/local/, so it does not "disturb" other stuff - or in the users home directory. Basically because I do not have time to bother with the "ideal solution" that try to be compatible with everything at once. This works well for me, at least for the time being.

[cybrid]

Hmm, maybe a good solution for everyone could be using XML for make files and a common api. What do you think of this?

[lnostdal]

maybe .. but it will be hard to describe anything else than declarative stuff then .. i mean; how would you do things like `if-then-else', in general describing imperative actions - using XML? .. it would end up quite hairy i think

while a common api(#1) might have been ideal if it was what everyone agreed is the "best api" for their task -- it's not going to happen for the same reason some people prefer python, some people prefer ruby and some people prefer lisp .. or some prefer emacs while others prefer vim .. or even some prefer windows while others prefer linux .. etc.etc.


#1: i'm not sure what API we're talking about; do you mean a GUI API here? ..assuming you mean a GUI-API:

is this a real problem? isn't GTK+ or QT common already because they are _available_ (the installer can just call apt-get libgtk2.0-0 or emerge libgtk2.0 (on gentoo .. etc.) -- well, or create a .deb or an .ebuild-script ofc.) on _all_ distros - even ones "dedicated" for only kde or only gnome?

i actually view this as a good thing as i'm certain most developers here wouldn't like to be forced into using one they didn't like or one that would not be as suitable as the other for the task at hand

on win32 you have the same problem - but with no package-managers available at all so i'm not sure that situation is in any way better btw. .. or you can just use the one that is "common"; low-level win32 gui programming is not very nice .. (as a note here xlib is "common" in the same sense on linux here)

..a problem i do see is how GTK+/Gnome and QT/KDE (and others) use different libraries to communicate between applications etc. .. this should be handled in a library beneath both GTK+ and QT (and others) and i think this is what DBUS and the libraries around it is trying to solve atm. .. it would be nice to see something that worked with both local and remote IPC though

[yaaarrrgg]

maybe .. but it will be hard to describe anything else than declarative stuff then .. i mean; how would you do things like `if-then-else', in general describing imperative actions - using XML? .. it would end up quite hairy i think

In the Java world, Apache Ant uses XML. Also, there's an additional modules for conditional compilaton (like AntContrib), and other things. I believe C compilation is supported to some degree as well, but have never tested this.

[j_g]

scons and cmake were added (because) there are some very real and fundamental flaws and problems with make.

Oh absolutely. I don't argue with that. I just wonder why the authors choose essentially the same paradigm that the GNU tools already use (ie, the programmer has to hand-create a text-based data file written with a particular "syntax language", using a text editor that is not specifically integrated with that dev tool). If that's all they were going to do, then they should have instead taken the GNU sources and "fixed" the flaws in them. It would have ultimately amounted to the same thing in practical, useable terms.

But we have Gnome and QT. We've had them for years. They are supposed to be mature. These are the technologies that are making Linux a competitor to Windows. So why are developers _not_ leveraging them in making dev tools? (And I'm not counting IDEs that ride on top of these too convoluted, poorly structured, free-flowing text-based approaches, because things like Anjuta show the perils of this approach). Why didn't the SCons folks say?:

"OK, let's start with the premise that this tool is going to be UI based. Let's pick a mature UI toolkit that does what we need. Now let's make a UI that lets the user enter all the data we need via controls. And let's store the data in a binary format since the user will _never_ manually edit it. A binary format is _much_ easier for software to parse and analyze than a convoluted text format, especially one with all manner of 'conditional expressions'. Let's not be stupid about it. Let's pick an extensible binary format such as IFF which has been successfully used for years and years, or something that at least supports the concept of 'tagged data' such as XML. What? Some guy over there doesn't have support for this mature UI, and still wants to use a text editor to hand-create a text-based 'make file' that has all manner of conditional expressions in its syntax so that he can accomodate systems that also don't support the mature tech we're using? So let him use the GNU tools. This tool is not intended for him. Enough is enough. This tool is supposed to represent progress/change, which is what Linux needs."

how would you do things like `if-then-else', in general describing imperative actions

You mean like;

#ifdef WIN32

#elif AIX

#else

#endif

Very easy, if you're using a file format that supports "tagged data". For example, in XML, if the user selects the check box labeled "IBM AIX" (inside a frame labeled "Target OS"), then the following data tag will appear in the file (within another, appropriate tagged-data "header").

<TARGET>AIX</TARGET>

If he selects "Windows" instead (and maybe selects the radio button labeled "32-bit" rather than "64-bit"), then the above tag will not be found in the file. Instead, the file will contain:

<TARGET>WIN32</TARGET>

If he is allowed to select both AIX and 32-bit Windows, and he does, then both tags will appear in the data file.

If he selects the "None of the above" box, then neither of the above tags appears in the file.

And of course, when the dev tool reloads the data file, it should note what is selected and use this info to create output files (like an executable, installer, or sources) geared for the selected systems. If it's too difficult to accomodate a particular system because it's too oddball and/or limited, then don't support it. Let people who make convoluted, poorly structured/integrated, "I'm all things to all people" dev tools, such as GNU tools, support those folks. And let the oddball folks use that stuff. They _deserve_ it. Don't inflict it upon the rest of us.

Those of us who were weaned on operating systems that were not based upon Unix (typically text-based data files) or MS-DOS (typically non-extensible, non-tagged data files) were weaned on tagged-data, extensible binary formats, so this stuff is all old hat. Linux programmers need to come up to speed on this stuff. I mean, it's good that we're starting to see newer versions of software (such as gconf 2, and glade) finally grasp the concept of tagged data, but what took Linux programmers so long, and why are the dev tool programmers _still_ not "getting it"?

if it was what everyone agreed is the "best api" for their task...

Please believe me that I'm not attacking you personally. I know what point you're making here. It's just that, while I support the concept, and your affirmation, of "choice", I believe that the "implementation of choice" on Linux leaves much to be desired. A real choice isn't:

I can get a hamburger at McDonald's, or I can get a hamburger at Burger King, or I can get a hamburger at Wendy's.

Real choice is:

I can get a hamburger at McDonald's, or I can get a specialty gourmet exotic dish at the restaurant next door, etc.

If Linux is so big on choices, why are so many Linux developers (particularly the ones making dev tools) fixated upon making an offering that attempts to "be all things to all people"? I mean, if you're making something that ends up being all things to all people, why does anyone need anything else?? And why are so many Linux developers all using the same paradigm for their software? What's the point of choices if they're all essentially the same hamburger?

I initially chose Anjuta because I was running a Gnome-based distribution (Ubuntu) and planned to develop GTK+ based apps. Why didn't I pick KDevelop, or Eclipse, or something else? Well, I thought:

"Anjuta purports to be especially geared for Gnome development. I'm assuming that it is written using Gnome libraries, and will be easier for me to develop Gnome apps with it because its IDE will have lots of Gnome-specific stuff to help guide me, and it will produce output files that will be geared to install/distribute my stuff for Gnome distributions like mine. It will integrate better with my Gnome desktop. Etc.".

What I discovered is that Anjuta is more of a "Gnome facade". It really rides on top of these "I'm trying all be all things to all people" GNU dev tools, and relies upon them to do too much work. It isn't geared for Gnome distributions. It's yet another tool that ultimately tries to be all things to all people, and ultimately fails at being particularly good for anyone in particular. It's yet another one of those typical Linux apps which screams "I'm pretty much the same thing as those other 300 'choices', all of which are pretty much the same thing as me, but we have minor variations in the way we implement the same paradigm, so my ultimate purpose is to just make you deal with yet more inconsistencies, dependencies, variations on a theme, and other stuff that doesn't offer you any real added value. I just offer you more of the same headaches.". Welcome to the Linux concept of "choice".

We need more people addressing specific target audiences, and offering truly different paradigms, and a whole lot less people forking stuff and just making their own versions of everybody else's 'choices' just so they can say "My 'choice' does all the same things as these other 'choices' plus one or two more things. But what I've neglected to tell you is that it basically is another rehash of the same approach, and yet, because I've heaped a few more things on top of it, it's going to be at least as convoluted, unintuitive, inefficient, and difficult to learn/use as all the other 'choices'.".

Ok, whomever swiped my soapbox, you bring that thing back here right now!

I am glad there are other people than me thinking about this.

I believe there are lots of people thinking about this. Often, they are afraid to voice their opinions because folks who were weaned on Unix, and have never really spent any time using any other paradigm (especially GUI-driven stuff), insist that things would be "better" for everyone if we all just attempted to acclimate to convoluted, unintuitive, text-based "I'm trying to be all things to all people" offerings. And I also believe a lot of those former people are looking at Linux and rejecting it because of the nature of its 'choices'. I can't tell you how many times I, as a Windows user/developer, installed versions of Linux, tried them out a bit, and then rejected them. This is the first time, after several years of evaluation, that I finally have taken a serious plunge into Linux. I did so because, for the first time, I felt that things like the UI, installation of available software in "repositories", ease of administration, etc, met or surpassed at least my minimal standards of usability. Then, I went to develop Linux software, and man, after pulling my hair out to hunt down some tools that actually work for me, and being an experienced enough developer to figure out how to deal with some compiler/linker issues, I've found that it just barely... and I mean, just barely... is usable. This is a perilous state of affairs if Linux intends to attract any Windows developers. Linux dev tool makers need to start thinking differently because what they're doing is not working well versus the Windows competition.