Removing the detaching and KDEV_SESSION
Andreas Pakulat
apaku at gmx.de
Mon Feb 1 18:39:52 UTC 2010
On 01.02.10 00:44:18, David Nolden wrote:
> Am Sonntag 31 Januar 2010 22:53:12 schrieb Andreas Pakulat:
> > Reasoning: Its impossible by now to let users easily fetch the debug
> > output of kdevelop and add it to a bugreport. They have to jump through
> > hoops to do that as normal stdout-redirection doesn't work anymore. This
> > just adds yet another problem on top of the existing ones. And at this
> > point I value these problems higher than separating the duchain data.
>
> Sorry I misunderstood the last message.
>
> This is stupid. We can simply add a "--nofork" option and be ready, it would
> solve both the debugging- and the debug-output problem. It doesn't matter
> whether you tell a user to do "kdevelop > ./output" or "kdevelop --nofork >
> ./output". That option will cost only 5 lines of code.
Sorry, but thats not making the executable any more usable.
> And I find it annoying that this subject is brought up again and again.
And it will be brought up again and again and again until the bug in the
language library is fixed and the library provides proper initialization
and de-initialization (is that a word?) methods.
Anyway, I'm tired of all this discussion right now. So how about the
following:
We inline the code needed in SessionController that calculates a
session-id and that can list all the sessions, its static already right
now and doesn't need any running code from the shell library. Then we
create a small wrapper app (Qt only probably) which uses the inline
functions to supply the --sessions output and generates a session id
from the -s switch. Then it runs the real app as subprocess, without
detaching it.
That way the duchain-stuff is only loaded once the envvar is set, we get
proper stdout/stderr forwarding and follow-fork-mode should work again
(though you'll have to disable it again once you broke into the main()
of the reall executable).
> Changing anything about that is out of discussion in medium-term, as the
> relation between effort and potential value is exorbitantly bad.
What exactly is medium-term for you? I'm asking with my maintainer head
on here. Because if its clear that this won't be fixed within the next
12-24 months, then this won't happen at all.
Andreas
--
You will meet an important person who will help you advance professionally.
More information about the KDevelop-devel
mailing list