Hello Viktor
Viktor Szakáts wrote: > > Note: "for me". I have my own (actually quite simple) system > which sets tool environment, so any tool which tries to > replicate that, is just a nuisance and double effort for me, > since I have keep my system configured, plus keep hbide > configuration update so that it can also configure my system. > Believe me, I do not want to configure anything in HBIDE. This was the first commandant I wrote on my scratch book. I am trying to gather all information how and what HBIDE must supply to HBMK2 to compile projects under different compiler settings. I know nothing about make system at all. > Setting tool environment varies a lot from platform to platform. > > Huge part of hbmk2 deals with detecting these environments, and > it sometimes even does some configuration automatically to make > it simpler for users (bcc, watcom, f.e.). > > If you plan to add such feature to hbide, first you'll have to > precisely _emulate_ natural tool environment scenarios, so that > hbmk2 detects it as if it were configured by the tool installer > or the documented method for given tool (as listed in INSTALL > in examples section, although this is not complete, and never > will be). To achieve that, you'll have to know much detail about > the tool (f.e. version, locations, extensions), plus you'll have > to maintain these logics perfectly in sync with official setup > method for every tool and every new version of them as they are > released. > > For *nix systems, you'll have to deal with the whole thing a > little bit differently, since there most tools are always > available in PATH, and they require other means of configurations, > many time only detection. > > I'm not saying it's impossible, but it's a huge duplicate task, > very error prone, and makes hbmk2 fail easily if not done well. > As above. > Now, there is a way to avoid all above pitfalls and create hbide's > integrated configuration system in a generic way (although even > this has some dangers). I'll try to describe it in a few points: > > - Default state: No configuration is done by hbide, it uses what > it gets from environment and let hbmk2 do it's autodetection job. > (default/automatic/system mode) > Probably this is not what HBIDE is intended for. _no configuration on its part_ is a valid point, and I want to stick to it, but it is not valid that it accepts what user has set before executing it. I need a way to forward HBMK2 _what user want to configure_ plus _what he want to build_. This way HBIDE could be executed from any location. > - Support for 'compiler profile's: > User can add, delete, edit such named profiles, each > profile does nothing more than have a list of system commands, > which get executed before calling hbmk2. > This is exactly hbide.env is thought of, though I am not sure, yet, what contents it will hold finally. > - No hard-wired 'compiler profile' in hbide .prg code. > 100% correct. > - No preset 'compiler profile's in hbide SVN area (f.e. in .ini). > At present also it is not, nor it will be in the future. > Last two will assure that hbide is independent of actual > tool setting, so we don't have to keep it in sync with INSTALL > information, it cannot have anything non-portable, etc. > For sure, yes. > This is quite flexible and makes it possible for everyone to > customize profiles in an easy way, using existing methods or > documentation. Here the only challenge is executing shell > commands and then calling hbmk2. This needs to be done > differently on different platforms. Maybe the easiest is > to create a platform dependent .sh / .bat / .cmd file on the > fly and call that with hb_process*() API. > Agreed. Now the point is the design time considerations. 1. User will write commands in a profile ( say .env ) 2. This profile is essentially a replica what he otherwise will invoke via .bat/.sh/.cmd before executing HBMK2. 3. HBIDE or HBMK2 ( I would like HBMK2 ) process this profile before invoking the next step. 4. HBIDE simply forwards two files 1) .env and 2) .hbp to HBMK2. 5. HBMK2 runs silently in the background supplying compile/link output to HBIDE via some callback mechanism. Hopefully I am clear in opening up my mind. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/Create-Process-API---Brief-Overview-Requested-tp26696490p26704862.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
