On Wed, 12 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
>> Dont' you afraid that we will end with winvista, winxp, >> win9x, win64 and other subdirectories? > No. WinCE is a different beast than the rest of > the flavors, as you must know the best. We also have > the special macro HB_WINCE internally for this reason. I do not agree. The differences between WinCE API and WinXP are smaller then between Win9x and WinXP. In our contrib code number of MS-Windows API functions which does not exists in Win9x is systematically growing up and here the problem is bigger the with WinCE and if we do not begin to check it then we lost Win9x and NT4 compatibility in the nearest future. > I'd change w32 to simply win as a next step, and win > should cover all desktop flavors. Maybe we could > separate win32 and win64, but so far I cannot see > any strong reason to do it and it'd be better trying > to avoid this anyway in the future. Now the biggest problem is only with Win9x for which we do not even have build time setting to force Win9x compatibility. > [ but we may also want to introduce a 3rd level of > builds: real architecture, like x86, x64, ia32, ia64, > this would make it easier to create such builds in > parallel. no very high priority. ] The achitucture problem is not real problem for us because you need separated biunaries for each architecutre so you have to rebuild harbour with different arch switches. The real problem is in used MS-Windows API functions. To support new feature we have to use new functions. But there is no easy way to now compile Harbour code excluding all stuff which does not exists in Win9x. In some cases where C compilers supports some dummy libraries with dummy functions for Win9x then it we are trying to detect use OS at runtime but such method does not work in all cases. >> Most of them are libraries which needs 3-rd party libs. >> If such libs will be in WinCE version then they should >> work. hbole should be fixed. > Well, gtwvg, hbwhat, hbtpathy f.e. don't have 3rd party > dependencies, yet they cannot be compiled and there don't > seem to be anyone taking care of this, but we certainly > cannot be sure they'll be ever fixed, if a fix is possible > at all. Just like we cannot be sure that they will work with Win9x in a year if we will keep current code updating and like you do not know what will happen with incoming Win7. It's possible that MS will force UNICODE builds for some new Windows version just like it did for WinCE. As I can see then WinCE is quite often updated and many of its modifications are later intorduced to desktop windows so keeping the code ready for WinCE is very good idea to make it ready for new desktop windows. Here I do not see any problems with current build process and I like that it forces some modifications. As I said for me the real problem is in keeping support for older Win32 versions which we probably lost if we do not make sth with it. > In any case it'd be good to have a facility to exclude > packages for WinCE, even if those are 3rd party dependent > ones IMO. But we do not need for this HB_ARCHOTC > [ I'd prefer to delete hbwhat from the repository BTW, > but that's another matter, it's a permanent candidate > for all sorts of problems and without developers actively > fixing/testing it. I haven't seen any user of it either, > so it pretty much looks like an unnecessary clog in > Harbour. ] Maybe you should ask Andrzej about it? Maybe it can help. AFAIK he was working extensively on this library in last years but I do not know the current status of his code and if he will want to public it. >>> [ Some of these could probably be fixed to compile >>> under WinCE, but some definitely not. ] >> Which one? > hbole, hbct, hbnf, hbsqlit3: yes > hbfbird, hbtpathy, hbodbc: maybe > gtwvg, hbwhat: I don't know. hbole, hbct, hbnf, hbsqlit3, hbodbc, hbtpathy, hbwhat, gtwvg are present in my MinGWCE builds. I do not have firebird installed so I cannot check if it can be compiled and I do not know if WinCE FB port exists. Even if not now then it can appear in the future. > HB_XBUILD is merely a signal that the current and > target platforms are different. Even Win64 build > creation on Win32 is a cross build. So for above purpose, > it's not suitable. HB_BUILD_WINCE I didn't know about > in GNU-make (and it seem to have a different meaning > in non-GNU make), but it doesn't seem like a std way > to control this problem to me. Exactly and this should be the rule of HB_BUILD_WINCE. Isn't it? It's the reason why we have separate envvar. Single HB_ARCHITECTURE is not enough. > Yes, but this is a different problem. We should > probably have two separate variables for current > and target platform. > Like: > HB_COMPILER=pocc > HB_ARCHITECTURE=wince > HB_ARCH_HOST=win32 [we may allow leaving this empty for non-cross builds] > HB_XBUILD => ( HB_ARCH_HOST != "" && HB_ARCH_HOST != HB_ARCHITECTURE ) Why not. But it's naming convention which we can clean. But still the real problem I can see is with used API. For WinCE builds we have HB_WINCE macro and it resolves the problem partially (we do not have support for WinCE version) but we have nothing to keep Win9x/NT4 working. and this is a problem for me. BTW seeing libraries you listed as problematic in your WinCE builds it looks that you will need HB_ARCHITECTURE=wince to exclude them from WinCE builds when they can be build for WinCE and at least some of them like CT I intentionally updated to work with WinCE and even tested some functionality. So the problem is strictly bound with CRTL for WinCE supported by given compiler not with HB_ARCHITECTURE. So if you really want then you should exclude them using HB_COMPILER variable not HB_ARCHITECTURE. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
