Version: (using KDE KDE 3.1) Installed from: SuSE RPMs Compiler: gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux There is no way to add cpps to a subdirectory and assign them directly to the bin. If you click right on the bin, do a create new, and change the path, Automaker ignors the change and put the cpp in the same path as the target. changing the Makefile.am manually do not help either. (A solution with lib files for every subdirectory will not work, if files from 2 subdirectorys include the headers of each other.)
This is a duplicate, but anyway, please specify your KDevelop version *** This bug has been marked as a duplicate of 54998 ***
ok didn't find it. kdevelop version 3.0.0b1 (Using KDE 3.1.1) Although I thing it's a bug not a wish, because kdevelop reacts not like it should, and some Projects are unable to be compiled on the regular way.
All KDevelop created projects work fine! It's more of a philosophical question than anything! - Our philosophy is One Makefile.am per directory that explains what to do with the files in that directory. - Your philosophy is to have a super duper Makefile.am (or more than one) that contins info about files is several directories. It needs a complete new Autotools manager to implent your philosohy. The current one works fine on most projects.
I see the problem. But it isn't so huge, that you have to completely rewrite the Autotools manager. The output can stay the same. You click in the top window on the directory, where the Makefile.am is. The only change is that the .cpp files assigned to a target can be of the form "subdirectory/name.cpp" instead of only "name.cpp", that's all, on the same way they are written to the Automake.am. You can still have a Makefile.am for every subdirectory, or leave it to the user if he want's to create one there. (You only need to be able to handle Makefile.am without a target, which you need to, anyway). And to find the Makefile.am to a name.cpp just write a small function and look at the list of Makefile.ams you already have for the top part of the Automakemanager. And the other tools like the class manager could handle it the same way: Show the things in the directory where the Makefile.am is. (Or skip the support for subdirectorys until there is more time) I hope your limiting release philosophy will change. It would be bad if you stop one step before really supporting gnu's autohell and make it useful and easy to use for everyone. (I have like others not the freedom to change the philosophy to the one of the IDE if it makes no sense for the design)