Sign in to follow this  

Simple alternatives to KDevelop?

This topic is 4773 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I ask this question every so often and am usually disappointed by the results, so I don't expect much this time. ;) But I will try anyway. Basically, coming from a background of Visual C++, I can't find a decent equivalent for my Mandrake installation. Last time I looked, KDevelop seemed to be the best of a bad bunch but it's still a nightmare. If I want project management it expects me to go through all the ./configure foolishness that I don't want. I just want a simple makefile but it won't manage that for me, apparently. Also, when I ask it to make an SDL project, I expect it to be able to compile that project, not tell me that it can't find "sdl.h". I installed these things from the distro's RPMs so it's not like the lib is hidden in some obscure location. I eventually found out that it seems to have forgotten the sdl-config lines. Kdevelop's project configuration is only the thinnest of layers over gcc, requiring me to know the flag syntax for adding libraries and so on. I can't even find how to add a file to the project - the docs tell me there's an automake manager window, which I can't find. Finally, it's segfaulted on me twice in the last half hour. Surely it has to get better than this? I'm quite happy to drop automake, doxygen, cvs/svn support (which annoyingly clutters the Kdevelop context menu despite me explicitly asking for no such support for my current project), etc etc, just to get something that works with minimum effort and will manage a trivial makefile for me without creating almost 20 different files before I even start coding. I'm tempted to drop back down to text mode and use the Jam build tool for makefiles but I've no idea how well that'll work when it comes to using multiple libraries.

Share this post


Link to post
Share on other sites
MonoDevelop is, admittedly buggy, but very much on the right track, but it sounds like you don't want a C# IDE. For C#, last time I used it I found Anjuta sufficient, if not excellent. At least it seemed to manage your makefiles and libraries for you and give you some syntax highlighting, code collapsing and some other features. Code completion was curiously absent. Still, check it out: anjuta.sf.net.

Share this post


Link to post
Share on other sites
I know what you mean. I really want to be able to do all my programming under Linux but I can't get SDL to work properly with any of the IDEs. That and games are the only reasons I still use Windows. Dev-c++ is just soooo much quicker and easier than using KDevelop or Anjuta.

I must say though, both Linux IDEs do have lots of cool features but it's just that it's a real pain doing even a simple program.

Share this post


Link to post
Share on other sites
Sorry, I should have mentioned explicitly that I'm after C++ stuff. I tried MinGW Studio in the last 2 minutes while I was waiting for replies and it won't run on my system, saying it can't find a certain library.


I'd like to use Linux for my coding because I'm currently working on an OpenGL project, and running OpenGL apps on my Win98 partition eventually screws up the system with stack overflows.

(PS. Apologies if you don't see any paragraphs in these posts -I'm using Konqueror to post with and there seems to be some bug with it/Gamedev.net where the carriage returns are getting chewed up.)

Share this post


Link to post
Share on other sites
I got frustrated with Anjuta badly managing stuff, so I dropped to the basics: glade, gedit, and a terminal.

glade took care of creating all the makefile.am/configure madness, and I can just edit code with gedit, perhaps add a new sourcefile into the makefile.am and then just 'clear && make && ./prog' in the terminal.

There's only three negatives:
1. You have to know how to fiddle with a makefile.am SLIGHTLY, jsut enough to add new files to the project yourself. Pretty simple.
2. Compile errors mean you have to find the line yourself, you can't click on the line in the terminal and expect gedit to jump to that spot...
3. No "Intellisense" or whateer you call it. Fine with me, it always just annoyed me anyway.

Share this post


Link to post
Share on other sites
What version of KDevelope are you using (just curious). I am using 3.0 and it works great with SDL. I think they are up to 3.2 or 3.3 now. I did have 2.3 a while back and it was a total nightmare.

Share this post


Link to post
Share on other sites
I'm 'using' KDevelop 3.0 on Mandrake 10.0. SDL projects don't work out of the box until you add in the relevant sdl-config lines to the project settings. It just segfaulted on me a 3rd time just for browsing the project menu, perhaps because the project wasn't loaded yet. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
Sorry, I should have mentioned explicitly that I'm after C++ stuff. I tried MinGW Studio in the last 2 minutes while I was waiting for replies and it won't run on my system, saying it can't find a certain library.


I'd like to use Linux for my coding because I'm currently working on an OpenGL project, and running OpenGL apps on my Win98 partition eventually screws up the system with stack overflows.

(PS. Apologies if you don't see any paragraphs in these posts -I'm using Konqueror to post with and there seems to be some bug with it/Gamedev.net where the carriage returns are getting chewed up.)


I have a feeling this happens with older versions of Konqueror, since it was happening to me before, too, but since I've upgraded to 3.3 it seems to work fine.

