Hi Pritpal, >> Although for me hbide would be dropped as potential dev tool, >> if it will set compiler dependent variables :( First of all >> this makes it non-portable, difficult to maintain, or requires >> double logic, etcetc. >> > > _hbide would be dropped as potential dev tool_
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. > I could not follow you in this respect, can you explain > a little more. I cannot comprehend why it will be a > _non-portable tool_ ? 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. 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) - 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. - No hard-wired 'compiler profile' in hbide .prg code. - No preset 'compiler profile's in hbide SVN area (f.e. in .ini). 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. 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. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
