Hi Przemek,
> > I know, but this isn't a Linux tool :) For Linux it isn't hardcoded, > > just the default is set to gcc. You can set it just like for hbmk > > script HB_COMPILER=gpp|owatcom. The new command > > For hbmk script I do not have to set anything because it's build > dynamically in install phase from user settings. If this is the preferred method for Linux users, we can easily do it by extending compiler detection from hb_compiler() and tweaking the currently static default based on that. How does this seem for you? > I think that here we have yet another mistake. Probably someone send > you some very old hbcc description. In RPMs and in doc/howtobld.txt > we have: > ,--------------------------------------------------------------------- > | "hbcc" is a wrapper to the C compiler only. It sets all flags > | and paths necessary to compile .c files which include Harbour header > | files. The result of its work is an object file. > `--------------------------------------------------------------------- 'hbmk -hbcc' will work as you say, given that you don't supply any .prgs on the command line. If this isn't good enough we can further tweak it to better emulate hbcc. > > I'll add -info switch which will control currend OutStd() > > messages, these will be kept 'on' until we test hbmk, > > later turned off. -q will disable informational messages > > + logo. > > But -q is also harbour compiler switch so I cannot control them > separately. Since harbour was called with -q0 anyway, this didn't seem like a big problem, anyhow I've changed it to -quiet to clear this up, and allow us to play with -q0. > > > // t.prg > > > ? "Hello World!!!" > > > hbmk t && ./t > > Is this also true on Windows? all compilers? I'd love to > > see it working like this on all platforms/compilers, and in > > this case we can safely remove -n. > > It is and always was in the whole [x]Harbour history I remember. Good then. I remember otherwise from the early times, and I might have missed something along the way, which is good. Since we currently have _all_ Harbour tests and samples using MAIN() entry points, we will have to find a solution to let these compile easily. .hbp files could help. If you have a suggestion, I'd appreciate it. [ maybe entry point detection? ] > > What about the -n1 situation? Is it possible to add those > > discussed changes? > > I think that we should finish one thing 1-st. I have not idea what will > be the final result of hbmk2.prg usage in different platform and for > cross compilation so I'd prefer to leave it as is. Ok. > > Which it does, but it was so obvious I didn't include > > in my answer. > > It's very hard to guess what is obvious for you. Since without -I you don't have a chance to compile any Harbour .prgs using .ch files, so it should be there, just like -I for C compiler, I thought this is obvious. You could have peeked into the source, which I thought you did ;) > -n and -q wasn't for me. > Just like this: > TODO: Add support for wildcarded input source. > Only if only one source file is specified. > is obvious technical nonsense for *nix users ;-) What is *nix? :) But seriously, thanks for reminding me, anyway non-*nix users might find this useful still. The TODO isn't clear but I meant to generate multiple .exes in such case. This feature would need quite some work with not terribly big use except compiling test dirs, so I'll see, it's not top priority. > Here we should also add something to change path base path > logic detection because link can be in different directories > then hmmk2 binaries. We should add support for passing some Your help here will be needed here. > build time switches, f.e. we have to decode HB_PCRE_REGEX > and HB_EXT_ZLIB build time macros to use native platform pcre > and zlib binaries. I've implemented some bits of this. Tell me if something is missing still. > Probably hbmk2.prg auto detection logic should be changed. > 1. default compile time mode - used by 99% of users which > strictly keep the same platform and C compiler as the > one used to create hbmk2 binaries. It's very seldom > situation when user will want to use harbour.exe/hbmk2.exe > compiled by different C compiler then the one used to compile Speaking about non-*nix, to make everyone happy, we can add a switch to influence autodetection, and allow to turn on chameleon mode where it would behave like what it was specifically built for. Anyhow in prinpical here I very strongly disagree, for non-*nix systems. I think this is more than unexpected behaviour in this world. I can understand why you need it on *nix, but here this is completely alien, I've never ever seen such, maybe with the exception of some *nix rooted tools, and they've made life very difficult when working with them, their behaviour very difficult to predict, just to name two from the life of Harbour: make.exe, bison.exe for many years. And this is still present with some ported tools. We shouldn't replicate this with Harbour tools, and we don't do this for harbour.exe either, very very luckily. > harbour libraries. Such situation happens only during cross > compilation. In fact also using different C compiler for the > same platform should be treated as some type of cross compilation > because binary libraries in most of cases cannot be moved between > compilers and even if final executable files can be created then > there is very big chance that it will be corrupted due to difference > in CRTLs. I also do not believe that many users will try to collect manually final Harbour installation from two different binary builds > and hbmk2.exe will come from the 1-st one and libraries from the second > one. It's unusual situation and any auto detection which will prefer it > will only create more troubles by sporadic wrong compiler detection > due to differences in environment settings. While I agree with what you say, it's still fundamentally against all non-*nix tools to do such thing. In this case we should at least change the name of the .exe to make it clear that while all of them look the same, feel the same, they indeed completely different tools internally. Such thing would nix the possibility to put hbmk.exe in the path and let do it's job neutrally for different Harbour dirs explicitly specified with HB_INSTALL_PREFIX envvars. Not to mention the case of simply copying hbmk.exe around to another build and try to use it there, to much surprise. So to sum it up I'd propose a switch to select free autodetection like now, and fixed compiler detection based on build. In this case I'll remove current hack to prioritize based on build. For *nix system the build based method will be the default for non-*nix build the former. So much for simplicity, but what can we do. In this mode hbmk2.prg should fully respect compile time macros > like HB_PCRE_REGEX, HB_EXT_ZLIB, HAVE_GPM_H, etc. It may also > detect default GT driver and not overload it if it's not strictly > necessary though it's minor feature. Same issue as above. I wouldn't abuse flag inheritance on non-*nix too much, it's dangerous and not overly useful. Except for prg flags. Other than that we can detect these settings and apply for platforms where this is expected and useful (*nix mostly). The only current exception is the GT driver, if it was overridden at build-time. For the GT issue, we can add a hb_version() readout about the default state, but overall I'm not a big fan of GT override at build time. After all it can be changed anytime dynamically. It's like wanting to set the default RDD at build time. It just creates problems. IMO. > 2. support for cross compilation where we can chose other then default > C compiler. > In such case it will be also necessary to set different library path > (in few seldom situations maybe also include path), (un)define some > harbour compiler macros using -D/-undef: options, set C compiler prefix > and/or some C compiler options. It will be hard to create full > auto detection for all possible combinations so user will have to > control each setting manually. To make it easier I suggest to intorduce > config file which will have sctions like in .ini file. Each section > will contain full information necessary to pass succesfully cross > compilation, f.e.: > [xmingw] > COMPILER=mingw > CCPREFIX=/usr/local/bin/i386-mingw32- > PRGFLAGS=-D__PLATFORM__WINDOWS -undef:__PLATFORM__UNIX > -undef:__PLATFORM__LINUX > ... > such file is easy to edit and it's not necessary to hard code all > information in different make file. It's also easy to copy and update > on different computer for different configuration. It's single file so > setting new environment is much easier. I hate when I have to update > xxx files and I forgot about some of them. After setting user can > easy specify 'xmingw' in some hbmk2 parameter and work with new > environment. > Yes, we need to solve cross compilation. But first I'd like to clear the non-cross issues simply because I cannot keep that many open threads in my head :) For the cross compile thing, we'd need to find some more generic solution than the current one. Even that GNU-make settings are a bit unclean. As for the config file, I'm not sure yet, it really starts to push hbmk2 on the bloated/complicated side. We should make it as light as possible and as easy to use as possible, even for cross compilation. So, I'd prefer to hide cross platform details (tools, logic) inside hbmk2, if there is any chance for that. We could initiate a cross build by special arch | compiler pairs: linux - mingwce, win - msvc64, we already have: win - mingwce / poccce / pocc64. etc. So I'd try to add these to the current structure. Maybe what you say could be a way to override internal rules in hbmk2. This can be interesting although very advanced, and it would also need to create smooth easy to reconfigure rules inside hbmk2. To make rules _fully_ configurable, it would need a considerable amount of work to do it properly. So in essence the current hard-wired .prg logic should be separated to an external rule file + a rule processor. > I do not see any reason why we have to hard code such limitation > and forbid users to use hbmk also in make scripts. For me it's the > main job of such tool and I do not expect that we will create make > system comparable to GNU make in the nearest future. We're circling around this topic, I'm not sure why, probably we're misunderstanding each other. I've already made several modifications to allow for this type of usage, plus this was my intention right from the point I realized the need, and I haven't by any means stated that I'd like to "frobid it". This is nonsense, I have no idea where did you get this. So after spending quite a time on it, now we have some modes which focus on this kind of usage, and there is default mode which focuses on normal (hbmk.bat-like) usage, and there are switches to bend behaviour if defaults aren't adequate. Photocopying 100% hbmk script behaviour isn't an option, as we have to deal with some more aspect and more platforms, not to mention the possibilities are also wider, so we should concentrate on what's important. If you have some specific suggestions what to tweak to clear up remaining ones, or why does it feel like it "forbids" anything, please tell, but speaking in general I cannot do much more than now. I'd also invite you to try the tool out, I'm not sure if had already done so :) Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
