Hi Przemek,
I'd like to ask opinions whether to introduce wince
as a distinct architecture in the GNU-make system.
This would replace current w32/mingwce, w32/msvcce,
w32/poccce builds with wince/mingw, wince/msvc,
wince/pocc.
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'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.
[ 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. ]
It would be useful because it would make it easier
to enable/disable contribs for this platform.
As of now, following contribs should have been
disabled for WinCE builds: hbwhat, hbole, hbmysql,
gtalleg, hbtpathy, hbfimage.
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.
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.
[ 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. ]
[ 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.
It would also allow to better sync non-GNU make
with GNU make by changing HB_BUILD_WINCE=yes to
HB_ARCHITECTURE=wince.
I do not think so. HB_BUILD_WINCE is used to mark that it's
a cross build not only to mark destination platform.
In GNU make HB_XBUILD is used for it. There are different
possible combination of cross building and of course also
native builds. So far we do not have native WINCE builds
but it may change in the future with increasing PocketPC
capabilities. It's technically possible even now with
MinGWCE but because I do not have such needs I haven't
added such possibilities so far.
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.
Now HB_XBUILD is used in some *nixes to create Win32/64/CE
binaries and in Win32/64 to create WinCE binaries. I plan
to add OpenWatcom cross build support too. Adding separate
support for HB_ARCHITECTURE=wince does not inform that it's
a cross build so second variable is still necessary.
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 )
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
