Version: CVS (using KDE Devel) Installed from: Compiled sources OS: Linux Gideon should keep track of where you are in the build process and ask you if, for instance, you've done an automake but not a configure before it runs the program. Basically, the programmer needs to know which version of their code they are actually running -- and be reminded if they've missed a step. Sphere.
AFAIK this is the current situation.
I disagree.
Subject: Re: Automake, configure, make, install dependancies Amilcar do Carmo Lucas wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 >a.lucas@tu-bs.de changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Component|general |autoproject > Resolution| |INVALID > > > >------- Additional Comments From a.lucas@tu-bs.de 2003-06-19 16:01 ------- >AFAIK this is the current situation. > > > If that were correct then when I built a test project and tried to run it without installing it first I would have been told that I hadn't installed it. The fact that installing it is an absolutely rotten idea which makes Gideon effectively unusable is a separate bug. Sphere.
The necessity of installation is totally independent of KDevelop/Gideon. It's a requirement of the KDE build system (the admin/ directory) for any complex application -- i.e., one that uses .desktop files or installs icons. Most simple applications can get away with not installing. If you want that to change, the admin/ directory structure would have to change.
>If that were correct then when I built a test project and tried to run it > without installing it first I would have been told that I hadn't > installed it. I assume you are alluding to your kpart and my hint to install it. There is the necessity to install it (at least afaik), 'cause the klibloader searches for the kpartlib in the kde/lib directory (maybe there is a way to provide other paths to it). For convenience during development of a kpart, just symlink the kpartlib(no need for the "shell"-binary) to your project path, so you don't have to install every time. Maybe there are nicer solutions, that's just the way i do it. Yours, Jonas
Subject: Re: Automake, configure, make, install dependancies Thiago Macieira wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 > > > > >------- Additional Comments From thiagom@mail.com 2003-06-19 18:52 ------- >The necessity of installation is totally independent of KDevelop/Gideon. It's a >requirement of the KDE build system (the admin/ directory) for any complex >application -- i.e., one that uses .desktop files or installs icons. Most simple >applications can get away with not installing. > >If you want that to change, the admin/ directory structure would have to change. > > > In that case the admin/ directory structure has to change. If KDE can't handle a multi-user environment then it will never gain significant market share. I guess I can go back to using Windows 2000 and forget about Linux. It looks like it'll never make it in the real world. Sphere.
Subject: Re: Automake, configure, make, install dependancies Jonas Jacobi wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 > > > > >------- Additional Comments From j.jacobi@gmx.de 2003-06-19 19:26 ------- > > >>If that were correct then when I built a test project and tried to run it >>without installing it first I would have been told that I hadn't >>installed it. >> >> >I assume you are alluding to your kpart and my hint to install it. There is the necessity >to install it (at least afaik), 'cause the klibloader searches for the kpartlib in the kde/lib >directory (maybe there is a way to provide other paths to it). For convenience during >development of a kpart, just symlink the kpartlib(no need for the "shell"-binary) to your >project path, so you don't have to install every time. Maybe there are nicer solutions, >that's just the way i do it. >Yours, >Jonas > > > The problem with that is that it pollutes the file space. It's putting work-in-progress into the production area which is the problem. If you've got a couple of thousand employees and you have to keep their data backed up every night you're going to keep their files on a fileserver, not their PC. That means that everyone will be using the same copy of KDE, and the same directory tree. You're proposing that the programmers install their toys into the same KDE the secretaries are using. (And just how many programs named "test" are there in the world anyway?)
There is no need for make install to install globaly. All you have to do is create a test tree in ~, and export KDEDIRS=/global/kde/dir:/home/user/testdir, and then configure with --prefix=/home/user/testdir when developing
I just took a look at KLibLoader. Imho it should even be enough to add your needed path to the kde library paths, to have the stuff loaded. No need to install it. Yours, Jonas (btw. better don't start comparing of multi user capabilities of any windows with unices ;) ) Yours, Jonas
Subject: Re: Automake, configure, make, install dependancies Jonas Jacobi wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 > > > > >------- Additional Comments From j.jacobi@gmx.de 2003-06-19 19:26 ------- > > >>If that were correct then when I built a test project and tried to run it >>without installing it first I would have been told that I hadn't >>installed it. >> >> >I assume you are alluding to your kpart and my hint to install it. There is the necessity >to install it (at least afaik), 'cause the klibloader searches for the kpartlib in the kde/lib >directory (maybe there is a way to provide other paths to it). For convenience during >development of a kpart, just symlink the kpartlib(no need for the "shell"-binary) to your >project path, so you don't have to install every time. Maybe there are nicer solutions, >that's just the way i do it. >Yours, >Jonas > > > My reading of KLibLoader is that it only searches if the name is not an absolute filename. It also only appends ".la" if the library name doesn't have an extension. See kdelibs/kdecore/klibloader.cpp
Hi, Debugging into a KParts part is currently a problem. The workaround at the moment is to install the part. This is because the KPart library is dlopen'ed and kde searches only in the installed area for the part. I'm had a short conversation with Simon H. about this and we concluded that a small change may be required to KLibLoader but at that stage nothing more happened. It could well be that these days the amending the KDELIBS path could be a solution. For other dynamically loaded libraries libtool sets the environment correctly so the library does not need to be loaded.
Subject: Re: Automake, configure, make, install dependancies Maksim Orlovich wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 > > > > >------- Additional Comments From mo002j@mail.rochester.edu 2003-06-19 21:46 ------- >There is no need for make install to install globaly. All you have to do is >create a test tree in ~, and export KDEDIRS=/global/kde/dir:/home/user/testdir, >and then configure with --prefix=/home/user/testdir when developing > > > That makes much more sense to me. Thank you very much. Sphere.
Subject: Re: Automake, configure, make, install dependancies Jonas Jacobi wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 > > > > >------- Additional Comments From j.jacobi@gmx.de 2003-06-19 22:07 ------- >I just took a look at KLibLoader. Imho it should even be enough to add your needed >path to the kde library paths, to have the stuff loaded. No need to install it. >Yours, >Jonas >(btw. better don't start comparing of multi user capabilities of any windows with unices >;) ) >Yours, >Jonas > > > Windoze sucks when it comes to multi user capabilities, but VC++ is well behaved. Generally, the production filesystem is done on a unix server and is backed up nightly. The local Windoze filesystem is only used for the user's personal crap. (Unless, of course, the sys admin has been brainwashed into trying to use Windoze as a server farm...) Microsloth hasn't made it easy to run executables off a unix fileserver, but it can be set up.
Subject: Re: Automake, configure, make, install dependancies John Birch wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 > > > > >------- Additional Comments From jbb@kdevelop.org 2003-06-19 22:21 ------- >Hi, > >Debugging into a KParts part is currently a problem. The workaround at the >moment is to install the part. This is because the KPart library is dlopen'ed >and kde searches only in the installed area for the part. I'm had a short >conversation with Simon H. about this and we concluded that a small change may >be required to KLibLoader but at that stage nothing more happened. It could >well be that these days the amending the KDELIBS path could be a solution. > >For other dynamically loaded libraries libtool sets the environment correctly >so the library does not need to be loaded. > > > I didn't follow the path completely, but it looked to me that KInstance didn't provide a way to update _dirs. I also didn't hunt down kdevelop's handling of starting a program.
I sent this to the list, but then I remembered that you're not subscribed there: - Do a CVS update on Gideon. - Compile and install it. - Start it and create a new C++/ KDE application framework. - Read the readme file contained in the src directory. PS: When you reply to a bug, please please no _not_ quote the provious answer.
Subject: Re: Automake, configure, make, install dependancies Amilcar do Carmo Lucas wrote: >------- You are receiving this mail because: ------- >You reported the bug, or are watching the reporter. > >http://bugs.kde.org/show_bug.cgi?id=60067 > > > > >------- Additional Comments From a.lucas@tu-bs.de 2003-06-20 15:43 ------- >I sent this to the list, but then I remembered that you're not subscribed >there: > >- Do a CVS update on Gideon. >- Compile and install it. >- Start it and create a new C++/ KDE application framework. >- Read the readme file contained in the src directory. > >PS: When you reply to a bug, please please no _not_ quote the provious answer. > > > No. On The CVS update of Gideon issue: I'm busy trying to get a clean build of KDE, but I updated Gideon yesterday within my current test environment.
This has evolved into bugs: http://bugs.kde.org/show_bug.cgi?id=60092 and http://bugs.kde.org/show_bug.cgi?id=60191 *** This bug has been marked as a duplicate of 60191 ***