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.

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.

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.

You could try the Borland C++ XBuilder, which is free as long as you register (also free).

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?

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.

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...

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.

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.

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.