[p4perl] Fwd: 8 hrs invested, 1 unresolved external symbol to go...
tony at smee.org
Wed Jul 25 06:24:58 PDT 2007
> Thanks for the follow-up. I was actually unaware that the Windows installer
> included a pre-built version of the binary. I was under the impression,
> from the documentation, that the binary had to be built locally. Now that I
> look at the page again it seems obvious, but it wasn't when I was reading
> through your instructions as there is no mention of using the bre-built
> binary in step #2.
Thanks for the feedback, I'll take a look at improving the page.
> Because of the plethora of version compatibility issues, I am uneasy at
> this point about using an API which may break during a future upgrade,
I'm not sure I agree with that - once it's installed, it works with all
versions of Perforce, so you only need to upgrade if you want to (and you can
test that before you do it).
> so I
> am electing to go with basic scripting (using system calls to p4 commands).
> This is less than ideal, as I am interested in listening to audit events,
> but seems a simpler and more stable approach, at least for now.
I'm sorry you had a hard time getting P4Perl to build, but I hope it hasn't
given you the wrong impression. P4Perl really is very stable and is widely
The issue we hit is discussed online at:
http://www.perlmonks.org/?node_id=621976 (amongst others), and it seems that
ActiveState are still using VS 6.0 to compile ActivePerl. Small wonder then
that modules compiled with VS 2005 aren't instantly compatible with it! I
think ActiveState have been lucky to get away with it for so long.
> If I had lots of time on my hands to get the API working and play around
> with it, I'd likely go that route. For now, I'm out of time and need to
> move on.
> Thanks for your help, though. P4Perl looks like a worthwhile project and I
> hope to get a chance to use it in the future.
Good luck Dan.
More information about the p4perl