Version: gideon, CVS of 09/06 (using KDE KDE 3.1.2) Installed from: Debian testing/unstable Packages The debug part does not set the environment variables specified in the run options.
Strange, This was working fine three weeks ago!!!
Which kind of project manangment? autoprj, customprj, antprj, trollprj? AFAIK it is working fine in CVS at least for autoprj and customprj.
Sorry for that, I'm afraid I didn't searched enough. In fact, my problem is not an environment variable, it is the LD_LIBRARY_PATH. I'm not sure that it is used by gdb. Maybe the part needs to use its value in a gdb command (I'm no gdb guru, I'm sorry that I can't help)
Works with trollproject here too :-) I have a project with a shared lib and an executable linked to it: I want to debug it without installing anything, just compile and debug. What I do is just use as target dir for the library subproject the directory <myprjdir>/lib and then set in Project Options->Run the variable LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<myprjdir>/lib. Ok, it is not portable but works pretty nice :D
*** Bug has been marked as fixed ***.
I does *not* work for me. But as I searched more (sorry :() I found the problem more complex that I thought [With CVS of 02/07 and autoproject] Here is the symptom : I have a client / part application I symlink my libraries into <myhome>/.kde/lib LD_LIBRARY_PATH is set to <myhome>/.kde/lib in Project Options/Run Options I can execute it with Build/Execute Program Running the program directly with gdb works fine But if I try to debug, the part is found (which is OK) _but_ the loader can't find the libraries the part depends on. Have you any ideas as what I can do to find the problem ?
Here's the text of a mail I sent to kdevelop-devel mailing list on 25 June 2003 This explains the problem and a way to fix it. I have not fixed this yet :( Maybe someone will beat me to it :) Hi, I want to be able to get the environment variables for any c/c++ type project ie autoproject, trollproject etc. The following code (in gdbcontroller.cpp:1276) works for troll projects but doesn't work for autoprojects :( QString project_mananger_key = (DomUtil::readEntry(dom,"general/projectmanagement")).lower(); DomUtil::PairList envvars = DomUtil::readPairListEntry(dom, "/" + project_mananger_key + "/run/envvars", "envvar", "name", "value"); because project_mananger_key = kdevkdeautoproject, but it needs to be kdevautoproject. The troll project sets it to kdevtrollproject which just happens to be correct for that type of project. I think these run options don't need to be in a sub option of the project type. This would mean we access the values like so DomUtil::PairList envvars = DomUtil::readPairListEntry(dom, "/run/envvars", "envvar", "name", "value"); (I hope I'm understanding the way this Dom stuff is supposed to be working) If no-one objects, I'll change this to remove run as a sub option and in the process fix this bug. jbb
jbb, me and roberto are working on a possible fix. do not commit yet
Basicaly to fix this bug we need to find all kdevkdeautoproject and replace it with kdevautoproject. This seams to be the more correct way to deal with it. The problem is: I can not find any occurencies of "kdevkdeautoproject" :(
With my last comment in mind, this is an autoproject bug and has nothing to do with the debugger.
It comes from file parts/appwizard/kapp/app.kdevelop <projectmanagement>KDevKDEAutoProject</projectmanagement> Somewhere it's lowercased to give kdevkdeautoproject. And yes, a quick fix is to change this to <projectmanagement>KDevAutoProject</projectmanagement> However, what if someone adds a new template, that is a slight variation of the kapp template, just changing the template source code in minor ways, and calling it <projectmanagement>KDevAutoProject2</projectmanagement> (as we like to do :-). This would cause the setting of environment variable to fail for these projects. I still think all the run variables are independant of the project type, hence my previous proposal. If nothing else it makes the code much easier to understand.
Well IMHO the bug is that we have only one automake mananger and it seams that it has several names: <projectmanagement>KDevKDEAutoProject</projectmanagement> <projectmanagement>KDevAutoProject</projectmanagement> If the "kde" in KDevKDEAutoProject is used some where, then it sould change to: <projectmanagement>KDevAutoProject</projectmanagement> <KDevAutoProject> <KDE>true</KDE> </KDevAutoProject> If on the other hand the "kde" in KDevKDEAutoProject is not used then we sould replace it with KDevAutoProject. I currently don't have the time to check it and change it, but it's on my list. jbb is fix sounds good to me, but it involves changing lots of code. This fix is simpler.
jbb wrote: > However, what if someone adds a new template, that is a slight variation of the > kapp template, just changing the template source code in minor ways, and > calling it > <projectmanagement>KDevAutoProject2</projectmanagement> > (as we like to do :-). This would cause the setting of environment variable to > fail for these projects. The projectmanagement tag if for the project manangers and not for the template name!!! and If somebody would write a template with <projectmanagement>KDevAutoProject2</projectmanagement> then that person would also have to write a KDevAutoProject2 project manager part. Currently we have: AdaProjectPart AntProjectPart AutoProjectPart CustomProjectPart PascalProjectPart ScriptProjectPart TrollProjectPart So I really don't have a clue why the kdevkdeautoproject can work. It shouldn't. It's like an "unexplained natural phenomena" or something because AFAIK it would need to have a corresponding part/kdeautoproject to be able to work :)
Created attachment 1956 [details] a patch to the debugger The only reason that I did'nt move the run options outside of the project is that I want to be able to execute the "active target" if no main program is in the run "Main Program" Option
Created attachment 1965 [details] An extended run options fixes and expands the run functionality, but has looots of code duplication
Created attachment 1966 [details] An extended run options Sorry the previous patch was a mess! Here is a new one. John please review. Fixes and expands the run functionality, but has looots of code duplication
Subject: kdevelop CVS commit by aclu: Allow the user to select a custom directory to run the executable from. BR#60055 I already commited the GUI files to do it in a previous commit, but the current commit makes the corresponding project managment changes to actually make it work! What it really does: - Adds the folowing functions to KDevProject class: virtual DomUtil::PairList runEnvironmentVars(); virtual QString runDirectory(); virtual QString runArguments(); This way the debugger can easily access these values when debuging Besides that this opens the doors for greater flexibility i.e. debug active target and stuff like that. More to come soon! PS: also fixes BR#59720 CCMAIL: 60055-done@bugs.kde.org CCMAIL: 59720-done@bugs.kde.org M +19 -6 lib/interfaces/kdevproject.h 1.19 M +77 -2 parts/adaproject/adaproject_part.cpp 1.5 M +5 -2 parts/adaproject/adaproject_part.h 1.2 M +83 -1 parts/antproject/antprojectpart.cpp 1.11 M +5 -1 parts/antproject/antprojectpart.h 1.4 M +89 -34 parts/autoproject/autoprojectpart.cpp 1.98 M +4 -1 parts/autoproject/autoprojectpart.h 1.35 M +72 -2 parts/customproject/customprojectpart.cpp 1.53 M +4 -1 parts/customproject/customprojectpart.h 1.15 M +15 -1 parts/debugger/dbgcontroller.h 1.17 M +15 -5 parts/debugger/debuggerpart.cpp 1.79 M +6 -12 parts/debugger/gdbcontroller.cpp 1.49 M +2 -1 parts/debugger/gdbcontroller.h 1.19 M +74 -1 parts/pascalproject/pascalproject_part.cpp 1.9 M +4 -1 parts/pascalproject/pascalproject_part.h 1.2 M +72 -2 parts/scriptproject/scriptprojectpart.cpp 1.30 M +6 -3 parts/scriptproject/scriptprojectpart.h 1.10 M +72 -2 parts/trollproject/trollprojectpart.cpp 1.58 M +4 -1 parts/trollproject/trollprojectpart.h 1.22
This bug reappeared in KDevelop 3.2.2. I'm using a QMake project with one environment variable set in Run Options. When launching the app, the variable is set, but not when debugging the app. best, Jeroen
Strange..... who broke it ??? Can you trace it back in the annotations ?
It seams the bug is back.
In KDevelop 3.3.2 this bug is also still present.
Can't reproduce with Automake on current 3.4 SVN.
Same with Custom Makefiles project. No problem.
Ok, can't reproduce with QMake project either. Assuming fixed.