*crosses fingers*

Interestingly, I can see your linebreaks when quoting you. Huh.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
I'm 'using' KDevelop 3.0 on Mandrake 10.0. SDL projects don't work out of the box until you add in the relevant sdl-config lines to the project settings. It just segfaulted on me a 3rd time just for browsing the project menu, perhaps because the project wasn't loaded yet. :)



I use, and really like KDevelop3 (along with VIM for quick-editing, btw) all the time without any problems.

I don't know if it's the same with Mandrake, but with Debian I found that if you don't install the ~7mb kdevelop plugins package ( which marked as optional ) kdevelop segfaults all the time even though, back then, I didn't specifically use any plugins.

Matthew.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
KDevelop is just horrible.

Anjuta looks very good, has lots of features, but it's totally unusable in practice. The way Anjuta forces you into this automake crap makes it unsuitable for any serious project. Which is a pitty, because the IDE in itself has a lot of potential. I have already tried to modify it into using standard makefiles, without reyling on these atrocious autotools. I failed, as a lot of the limitations are hardcoded into Anjuta itself and would require major source level modifications. For example the fact that it forces you into the stupid src/ tree structure. If they got rid of this obsolete automake and fixed directory structure, replacing them by a modern build system and a virtual directory tree, then Anjuta could become the IDE of choice under Linux. It would probably not even take a week to turn Anjuta from its current crippled form into a superb IDE, if you know your way through their source.

Unfortunately, their debugger link is extremely unstable in the current release.

Please, if anyone suceeded in hacking Anjuta away from the autotools of evil, let us know how you did it.

Share this post


Link to post
Share on other sites
autotools are hardly obsolete and are definately not evil.

They're just another thing to learn. Fortunately, it's not that difficult to figure out.



Has anybody who's been complaining about IDEs thought about popping up on anjuta's mailing lists and helping fix it?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by C-Junkie
autotools are hardly obsolete and are definately not evil.

They're just another thing to learn. Fortunately, it's not that difficult to figure out.

I strongly disagree. GNU make and the autotools are amongst the most bloated, flawed, and incoherent parts of the GNU environment right now. They're a total mess, prone to failure on the slightest misconfiguration, and being patched again and again, right into oblivion. It's about time to replace them by something much more streamlined.

It's also about design patterns. The autotools are useful if you want to write GNU-style code that compiles on billions of different Unix flavors. Tell you what, but I don't care if my game compiles on Solaris or Irix. I want it to compile on 32 or 64bit x86 Linux, period. I hate when my code directories get cluttered up with Anjutas autogen nonsense, and I hate it when I get forced into developing according to a certain GNU mandated paradigm. I'm no big friend of GNU and "GPL type" code, thank you. I would like to develop proprietary and closed source code that happens to work on Linux in addition to Windows. I don't want to redistribute the source, and I don't care if it fails to compile on any other setup than mine. But I'm currently lacking the tools to efficiently do that.

It's not about learning the autotools either, I've already more experience with them than what is good for my own sanity. I deeply _hate_ the whole GNU make process, and the autotools are just the topping on all of that.

MingW dev studio does it the right way: proprietary, yet highly efficient and functional make management (one single project file, fully virtual directory tree), and support for standard makefile export if needed. Unfortunately, mingw DS is a little too primitive to be useable on larger projects.

I would be willing to pay for a good Linux IDE. Is C++ BuilderX any good ? I haven't tried the personal version, as I'm reluctant to register with them.

Quote:
Original post by C-Junkie
Has anybody who's been complaining about IDEs thought about popping up on anjuta's mailing lists and helping fix it?

They don't see it as a bug or flaw, but as a feature. It's unlikely to go away.

Share this post


