On Mon, 18 Jan 2010, Szak�ts Viktor wrote:
> I understand this, but since in 95% of cases we're
> doing well with simple #if guards, I'm not sure all
> of these exceptions are valid one. F.e. the ones
> I mentioned are solely used in GTWVT and GTWVG, pretty
> easy to guard them, although f.e. in my mingw tests,
> they worked well, so they seem to be supported.
They are not supported by MinGWCE 0.55 I'm using in my
Linux box though they exists in header files so code can
be cleanly compiled. Fails when harbour.dll is created.
Which version of MinGWCE do you use?
0.55 is the last official release. I've downloaded 0.59.1
And checked that it also does not contain Arc(), FrameRect(),
FloodFill(), MulDiv() and few others functions. But it has
Beep() and file lock functions so I plan to enable then ASAP
when I installed it and verify it with real compilation and
link test. It will be nice if someone can also make runtime
tests at least in some WinCE emulator.
BTW I'm really happy that I have to update only single file
instead of grepping the whole code and reverting hacks for
functions missing in older MinGWCE versions and increasing
number of #ifdef... conditions in core code. As long as we
will not have new official release of MinGWCE I think it's
good to keep support also for 0.55.
I hope that someone can verify also MSVC and POCC WinCE builds.
> Maybe it's not true for all old versions of all
> compilers, but in this case it's still better to
> fine-tune it with version guards.
If these functions are missing only in WinCE RTL then guarding
them in source code is IMO very bad and dirty solution which is
also hard to update.
It's much cleaner to add them in single file which is easy to
update when new compiler is released and supports some additional
functions. Otherwise we will left like in contrib where a lot of
code which probably can be compiled for WinCE is simple disabled
by !defined( HB_OS_WIN_CE ).
> > BTW I also think that if some code can be compiled for WinCE and does
> > not create some fixed dependencies which break existing functionality
> > then we should compile it. I.e. with some minor fixes win_prn[123].c
> > can be compiled for WinCE by MinGWCE. In current version of WinCE RTL
> > low level functions do not exists but maybe they will be supported in
> > the future or even by some 3-rd party extensions i.e. there is 3-rd
> > party windows console for WinCE so it should be possible to use GTWIN
> > with it so we can provide GTWIN for WinCE builds but of course it cannot
> > be included in harbour.dll. Please also remember that new MinGW compilers
> > support direct linking with .dll libraries and do not need any
> > intermediate import libraries (BTW it's even suggested to eliminate
> > import libraries from new projects because direct linking with .DLLs
> > is faster and consumes less memory) so it's enough that user has valid
> > .dlls to link his application and use new functionality.
>
> So what should be the final conclusion here?
> I'd personally simply remove those few GDI
> WinCE stubs, as they seem to be supported and
> wait for feedback where they exactly fail.
> (f.e. I can't test msvcarm).
They are not supported by MinGWCE 0.55 and MinGWCE
0.59.1
> As for the rest, I don't know, we may leave
> them, but it would seem much cleaner and uniform
> to add guards to them, where they are used.
I do not find anything clean in hacking core code
adding workarounds for missing functionality in some
chose compiler versions. IMO it's much cleaner to
keep all such hack in one place only and for sure
it's much easier to update only single file and instead
of introducing and reverting hacks in many different
files.
> I somehow feel it very uncomfortable to publish
> system function form our own libs, be it .dlls
> or static libs.
Me two but it's minor problem in comparison to adding:
#if !defined( HB_OS_WIN_CE ) || \
( defined( __MINGWCE__ ) && __MINGWCE__ >= ... ) ||
( defined( _MSC_VER ) && _MSC_VER >= ... ) ||
( defined( __POCC__ ) && __POCC__ >= ... ) ||
[...]
in many different places and then updating each of them
when new compiler is released. I simply do not have time
for it and I do not believe that will be updated by others.
One file I can update from time to time very easy. Additionally
I have documented in one place all missing functions so I can
immediately locate what may be wrong when user reports some
strange behavior.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
