<picky>The extension is not called SCA_SDO, it's just sdo.</picky>
<extra_picky>It's not a PECL extension it's a PHP extension. PECL is a
repository and a packaging mechanism.</extra_picky>
Hi Caroline. Yes. I intended to describe the process for building the
extension on windows. This was in response to a request for this
information on the mailing list. I agree that not many people will
want to do this but if we at least record is somewhere then that may
help those who do want to do it, e.g. me when I forget a stage.
You are right I should have added "on Windows" to the end of the
title. I only intended to document the complexities of the process on
windows. We could repeat the *nix build instructions but I think that
our documentation covers that already. I would go and fix it but the
page is locked by Matthew just at the moment. Maybe he's making it
readable ;-)
<snip>
<picky>The extension is not called SCA_SDO, it's just sdo.</picky>
</snip>
When I look at our package page [1] it's titled SCA_SDO although the
loaded package and the cvs repository directory where our code lives
still refer to it as sdo. So I think SCA_SDO is a valid name for it.
<snip>
<extra_picky>It's not a PECL extension it's a PHP extension. PECL is a
repository and a packaging mechanism.</extra_picky>
</snip>
It's a fair cop.
The first thing to do was to get a copy of the PHP source, and also
SDO_SCA source from the BUZZARD branch. It was easily done by issuing
commands as described in [3]. but the command I used for checking out
sdo_sca was slightly different from Simon's page above:
cvs -d :pserver:cvs...@cvs.php.net:/repository checkout -r BUZZARD /
pecl/sdo
Before starting building php source, be sure you have everything you
need. Here, you have to carefully read the section called "Putting it
all together" in [2], there is some extra steps if you don't have
cygwin.
Also, you have built all needed libraries. I wasn't sure which one or
ones I needed, but the compiler kept prompting error messages. So I
decide to go get all the three libraries Simon had mentioned above.
libxml2 and libcurl can be easily found, just follow the link
"download area" from referenced page [5]. Note that you may have to
copy libxml2.dll file, which can be in the libxml2-x.x.x.win32\bin
directory, into libxml2-x.x.x.win32\lib directory, otherwise during
the build process, you will get an error message "unresolved external
symbol _xmlDllMain referenced in ......" If you need libcurl, google it.
If you want to make life easier, download the packages with the same
prefix name as Simon used. For example I found out that if I was using
libxml2-2.6.26.threads.zip, libxml2.dll would be there, in the lib
directory as it was expected.
Then, everything is ready for building sdo_sca and php source. I built
them together in one go, because I thought it was not necessary to
build php first and then sdo_sca, also the complier didn't let me to
build php source without those libraries in default configuration.
Before configuring, you have to make sure all environment variables is
set correctly, (e.g. the system can find you complier (including bison
and flex) somewhere in your path list). I used similar configure line
as Simon. I suggest you to write you a batch file for setting the
environment and issuing the configure line, it'll save you time when
the next time you want to build it again.
Finally, time to try out some examples. If something goes wrong, or
even you are not sure what the expected results looks like, you can
always check out the error logs of your application server. For apache
server error.log can be found in the directory named "logs" under the
directory where you apache server is installed. The following problems
were encountered:
1. The examples must be run from correct directories. I thought i just
needed SCA examples, so I copied those SCA examples directly into
htdocs (my apache web-root directory). That didn't work, I checked
error log and realised that some examples can be only run from its
original directory (i.e. //localhost/examples/SCA/...)
2. Don't forget to add curl extension. If you are using downloaded php
binary, in the default php.ini, there is a line " ;
extension=php_curl.dll "which is commented out. All you have to do is
to delete the semi-colon in front. also the same for php_soap.dll,
you'll need that as well .
3. when I was trying the json-rpc example, and getting "No valid
@binding annotation could be found for 'WebService.php' ". I
remembered from somewhere I had been noticed about renaming
binding.ws to binding.soap. There were two occurrences in example
files where still using binding.ws ( line 60 in
MailApplicationService.php, and line 27 in WebService.php), after I
replaced them with binding.soap, it works.
That's it, by doing this, I think I've really learnt something. I also
looked SCA source code in a bit more details which gave me a better
understanding of how it works.
On 26 Apr, 14:15, Jack Zai <z...@hotmail.com> wrote:
> Yesterday, I finally got some SCA PHP examples running. Be honest, it
> really was more complicated than what I expected, and here is some
> experience.
>
> The first thing to do was to get a copy of the PHP source, and also
> SDO_SCA source from the BUZZARD branch. It was easily done by issuing
> commands as described in [3]. but the command I used for checking out
> sdo_sca was slightly different from Simon's page above:
> cvs -d :pserver:cvsr...@cvs.php.net:/repository checkout -r BUZZARD /
Well done Jack and thanks for the notes on how you found your way
thorugh this. I've added the fix for the incorrect cvs line to the new
build page up on google groups.
I'll fix the problem you found in the JSON-RPC sample.
We should probably include your advice up on the build pages. I think
you should be able to edit it so feel free to go in and add what you
think is appropriate.
Thanks
Simon
On Apr 23, 4:06 pm, simonsl...@googlemail.com wrote:
>
> <snip>
> <picky>The extension is not called SCA_SDO, it's just sdo.</picky>
> </snip>
> When I look at our package page [1] it's titled SCA_SDO although the
> loaded package and the cvs repository directory where our code lives
> still refer to it as sdo. So I think SCA_SDO is a valid name for it.
>
> [1]http://pecl.php.net/package/sca_sdo
Indeed the package is called SCA_SDO. But currently the extension is
sdo: either sdo.so or php_sdo.dll. My concern is that if we start
calling it the SCA_SDO extension, people will expect a SCA_SDO.so and
be confused. And it does also raise the questions of possible
migration of some SCA function to an extension in the future, and
whether SCA and SDO are a civil partnership or just good friends.
I think at the moment they are just friends :-) If, as some point, we
were to move sca extension code into the package them maybe we would
also have a sca.so/php_sca.dll. For example, the tuscany C++
integration code may be kmore generally useful in terms of supporting
some kind of default binding for SCA . In that case I guess we would
extend the package we have. But, in the future, I agree that SCA and
SDO would be separate.
Simon