Link to post
Share on other sites
The last time I used KDevelop, there was a project type called 'custom project' that allows you to use your own makefiles. Don't know if that's what you want though...

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I strongly disagree. GNU make and the autotools are amongst the most bloated, flawed, and incoherent parts of the GNU environment right now. They're a total mess, prone to failure on the slightest misconfiguration, and being patched again and again, right into oblivion. It's about time to replace them by something much more streamlined.
I think they are slightly overengineered, but nothing that gets in the way. And the only "prone to failure" I've ever noticed is when something is wrong with the environment that would cause the build to fail ANYWAY. At least we catch it in the ./configure process.
Quote:
It's also about design patterns. The autotools are useful if you want to write GNU-style code that compiles on billions of different Unix flavors. Tell you what, but I don't care if my game compiles on Solaris or Irix. I want it to compile on 32 or 64bit x86 Linux, period.
I'm similiar. It doesn't get in the way.
Quote:
I hate when my code directories get cluttered up
In your source directories there is two extra files: makefile.am and makefile.in. Hardly cluttered up.
Quote:
with Anjutas autogen nonsense,
The root directory gets a few extra files, but hardly anything to be this upset about, so what are you talking about?
Quote:
and I hate it when I get forced into developing according to a certain GNU mandated paradigm. I'm no big friend of GNU and "GPL type" code, thank you.
How are you forced into doing this?
Quote:
I would like to develop proprietary and closed source code that happens to work on Linux in addition to Windows. I don't want to redistribute the source, and I don't care if it fails to compile on any other setup than mine. But I'm currently lacking the tools to efficiently do that.
Autotools doesn't care if it would fail on any other setup than yours. You're right though that autotools IS designed for source code will be released to the public, so some of it you just wouldn't need, but I still don't see how it gets in your way unless you're wasting way too much time sitting there staring at a few extra files in your project root complaining about them.
Quote:
Quote:
Original post by C-Junkie
Has anybody who's been complaining about IDEs thought about popping up on anjuta's mailing lists and helping fix it?

They don't see it as a bug or flaw, but as a feature. It's unlikely to go away.
Autotools? Heck no they're not going away, but other people have legitimate problems with anjuta.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by C-Junkie
I think they are slightly overengineered, but nothing that gets in the way.

It gets in my way, and that's what matters to me. If they're OK for you, well that's fine. It's not OK for me.

Quote:

In your source directories there is two extra files: makefile.am and makefile.in. Hardly cluttered up.

Yes, plus at least one hidden directory that is very non-hidden in Windows. And that in my source tree, that might be on a read-only partition, for example. Or on a fileserver where I don't have write permissions to. Oh right, my bad, I forgot that Anjuta _forces_ you to copy everything into a local /src directory... My point: An IDE has absolutely no business in writing stuff to my source tree.

Quote:

The root directory gets a few extra files, but hardly anything to be this upset about, so what are you talking about?

Uhm, I am talking about the _34_ extra files it creates in _every_ single project directory, not even counting the additional subdirectory with a name that makes it look like generated by an 1337-speak script kiddie virus (yes, I'm talking about this retarded autom4te.cache). My current game is mostly plugin driven, each plugin is a separate project (DLL/shared object), for modularity accross our team. All those directories are shared between Windows and Linux. Do the math. I can assure you, that I get very upset when I see the mess Anjuta + autotools leave in my project tree.

Quote:

How are you forced into doing this?

"/src"

'Nuff said. Have you ever managed to make Anjuta recognize source files outside of this subdirectory ? If so, I'd love to know how you did...

Quote:

Autotools? Heck no they're not going away, but other people have legitimate problems with anjuta.

Autotools are a very legitimate problem for me, and for many other people as well. That's why Linux lacks a decent IDE (and Anjuta is decent, apart from the autotool crap) for developers who enjoy a little more flexibility and less IDE interference in their projects.

Share this post


Link to post
Share on other sites
I don't want to add too much to this argument, as it's the wrong thread for it and I'm certainly no expert, but the autotools stuff looks like a large and horrendous hack being used as an alternative to either writing better tools, or better code, or both. I've had things fail to configure due to the lack of finding the package they want via pkg-config, even though the exact package in question was already installed via rpm. And on the other end of the scale you have all the ridiculous compiling of mini-programs just to test the availability of some feature which is only not supported in one version of one compiler on one architecture.

For example, I'm sure much of the architecture testing could be factored out into a separate tool. If the size of an 'int' on my machine was liable to change between compilation of 2 packages, I've got bigger things to worry about than whether that 2nd package compiles ok. ;)

In my case, all I want from an IDE is a basic makefile management tool so that when I click 'build', it knows what to do. I don't want to be prompted about having to run 101 little tools first, and I'd rather not have 10 or more extra files generated in my project's root to accommodate this. If the IDE wants to use GNU make or whatever, that's fine with me, but I don't want to be forced down the autotools route. My version of KDevelop at least doesn't seem to support this middle ground.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
I don't want to add too much to this argument, as it's the wrong thread for it and I'm certainly no expert, but the autotools stuff looks like a large and horrendous hack being used as an alternative to either writing better tools, or better code, or both. I've had things fail to configure due to the lack of finding the package they want via pkg-config, even though the exact package in question was already installed via rpm. And on the other end of the scale you have all the ridiculous compiling of mini-programs just to test the availability of some feature which is only not supported in one version of one compiler on one architecture.

For example, I'm sure much of the architecture testing could be factored out into a separate tool. If the size of an 'int' on my machine was liable to change between compilation of 2 packages, I've got bigger things to worry about than whether that 2nd package compiles ok. ;)

