12.12.2010

If that's not hot

I found a great way to eliminate all makefiles for rather simple C++ project structures: Simply compile it via command line using 'g++ *.cpp'. This takes all files in the current folder and compiles them. That's damn useful! I actually store all my current project files in one folder, so this elimites the usually necessary typing of filenames. Of course, it's always a full compilation. So it might be not so good for big projects. Well, atleast you can also use in makefiles as well, having more compile time than specifying it by hand of course. And you can't just make a simple backup files without giving it another extension. But well, I like simple project management and most of the time I'm, getting tired of adding new files to your project by hand. I structure everything in folders, so there doesn't seem to be any need for real project management. One problem is still persistent: having rather deep folder structures. Well, you could probably also solve this by executing 'g++ *.cpp */*.cpp' and so on. But if you really need a dozen of folders to get a clean file overview, it might be better to make a makefile instead for overall better performance...

But the wildcard solution it atm good enough for me. It's that I sometimes want a fully blown IDE but rethink it a few days later. Call it a short wave of virtual-virtual desire. The more I get typical IDE features, the sooner I don't want them anymore. It's just not as cool, you know. Plus, your CPU does stay cool without all this ressource-comsuming auto completition shit from seldomly effective alghorithms used to implement that kind of development feature. What I'd like is a mix of both features, but staying low in requirements and loose enough to take folder structures as input. So you only have a single project file where you can specify the folders it should take for compilation and it generates a makefile for all depencies on it's own. Additionally, it could also preparse the files and offer a auto completition when using gedit. So you'll have a sidepane for makefile generation and symbol browsing. To work automagically for EVERY file you've opened (and thus switching projects as you switch files), it would scan the folder of the opened file, taking the existing project file(s) there loading all preparsed symbol data. So in the end it's basically as system offering the possibility to refresh the current makefile based on the folders you gave it and a subsystem to switch auto completition depending on the currently opened file. Of course, if you want to share the same file over multiple projects, you'd need a) need to copy them here and there (ineffective) or add a possibility to choose completition based on the currently selected project. Well, maybe it's easier to make a selection of projects in a selected folder, so can have multiple projects/build variants simultaneously. And depending on the selected project, the auto completition and build would execute the associated makefile. I kind of like this idea. It's not an idea, but it's also no pure commandline compilation and no annoying makefile syntax. It's a tool to speed up the basic process you'd normally do by hand... I like it. It would give me the freedom to keep several componentcheck projects inside the same folder but still having a bigger project around sharing same files at once. That's exactly what I need for my ITK library. I have a lot of components to check, I don't want to have a single-click-to-compile-everything system cause some components maybe faulty or so. And if I don't want to develop anymore but write something else instead (like a concept for example), I can simply make a new file and the project manager simply doesn't do any auto completition since the file isn't a part of any projects.

Let's if I can actually code a gedit plugin, I'm not sure. It probably means some GTK and API work... Something I can't do at the moment. And a single command line tool? Oh come on - where'S the use if it doesn't integrate into my editor. This way I could also compile it all by hand.

No comments: