(*** This bug was imported into bugs.kde.org ***) Package: kdevelop Version: 2.0 (using KDE 2.2.0 ) Severity: wishlist Installed from: SuSE RPMs Compiler: Not Specified OS: Not Specified OS/Compiler notes: Not Specified Hi currently additional directories where to search for includes and libraries have to be specified in the "additional flags" field for the compiler/linker. It would be great to have a dedicated directory list for this. Another idea for specifying additional link libraries is to let the user select from a list where all the reachable libraries are displayed. Another idea is to expand "~" to the proper directory. Kind Regards Sven Heithecker (Submitted via bugs.kde.org)
Please let's have a sensible split between what can be set globally for the whole project, and what can be reconfigured for individual build configurations. The existing feature does not seem to work as it "should". If I am building a cross-development project, the names of the libraries I am using will (probably) be the same across platforms. However, the locations of include files AND LIBRARIES will be different depending on the platform being built for. Currently, KDEv lets you specify build-specific CPP/C/C++ options (Proj Options/Compiler Options/Flags and Warnings), and linker FLAGS (LDFLAGS), but you are only allowed to specify additional library LOCATIONS in the Linker Options/Additional Libraries field - which is a global Project setting for all build configurations. (I have tried setting -L options in the config-specific Compiler Options/Linker flags field without success.) Even in the non-cross-platform case this doesn't make sense - say I want to use a debug version of the library, in a different location, same lib name, for a debug build. Can't do it without re-editing the Linker Options every time. Regards Mike Whittaker [Currently using KDev 2.1.5 on RH 9.0, x86]
Please let's have a sensible split between what can be set globally for the whole project, and what can be reconfigured for individual build configurations. The existing feature does not seem to work as it "should". If I am building a cross-development project, the names of the libraries I am using will (probably) be the same across platforms. However, the locations of include files AND LIBRARIES will be different depending on the platform being built for. Currently, KDEv lets you specify build-specific CPP/C/C++ options (Proj Options/Compiler Options/Flags and Warnings), and linker FLAGS (LDFLAGS), but you are only allowed to specify additional library LOCATIONS in the Linker Options/Additional Libraries field - which is a global Project setting for all build configurations. (I have tried setting -L options in the config-specific Compiler Options/Linker flags field without success.) Even in the non-cross-platform case this doesn't make sense - say I want to use a debug version of the library, in a different location, same lib name, for a debug build. Can't do it without re-editing the Linker Options every time. And yes, "~" doesn't always expand properly Regards Mike Whittaker [Currently using KDev 2.1.5 on RH 9.0, x86]
Sorry, KDevelop 2.x is no longer under development. The KDevelop3 lets you specify additional library LOCATIONS per build configuration. You are strongly advised to update to the latest CVS version of KDevelop3, code name gideon, take a look at: http://www.kdevelop.org/index.html?filename=branches_compiling.html for all the details you need. If you find a problem or need help please send a mail to the mailing list: http://www.kdevelop.org/index.html?filename=mailinglist.html or drop us a line at the channel #kdevelop on the server irc.kde.org using ksirc, for example. Please use the CVS version and compile it yourself because that way you can easily patch it if a bug is found. KDevelop3 can open Develop2 projects. To do so, goto the "Project -> Open Project ... " and select "KDevelop 2 Project Files" in the "Filter:". You can have and run KDevelop3 and KDevelop2 at the same time on the same computer without any problems. So migrating is a breeze. :)
This wish now resumes to: - An idea for specifying additional link libraries is to let the user select from a list where all the reachable libraries are displayed. - Another idea is to expand "~" to the proper directory.
Hello, 2.x is no longer in development, but I cannot download anything but an Alpha version of 3.0 - there doesn't appear to be a 'release' yet. Or does Alpha really mean Beta ... or RC ? >> * Alpha releases are very early drops of the software intended for dedicated testers. Alpha releases may not be stable, may introduce file formats that will change or become unsupported in the future, and should not be installed on machines relied on for your daily work. They usually include known bugs. Alpha releases are best installed on a second machine or even a dedicated testing system. * Beta releases are considered reasonably stable drops of the software, but may share some of the instabilities of an alpha release. Beta releases should be installed only by users who are willing to endure some broken functionality, to provide feedback on our newsgroups, and who are willing (if necessary) to manually delete or move files or registry keys. * RC is the designation for release candidates. An RC1 release is intended to be suitable for "burning and pressing" onto a CD-ROM. Only critical bugs will be fixed. RC builds should be suitable for installation by almost any user. <<
Adding libraries is something that needs to be done through the buildsystem and all buildsystems that are supported in kdevelop allow to choose libraries via file dialog by now.