>> 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.
And the answer is that you have to pass nothing more to it than it's necessary to define the project: input components and build switches. Nothing else is required. It's good if you add some means to add user-defined, extra hbmk2 invokation switches to allow to do everything with hbmk2 which can be done from regular command line. Notice that some switches can only be passed from command line directly (no .hb* file). >> 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. ideally nothing by default. At least I hope. Otherwise someone will have to update it and yet it will never be correct for all users. IMO the only place where we should mention anything user specific is in INSTALL file, and even in this file it's listed as "EXAMPLE", as it's impossible to tell these things for Windows system. Plus HBIDE is meant to support Linux and OS X also, where such example don't make any sense. >> - 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. Okay. >> 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 ) Maybe the cleanest solution, is to have a /profiles (name tentative) dir and inside this dir, you allow to have any number of .env files. Each .env file describes a C compiler profile. I'd suggest .ini file, as .env file is not very standard. In this file all you have is _plain script lines_: --- profiles/win_bcc.ini: set PATH=C:\bcc;%PATH% --- --- profiles/osx_clang.ini: export CCPREFIX=/Developer/usr/bin --- --- profiles/myprofile.ini: export HB_COMP=msvc --- > 2. This profile is essentially a replica what he otherwise > will invoke via .bat/.sh/.cmd before executing HBMK2. Yes. > 3. HBIDE or HBMK2 ( I would like HBMK2 ) process this > profile before invoking the next step. Yes, hbide, would create a script like this, when selecting win_bcc.ini: --- _temp_.bat set PATH=C:\bcc;%PATH% hbmk2 _temp_.hbp --- > 4. HBIDE simply forwards two files 1) .env and 2) .hbp > to HBMK2. Only .hbp. .env contains shell commands. > 5. HBMK2 runs silently in the background supplying > compile/link output to HBIDE via some callback mechanism. Yes. Input from other developers would be welcome. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
