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.
"THE INFORMATION CONTAINED IN THIS REPORT IS CLASSIFIED; DO NOT GO TO FOX NEWS TO READ OR OBTAIN A COPY." , the pentagon
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
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)
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.
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 ?
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.
It's been there for years (at least since 2.1.5, I never used a version before 2.1.5). Note that qmake isn't perfect (multiple targets per directory isn't possible). The autotools are in my opinion better, but for quick and dirty stuff, qmake is more then good enough.
"THE INFORMATION CONTAINED IN THIS REPORT IS CLASSIFIED; DO NOT GO TO FOX NEWS TO READ OR OBTAIN A COPY." , the pentagon
Eclipse has a "CDT" that allows you to work in C/C++. According to my friend, "it sucks", but I haven't tried it, so I don't know. Eclipse was always great for Java, at any rate.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Anyone who hasn't tried Borland C++ BuilderX should really give it a shot.
Stability: Yes - not a single crash since I started using it (pretty much when it was released, think it's over 6 months ago). It's pretty much rock solid.
Speed: It's written in Java, but it still doesn't feel too sluggish.
Project configuration: A little different from most IDE's because it supports multiple compilers. You'll get used to it fast unless you're a total newbie, though. When linking with SDL, you just have to add -lSDL at one place and it just works.
Other notable features: Compare, visually, source files with older versions, even if you aren't using CVS. See a diff or look at the older versions.
And there is more that I can't remember right now. And this is the free download version. The only thing I kind of miss is "intellisense", but that's not a big deal for me. All in all - the best C++ IDE I ever used.
Quote:Original post by Anonymous Poster Anyone who hasn't tried Borland C++ BuilderX should really give it a shot.
Project configuration: A little different from most IDE's because it supports multiple compilers. You'll get used to it fast unless you're a total newbie, though. When linking with SDL, you just have to add -lSDL at one place and it just works.
And there is more that I can't remember right now. And this is the free download version. The only thing I kind of miss is "intellisense", but that's not a big deal for me. All in all - the best C++ IDE I ever used.
Hey, that sounds pretty good to me. Hopefully it will be what I'm looking for. What's intellisense though?
Quote:Original post by onthetweek Hey, that sounds pretty good to me. Hopefully it will be what I'm looking for. What's intellisense though?
Microsoft's code completion technology. At least I think it comes from Microsoft... usually other IDEs refer to it as code completion.
And I agree that C++ BuilderX is pretty nice for a free/dirt cheap (personal license) IDE. It feels a lot like an IDE you'd find in a Windows environment. My only complaint is that it DOES feel slightly sluggish, but it's definitely usable.