In my case, all I want from an IDE is a basic makefile management tool so that when I click 'build', it knows what to do. I don't want to be prompted about having to run 101 little tools first, and I'd rather not have 10 or more extra files generated in my project's root to accommodate this. If the IDE wants to use GNU make or whatever, that's fine with me, but I don't want to be forced down the autotools route. My version of KDevelop at least doesn't seem to support this middle ground.


Generate a QMake based project, all that thing needs is a .pro file per directory, qmake will then generate a Makefile based on the pro file. Instead of the automake manager on the right you will have the qmake manager, to manage your project.

Share this post


Link to post
Share on other sites
Quote:
Original post by C-Junkie
autotools are hardly obsolete and are definately not evil.

They're just another thing to learn. Fortunately, it's not that difficult to figure out.


I am with C-Junkie all the way there, I remember a while back when I looked at makefile.in files and configure scripts and I thought "These files are huge! I dont have time to learn to write them", but when I got to figure out the way autotools work I realized those files are automatically generated for you, the files you do have to write are quite simple, being configure.in the only one that may need some actual work.

truth is, autotools look for and use whatever you tell them to look for, I never use pkg-config, for example, and using libtool is optional as well.

Anyway, if anyone is interested there is a free autotools book which can be found here

Cheers!

Share this post


Link to post
Share on other sites
Anonymous,

Aside from being annoyed by *2* extra makefiles and *1* extra hidden-on-*nix directory per directory, and a pile of files in the root, your problems are not with autotools.

You're using autotools wrong, and it's not all your fault... Anjuta shares the blame.

autotools aren't meant for "projects" they're meant for "source trees". Anjuta fucks up the difference.

With a pile of plugins, no sane person would EVER put autotools in each and every plugin directory! It SHOULD look something like this:

/ (bunch of autotools stuff, yes)
/plugins/
/plugins/.../ (each plugin)
/myprog/ (your main source tree)

That's ONE autotools pile, and from then on its just makefiles. (and the .deps stuff)

Share this post


Link to post
Share on other sites
Quote:
Original post by George2
Generate a QMake based project, all that thing needs is a .pro file per directory, qmake will then generate a Makefile based on the pro file. Instead of the automake manager on the right you will have the qmake manager, to manage your project.


Thanks for the suggestion. I got the impression that qmake support was added literally a few days ago though? I can't check my version because I'm currently in Windows.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Kylotan, sorry for deriving this thread. I was just setting up Anjuta a few days ago, and trying to get rid of the autotools. This thread seemed the perfect opportunity to vent my frustration ;)

C-Junkie, I realize that Anjuta might make improper use of the autotools. Still, instead of "fixing" that behaviour, I still stand by my point that dropping the autotools altogether would be far more productive. In modern large teams and distributed software development, especially if Windows based, the notion of a single _physical_ source tree is largely deprecated. Many smaller independent source trees exist, in several different physical locations and under different access rights, that are virtually merged by an appropriate versioning and source control tool. I also realize that this behaviour can be simulated by the single source tree approach using a ton of symlinks. But first, Anjuta seems to seriously mess up if it encounters a symlink in the source tree (which is a bug). And second, I still think the combination of a symlinked tree and the autotools are a very poor solution to the problem.

I'll say it like this: they're overengineered for project handling, and they're too cumbersome and, well, primitive to do the entire source management on several projects. Much more powerful specialized tools exist for this purpose.

Anyway, here is a solution I might suggest. Does anyone here know the open Watcom compiler ? They have a very ugly (Windows) IDE, but they have an interesting concept of managing projects. A project regroups several targets, which again regroup several source modules. Everything is managed by a virtual file tree, so no forced hierarchy. A project is nothing more than a container for targets. Each target can be an executable, a library, a DLL, etc. A target inherits its configuration from the parent project, and can optionally specialize them. Source files are assigned to a target, and are compiled according to the target rules. Again, each source module can specialize the inherited properties. This model is very flexible, and doesn't impose any specific constraints. A project root gets 6 or 7 additional control files, a target root only 2. No further file is created anywhere in the source tree. This structure can be directly linked to a versioning system, such as CVS or Subversion.

Unfortunately, I never saw any IDE capable of such management under Linux. I wonder how long it would take to write a very simple IDE doing this, without all the eye candy. Just a basic Glade/Gtkmm/Qt GUI, with a third party editor component (Scintilla ?), and a flexible source/make management based on the project/target paradigm with property inheritance.

I'm not good at designing GUIs, but I bet someone with practice can lay down the basic framework pretty fast. I would be willing to write the source control and make file management backend. Any takers for such an experimental quick project ?

Share this post


Link to post
Share on other sites
Sign in to follow this