>> My guess is that it fails in HBIDE because >> HBIDE _does change current dir_, which is >> a dangerous thing to do in general and will >> mess up any process which rely on current dir >> (IOW any process which uses no or relative paths), >> such as running a relative filename got from >> hbmk2. So IMO HBIDE should never try to alter >> current dir, or if it does, it should adjust >> all relative filenames accordingly. >> > > Your assumption is wrong. > > For build process it stays in the project location folder. > For execution, because it has to be done in detatched > manner, it does not follow the project path and loose > its track which can either be set by proper -o switch > or providing the execuatble path in "Start in" field of > Project Properties.
This is totally wrong solution. Why do you want to force absolute paths for users? Because it's simplest to program? IOW you force each HBIDE user to actively work to workaround the lack of attention to details in HBIDE code. To me this is unacceptable. If my assumption is wrong, then HBIDE should try to emulate the logic to find the non-absolute output name at it's original position. I can help you that hbmk2 does no magic related to output filename, and it actually launches it using the exact same name as displayed on screen (which is detected by HBIDE). Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
