I really would like to see the 1400 test errors we get on MinGW reduced
before the next release.
As far as I can tell most of this boil down to GSMime issues (The NSURL
test seems to be a result of that as well). Even the most simple test in
GSMime build.m produces the wrong result. Only the last header and the
content get reported as the rawMimeData.
As debuggin on MinGW is a rather annoying task, especially when done in
a virtual machine, I looked through the code at GSMime to find any MinGW
specific issue and there aren't any. So I furteher tracked this down
until I got to the method -headerNamed: which always returned the first
element what ever the given name was. There we use this horrible
optimisation of implementation caching. Fine if done correctly, but here
we use the type IMP to cache a method that returns a BOOL not an object.
I will fix this later on and give the MinGW testing another try. in
GSMime.m I could see about five of this misuses of IMP and we will have
to check the rest of base as well.
Still no idea why this breaks on MinGW but seems to work on most other
systems.
Fred
On 16.08.2011 10:47, Fred Kiefer wrote:
On 15.08.2011 13:03, Fred Kiefer wrote:
On my Windows XP running in a VMware with GNUstep for MinGW things don't
look that well. I have 47 failed tests and one failed build. It looks
like everything related to character encodings, NSJSONSerialization and
NSURL is failing. I will look into this in more detail and report back.
These tests were done with an old installation of MinGW. I switched to
the new one yesterday and now the results look even worse :-(
I have about 1400 failed tests, luckily most of these come from one
single NSURL test. Attached you will find the the test logs.
There are a few worrying tests here. For example we get a warning about
-isClass when compiling the file NSObject/test01.m and both these tests
there fail. (The first test in this file actually tests +isClass)
I don't quite understand the test in NSObject/initialize.m, but MinGW
doesn't have SIGALRM, we will need to have a compile time check there.
Plenty of the GSMime tests fail, but I am not sure whether this is
related to Richard's recent changes.
We also have problems with NSDecimalNumber and NSNumberFormatter. The
later may be due to ICU bugs on MinGW.
There is also a more general issue on MinGW. When compiling the source
we get plenty of warnings. These are caused by passing a char* pointer
into Windows functions that expect wide characters. We introduced the
type GSNativeChar to work around the issue that
-fileSystemRepresentation should return a wide character pointer on
Windows, but we need to use this type for all the temporary variables as
well. Not sure, whether we should address this before the next release
though.
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
