On Tue, 18 Aug 2009, Szak�ts Viktor wrote: Hi,
> I don't see why they would need to edit any make files. I do not think that we ever directly address 10% of platforms where Harbour can be compiled. It's technically impossible so if we make build process too complicated to easy adopt it for some more exotic platforms we block the portability. For me much more important is easy portability then default Harbour behavior "out of the box". Just simply I hope that harbour will be default part of some systems and this is my main goal. > If there is a setting which needs to be controlled by users > we can provide it through envvars or VAR=VALUE make > parameters. The problem is that we do not know about such things as long as someone will not try to build Harbour on new system so we cannot add them now. Anyhow when the final version of new .mk files will be ready we can try to document which tools are required to build Harbour and then try to reduce dependencies list using some envvars. > The goal of course would be to require the least amount of > such settings. This is less important. For me the main goal is to be able to build Harbour in different environment without rewriting .mk files internals. I hope that the final version of new .mk files will help in it. > The only such remaining TODO is to autocheck /opt/mingw32ce/bin > for wce cross-builds. Of course unless I missed some bits which > may need to be fixed and cannot be covered by existing means, > which may happen. I do not understand above. People often have cross build binaries with some prefix in the PATH so any autodetection will locate them and enable cross building instead of native compilation. Or maybe I'm missing sth and you are talking about sth else. > But if everything fits, make_gnu_xmingwce.sh content can be > replaced by single call 'make $* HB_ARCHITECTURE=wce' (or > better be dropped), and make_gnu_xmingw.sh by 'make $* > HB_ARCHITECTURE=win'. Only if code in .mk files is working and does not have to be updated for new platform. > With some more work this syntax could be made working for > Windows hosts too, and to also autodetect win watcom > compiler (even on OS/2 or DOS), creating a more coherent > feel. Cross compilation is wider topic than just mingw[arm] > on *nix. > Maybe it's time to create a cross-build matrix to document > all supported cross build combinations. It's rather not possible. There are too many different combinations and we are supporting only few of them. OK let's wait with conclusions for the final version of new .mk files. Then I'll try to make some tests with some more exotic or much older systems and I'll check if sth has to be changed to make it working. > If we don't rely anymore heavily on manual HB_COMPILER and > HB_ARCHITECTURE settings, I also plan to rename the latter > to HB_PLATFORM. (or maybe to short versions HB_COMP and HB_PLAT). HB_ARCH best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
