hi,

On Sun, Jun 15, 2008 at 4:49 PM, Lester Caine <[EMAIL PROTECTED]> wrote:

> Well when I originally reported the problems that were creeping into
> php_interbase (linux and windows) I was told that *I* should fix them, and I
> keep being told I should get involved more.

Not easy to fix issues yourself but you are getting amazingly more
involved, this step is more than welcome!

> So
> http://lsces.co.uk/lsces/wiki/index.php?page=PHPDevelopment
> Had the M$ express stuff installed on my backup W2k machine it would
> probably not have been a problem, but I can't upgrade it since I need W2k on
> that machine to test against ;)
> I've been through the mill with M$ installs trashing the rest of my
> development environment in the past, so I am not going to risk it again.

In the meantime I tried to build the 2.1.x releases (1.x dsw/dsp do
not even want to be opened by vc6). It seems to work well but I met a
couple of issues due to the wrong architecture detection (it uses the
processor I use instead of actually using the current configartion,
you can compile for x86 on x64 or cross compile for x64 on x86).
Patches on their way, I suppose I can send them to firebird-developer?

By the way, do you know if the 2.1 lib is 100% BC compatible with the
1.x serie? If yes, I can then use them for the php windows binaries.

>> If you can write tests (you and the PHP firebird community) and run
>> them using our sources and binary releases, that will already do the
>> job. That's all we need to keep the extension alive.
>
> Testing is not a problem ESPECIALLY while we can run multiple versions of
> PHP on windows without the crap loaded into other applications which trash
> the working version and overload it with a version which may not work. I
> DON'T go with code that only has windows installers and would not test them
> ;)

It is rather simple to run multiple PHP version on windows. You only
have to uncompress the zip and run the tests. The fbclient will be
statically linked (bundled in the ext). You can call the run-tests.php
using the tests and script available in the src releases. I remember a
howto somewhere about running tests on windows without using nmake, I
will try to find it back.

> http://fbexport.sourceforge.net/ibtest.php.txt is our base set of tests and
> this shows a problem with NUMERIC(18,7) and above so we avoid that.
>
> The problem is fixing the problems we find?

Can you elaborate please? Or is there a bug # in bugs.php.net?

>>> I have an older windows server that is running as backup at present which
>>> I
>>> could safely load some of the M$ stuff on - if it will work on W2k .....
>>> But I'd prefer to stay inside my safety zone .....
>>
>> We can take care of the builds and port the firebird clients libraries
>> to Windows and/or MS tools. But we can do it only if we have a way to
>> test them :)
>
> THAT is an area where we do need to sort things out since the supplied
> client library is always ditched anyway and the current Firebird one used
> instead. From my point of view, splitting the fbird_ code from the ibase_
> code and building php_firebird against a firebird client would make sense,
> but as has already been said - is not actually necessary - yet.

Good point, especially as interbase is actually dead. That will simply
reflect the fact and we may add new 2.1 (or later) features. Feel free
to create the fbclient page in the wiki and to document what could be
done for 6.x (can't be renamed for 5.3).

> http://wiki.php.net/internals/windows/libs
> The pages for ibase and fbclient need creating, and the project link for
> interbase should be ibase but I could not work out what information should
> be on them. In the past I have also been told that *I* need to make
> pdo_firebird actually work which is yet another hassle that needs sorting
> even if the current Firebird users do not use it :(

I can provide the libs in the next days as well as use them in our
binaries snapshops (5.3, 6.x, maybe 5.2 if it works well and is 100%
BC).


Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to