Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:

>> That's interesting ... the SWIG port is borked. I port upgraded and
>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>
>> server:~ mklein$ port list installed | fgrep swig
>> swig @2.0.2 devel/swig
>> swig-php5 @2.0.1 devel/swig-php5
>
>
> Yep, that's what I'm seeing. I suppose I should open a bug @
> macports for SWIG.

If you do a "swig -swiglib" you can see where SWIG is looking for its
libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
box too after the port upgrade.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:

>> That's interesting ... the SWIG port is borked. I port upgraded and
>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>
>> server:~ mklein$ port list installed | fgrep swig
>> swig @2.0.2 devel/swig
>> swig-php5 @2.0.1 devel/swig-php5
>
>
> Yep, that's what I'm seeing. I suppose I should open a bug @
> macports for SWIG.

If you do a "swig -swiglib" you can see where SWIG is looking for its
libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
box too after the port upgrade.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ok, well I posted a comment to the swig port maintainer. Maybe he'll come up with a more robust way to deal with this issue in the future.

Alan

On Feb 26, 2011, at 2:28 PM, Mark Klein wrote:

>
> On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:
>
>>> That's interesting ... the SWIG port is borked. I port upgraded and
>>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>>
>>> server:~ mklein$ port list installed | fgrep swig
>>> swig @2.0.2 devel/swig
>>> swig-php5 @2.0.1 devel/swig-php5
>>
>>
>> Yep, that's what I'm seeing. I suppose I should open a bug @
>> macports for SWIG.
>
> If you do a "swig -swiglib" you can see where SWIG is looking for its
> libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
> box too after the port upgrade.
>
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:

>> That's interesting ... the SWIG port is borked. I port upgraded and
>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>
>> server:~ mklein$ port list installed | fgrep swig
>> swig @2.0.2 devel/swig
>> swig-php5 @2.0.1 devel/swig-php5
>
>
> Yep, that's what I'm seeing. I suppose I should open a bug @
> macports for SWIG.

If you do a "swig -swiglib" you can see where SWIG is looking for its
libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
box too after the port upgrade.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ok, well I posted a comment to the swig port maintainer. Maybe he'll come up with a more robust way to deal with this issue in the future.

Alan

On Feb 26, 2011, at 2:28 PM, Mark Klein wrote:

>
> On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:
>
>>> That's interesting ... the SWIG port is borked. I port upgraded and
>>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>>
>>> server:~ mklein$ port list installed | fgrep swig
>>> swig @2.0.2 devel/swig
>>> swig-php5 @2.0.1 devel/swig-php5
>>
>>
>> Yep, that's what I'm seeing. I suppose I should open a bug @
>> macports for SWIG.
>
> If you do a "swig -swiglib" you can see where SWIG is looking for its
> libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
> box too after the port upgrade.
>
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
wow! Homebrew has come a long way since last time I looked at it.
On Feb 26, 2011, at 3:25 AM, Ben Bleything wrote:

> On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
>> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.
>
> For what it's worth, I switched to Homebrew
> (http://github.com/mxcl/homebrew) about 18 months ago and I've been
> *very* happy.

wow! Homebrew has come a long way since last time I looked at it. I think I see some playing in my future.

Keith

--
Keith T. Garner - - 312-329-3294 - http://realtor.org/
National Association of REALTORS® - VP - Information Technology Services

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:

>> That's interesting ... the SWIG port is borked. I port upgraded and
>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>
>> server:~ mklein$ port list installed | fgrep swig
>> swig @2.0.2 devel/swig
>> swig-php5 @2.0.1 devel/swig-php5
>
>
> Yep, that's what I'm seeing. I suppose I should open a bug @
> macports for SWIG.

If you do a "swig -swiglib" you can see where SWIG is looking for its
libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
box too after the port upgrade.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ok, well I posted a comment to the swig port maintainer. Maybe he'll come up with a more robust way to deal with this issue in the future.

Alan

On Feb 26, 2011, at 2:28 PM, Mark Klein wrote:

>
> On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:
>
>>> That's interesting ... the SWIG port is borked. I port upgraded and
>>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>>
>>> server:~ mklein$ port list installed | fgrep swig
>>> swig @2.0.2 devel/swig
>>> swig-php5 @2.0.1 devel/swig-php5
>>
>>
>> Yep, that's what I'm seeing. I suppose I should open a bug @
>> macports for SWIG.
>
> If you do a "swig -swiglib" you can see where SWIG is looking for its
> libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
> box too after the port upgrade.
>
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
wow! Homebrew has come a long way since last time I looked at it.
On Feb 26, 2011, at 3:25 AM, Ben Bleything wrote:

> On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
>> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.
>
> For what it's worth, I switched to Homebrew
> (http://github.com/mxcl/homebrew) about 18 months ago and I've been
> *very* happy.

wow! Homebrew has come a long way since last time I looked at it. I think I see some playing in my future.

Keith

--
Keith T. Garner - - 312-329-3294 - http://realtor.org/
National Association of REALTORS® - VP - Information Technology Services

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 27, 2011, at 11:39 AM, Keith T. Garner wrote:

> wow! Homebrew has come a long way since last time I looked at it.

I suppose the real test comes when upgrading packages from one release
to the next ... that's where many package mangers either succeed well,
or fail miserably. To date with MacPorts, I've had only one failure
(that was quickly resolved) when doing "sudo port selfupdate && port
update outdated".

I think I'll let one of you "take the plunge" and tell me how things
work down the road ... I'll jump ship then. :-)
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:

>> That's interesting ... the SWIG port is borked. I port upgraded and
>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>
>> server:~ mklein$ port list installed | fgrep swig
>> swig @2.0.2 devel/swig
>> swig-php5 @2.0.1 devel/swig-php5
>
>
> Yep, that's what I'm seeing. I suppose I should open a bug @
> macports for SWIG.

If you do a "swig -swiglib" you can see where SWIG is looking for its
libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
box too after the port upgrade.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ok, well I posted a comment to the swig port maintainer. Maybe he'll come up with a more robust way to deal with this issue in the future.

Alan

On Feb 26, 2011, at 2:28 PM, Mark Klein wrote:

>
> On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:
>
>>> That's interesting ... the SWIG port is borked. I port upgraded and
>>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>>
>>> server:~ mklein$ port list installed | fgrep swig
>>> swig @2.0.2 devel/swig
>>> swig-php5 @2.0.1 devel/swig-php5
>>
>>
>> Yep, that's what I'm seeing. I suppose I should open a bug @
>> macports for SWIG.
>
> If you do a "swig -swiglib" you can see where SWIG is looking for its
> libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
> box too after the port upgrade.
>
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
wow! Homebrew has come a long way since last time I looked at it.
On Feb 26, 2011, at 3:25 AM, Ben Bleything wrote:

> On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
>> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.
>
> For what it's worth, I switched to Homebrew
> (http://github.com/mxcl/homebrew) about 18 months ago and I've been
> *very* happy.

wow! Homebrew has come a long way since last time I looked at it. I think I see some playing in my future.

Keith

--
Keith T. Garner - - 312-329-3294 - http://realtor.org/
National Association of REALTORS® - VP - Information Technology Services

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 27, 2011, at 11:39 AM, Keith T. Garner wrote:

> wow! Homebrew has come a long way since last time I looked at it.

I suppose the real test comes when upgrading packages from one release
to the next ... that's where many package mangers either succeed well,
or fail miserably. To date with MacPorts, I've had only one failure
(that was quickly resolved) when doing "sudo port selfupdate && port
update outdated".

I think I'll let one of you "take the plunge" and tell me how things
work down the road ... I'll jump ship then. :-)
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Sun, Feb 27, 2011 at 11:52 AM, Mark Klein <> wrote:
> I suppose the real test comes when upgrading packages from one release
> to the next ... that's where many package mangers either succeed well,
> or fail miserably. To date with MacPorts, I've had only one failure
> (that was quickly resolved) when doing "sudo port selfupdate && port
> update outdated".

That's what I like about homebrew. It installs everything into
/usr/local/Cellar// and then symlinks files
appropriately. Removing something means deleting the directory and
then removing dead symlinks from elsewhere in /usr/local. Upgrading
just installs to a new subdir and replaces the symlinks.

> I think I'll let one of you "take the plunge" and tell me how things
> work down the road ... I'll jump ship then. :-)

Like I said, switched over a year and a half ago and haven't looked
back. There's been some pain for sure, but overall it's much, much
better than macports.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:

>> That's interesting ... the SWIG port is borked. I port upgraded and
>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>
>> server:~ mklein$ port list installed | fgrep swig
>> swig @2.0.2 devel/swig
>> swig-php5 @2.0.1 devel/swig-php5
>
>
> Yep, that's what I'm seeing. I suppose I should open a bug @
> macports for SWIG.

If you do a "swig -swiglib" you can see where SWIG is looking for its
libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
box too after the port upgrade.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ok, well I posted a comment to the swig port maintainer. Maybe he'll come up with a more robust way to deal with this issue in the future.

Alan

On Feb 26, 2011, at 2:28 PM, Mark Klein wrote:

>
> On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:
>
>>> That's interesting ... the SWIG port is borked. I port upgraded and
>>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>>
>>> server:~ mklein$ port list installed | fgrep swig
>>> swig @2.0.2 devel/swig
>>> swig-php5 @2.0.1 devel/swig-php5
>>
>>
>> Yep, that's what I'm seeing. I suppose I should open a bug @
>> macports for SWIG.
>
> If you do a "swig -swiglib" you can see where SWIG is looking for its
> libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
> box too after the port upgrade.
>
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
wow! Homebrew has come a long way since last time I looked at it.
On Feb 26, 2011, at 3:25 AM, Ben Bleything wrote:

> On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
>> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.
>
> For what it's worth, I switched to Homebrew
> (http://github.com/mxcl/homebrew) about 18 months ago and I've been
> *very* happy.

wow! Homebrew has come a long way since last time I looked at it. I think I see some playing in my future.

Keith

--
Keith T. Garner - - 312-329-3294 - http://realtor.org/
National Association of REALTORS® - VP - Information Technology Services

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 27, 2011, at 11:39 AM, Keith T. Garner wrote:

> wow! Homebrew has come a long way since last time I looked at it.

I suppose the real test comes when upgrading packages from one release
to the next ... that's where many package mangers either succeed well,
or fail miserably. To date with MacPorts, I've had only one failure
(that was quickly resolved) when doing "sudo port selfupdate && port
update outdated".

I think I'll let one of you "take the plunge" and tell me how things
work down the road ... I'll jump ship then. :-)
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Sun, Feb 27, 2011 at 11:52 AM, Mark Klein <> wrote:
> I suppose the real test comes when upgrading packages from one release
> to the next ... that's where many package mangers either succeed well,
> or fail miserably. To date with MacPorts, I've had only one failure
> (that was quickly resolved) when doing "sudo port selfupdate && port
> update outdated".

That's what I like about homebrew. It installs everything into
/usr/local/Cellar// and then symlinks files
appropriately. Removing something means deleting the directory and
then removing dead symlinks from elsewhere in /usr/local. Upgrading
just installs to a new subdir and replaces the symlinks.

> I think I'll let one of you "take the plunge" and tell me how things
> work down the road ... I'll jump ship then. :-)

Like I said, switched over a year and a half ago and haven't looked
back. There's been some pain for sure, but overall it's much, much
better than macports.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> On Sun, Feb 27, 2011 at 11:52 AM, Mark Klein <> wrote:
>> I suppose the real test comes when upgrading packages from one release
>> to the next ... that's where many package mangers either succeed well,
>> or fail miserably. To date with MacPorts, I've had only one failure
>> (that was quickly resolved) when doing "sudo port selfupdate && port
>> update outdated".
>
> That's what I like about homebrew. It installs everything into
> /usr/local/Cellar// and then symlinks files
> appropriately. Removing something means deleting the directory and
> then removing dead symlinks from elsewhere in /usr/local. Upgrading
> just installs to a new subdir and replaces the symlinks.

I keep hearing from everyone that homebrew is better, but the arguments they make are not convincing.

I am not sure how Homebrew would've avoided this problem; it is essentially a bug in the swig package definition. The newer version of the swig package didn't remember to move the swig language defs to the right places.

To me the real test is how a system responds when you are upgrading things that have had lots of dependency changes; it's a problem that gets worse as you scale out the # of packages and my gut tells me that homebrew will eventually suffer this problem as well since I don't see any material improvements they've made to deal with the problem. However, I could just be missing something.

Hi-

Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.

I am trying to update our application to use the php bindings and am thus trying to build librets.

I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.

I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:

http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html

I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.

In any case, a few details I picked up from the thread were:

1) The librets in macports is "maintained" and should build.

The librets in macports is 1.4.0, which is very old at this point.

I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.

In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:

> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
> :3: Error: Unable to find 'php.swg'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'


2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:

> "port installed swig*"
>
> Results:
> The following ports are currently installed:
> swig @1.3.40_1 (active)

I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:

port installed swig

If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:

> port installed "swig*"
>
> Result:
> The following ports are currently installed:
> swig @2.0.2_0 (active)
> swig-php5 @2.0.1_0 (active)

It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.

In any case, I am still stuck at the missing "php.swg" file.

I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.

There seems to be some thought that this was related to swig:

>From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html

> > In any case, I got the following error:
> >
> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
> > -outdir build/swig/php5 ./project/swig/librets.i
> > :3: Error: Unable to find 'php.swg'
> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
>
> Is this the machine I originally set up or another one? Looks like
> something is funny in the SWIG installation. What is the result of
> "port installed swig*"?


My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.

I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Looking forward to your response.

Alan

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:

> I am now running into the same issue described in this very long
> thread from last May/June where Randy was trying to help out:
> It also required the underlying program to support globbing
> internally. This is a common mistake made in unix shells. Just
> wanted to point that out as it caused a lot of confusion on that
> thread.

>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am
> more than willing to help update the Portfile to the latest librets
> and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>>> In any case, I got the following error:
>>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 ./project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'

Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
"std" directory and "php" directories exist and are readable to you.

> My first question about this is -- which swig version is needed? I
> did not find it mentioned anywhere.

Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
significant changes over the releases. I last built with 2.0.1 on both
Leopard and Snow Leopard and it worked fine. I've just started a "port
upgrade outdated" on the Snow Leopard box and it will take some time
before it is done. I'll then do a build there and see what falls out.
I probably won't have an answer until tomorrow at the earliest.

I have found on some platforms (OS X was not one of them before this),
where you'd need to tell SWIG the paths to it's dependent libraries.
The MacPorts should have that all done properly unless there is
something that has overridden default directory locations along he
way. You can always try updating the librets-build.sh script to
include the path to the directory (e.g. add -I/opt/local/share/swig/
2.0.2) to the flags.

> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
> course it's set up to use the 2.0.2 version in macports, but I am
> not sure if maybe that's the problem, maybe you are expecting 1.3.31?

Aaah. Make sure the swig that "configure" finds is the same swig
being run at make.

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.

BOOM! That was it. I had a hunch it was a swig-specific thing. Thanks for pointing me in the right direction. Here's what was going on

So, the swig package has been updated to 2.0.2 but all of the bindings are still at 2.0.1, and the php/ subdir was all by itself in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/2.0.2.

I just copied the php/ dir over to 2.0.2 and it was able to finish building.

What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

There is one more strange thing going on.

When you build, it fails the first time somewhere in the antlr build I think. If you simple build again, it completes. No idea what's going on there but thought I'd mention it.

Thanks so much for taking the time to help out, it worked!

I will probably be back with more questions but this was a huge help.

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
BTW here is the diff of the Portfile changes I made.

--- /Users/Shared/src/ports/devel/librets/Portfile 2011-02-25 17:06:16.000000000 -0500
+++ /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/librets/Portfile 2009-12-17 00:31:05.000000000 -0500
@@ -4,7 +4,7 @@
PortSystem 1.0

name librets
-version 1.5.2
+version 1.4.0
revision 1
categories devel
platforms darwin
@@ -21,15 +21,13 @@
homepage http://www.crt.realtors.org/projects/rets/librets/
master_sites ${homepage}/files/

-checksums md5 74bcea0eb11f3c66cde5dc3ecea05224 \
- sha1 cc856a41bc8120865937d199c918542bf3d82a95 \
- rmd160 154a4fff9bbf994b739a1d30b3bb5eed9ecdd5d3
+checksums md5 e8c5bde8897d6f3d979b5415c4392961 \
+ sha1 b398098efce28b4afbe7020bfa070f6aeb8baac2 \
+ rmd160 28673dc8e60b782ad5def9a388490befd013a7d3

depends_lib port:boost port:curl port:swig


On Feb 26, 2011, at 12:13 AM, Mark Klein wrote:

>
> On Feb 25, 2011, at 2:36 PM, Alan Pinstein wrote:
>
>> I am now running into the same issue described in this very long
>> thread from last May/June where Randy was trying to help out:
>> It also required the underlying program to support globbing
>> internally. This is a common mistake made in unix shells. Just
>> wanted to point that out as it caused a lot of confusion on that
>> thread.
>
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am
>> more than willing to help update the Portfile to the latest librets
>> and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>
> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
> "std" directory and "php" directories exist and are readable to you.
>
>> My first question about this is -- which swig version is needed? I
>> did not find it mentioned anywhere.
>
> Anything greater than 1.3.33. But, SWIG (and MacPorts) has made some
> significant changes over the releases. I last built with 2.0.1 on both
> Leopard and Snow Leopard and it worked fine. I've just started a "port
> upgrade outdated" on the Snow Leopard box and it will take some time
> before it is done. I'll then do a build there and see what falls out.
> I probably won't have an answer until tomorrow at the earliest.
>
> I have found on some platforms (OS X was not one of them before this),
> where you'd need to tell SWIG the paths to it's dependent libraries.
> The MacPorts should have that all done properly unless there is
> something that has overridden default directory locations along he
> way. You can always try updating the librets-build.sh script to
> include the path to the directory (e.g. add -I/opt/local/share/swig/
> 2.0.2) to the flags.
>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of
>> course it's set up to use the 2.0.2 version in macports, but I am
>> not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Aaah. Make sure the swig that "configure" finds is the same swig
> being run at make.
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.

For what it's worth, I switched to Homebrew
(http://github.com/mxcl/homebrew) about 18 months ago and I've been
*very* happy. I've created a formula for librets that we use on our
mac dev machines, which you can get here:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/librets.rb

You'll also need swig:

https://github.com/bleything/homebrew/blob/librets/Library/Formula/swig.rb

It's very ruby-centric, since that's what we use, but you can edit the
librets formula and enable/disable specific languages.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Feb 25, 2011, at 9:50 PM, Alan Pinstein wrote:

>> Do a "ls /opt/local/share/swig/2.0.2" and make sure that both the
>> "std" directory and "php" directories exist and are readable to you.
>
> BOOM! That was it. I had a hunch it was a swig-specific thing.
> Thanks for pointing me in the right direction. Here's what was going
> on
>
> So, the swig package has been updated to 2.0.2 but all of the
> bindings are still at 2.0.1, and the php/ subdir was all by itself
> in /opt/local/share/swig/2.0.1 instead of in /opt/local/share/swig/
> 2.0.2.
>
> I just copied the php/ dir over to 2.0.2 and it was able to finish
> building.

That's interesting ... the SWIG port is borked. I port upgraded and
instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:

server:~ mklein$ port list installed | fgrep swig
swig @2.0.2 devel/swig
swig @2.0.2 devel/swig
swig-csharp @2.0.1 devel/swig-csharp
swig-csharp @2.0.1 devel/swig-csharp
swig-java @2.0.1 devel/swig-java
swig-java @2.0.1 devel/swig-java
swig-perl @2.0.1 devel/swig-perl
swig-perl @2.0.1 devel/swig-perl
swig-php5 @2.0.1 devel/swig-php5
swig-php5 @2.0.1 devel/swig-php5
swig-python @2.0.1 devel/swig-python
swig-python @2.0.1 devel/swig-python
swig-ruby @2.0.1 devel/swig-ruby
swig-ruby @2.0.1 devel/swig-ruby


>
> What a macports fail. I've been rebuilding macports stuff from
> scratch today due to a snow leopard upgrade and had so many little
> issues. Creating packages is hard work, I understand, but man is it
> frustrating when they are not architected well! I am very surprised
> to see the swig packages so fragile.

I've been using MacPorts for years and prefer leaving the integration
management to someone else. I've never had an issue like this in all
the years I've used it.

> There is one more strange thing going on.
>
> When you build, it fails the first time somewhere in the antlr build
> I think. If you simple build again, it completes. No idea what's
> going on there but thought I'd mention it.

I've never seen that before. Let me finish doing the port upgrade (can
you believe my ports are still building?) and then I'll clean and
rebuild libRETS here to see what's going on.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> That's interesting ... the SWIG port is borked. I port upgraded and
> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>
> server:~ mklein$ port list installed | fgrep swig
> swig @2.0.2 devel/swig
> swig-php5 @2.0.1 devel/swig-php5


Yep, that's what I'm seeing. I suppose I should open a bug @ macports for SWIG.

Macports actually has a cool extension architecture to deal with this problem; the php port uses this to manage extensions to PHP. SWIG should be using it too...

>> There is one more strange thing going on.
>>
>> When you build, it fails the first time somewhere in the antlr build
>> I think. If you simple build again, it completes. No idea what's
>> going on there but thought I'd mention it.
>
> I've never seen that before. Let me finish doing the port upgrade (can
> you believe my ports are still building?) and then I'll clean and
> rebuild libRETS here to see what's going on.

Yes, rebuilding can take forever if you have lots of ports sadly.

I might have to check out homebrew at some point. I'm not 100% sure I understand the advantage (over well-designed macports packages) but I will see...

Alan
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
The problem referenced in that thread from May was I could not get the
swig-php5 port installed at all. Kept getting the error ...

Error: You have a conflicting install of Berkeley DB in /usr/local,
please move it aside before building db46
Error: Target org.macports.extract returned: Berkeley DB in /usr/local
is in the way
Error: Failed to install db46

Without swig I'd get :3: Error: Unable to find 'php.swg' when
attempting to build libRETS, same as you.

I never did figure out where the conflicting db46 was to even move it
aside. It was not in /usr/local. And I'm not sure what is using it.
Since this was on my MacBook Pro for my own use I lost interest and
never got back to it. I've since had no problems building librets on
other systems by following the instructions.

On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
> Hi-
>
> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>
> I am trying to update our application to use the php bindings and am thus trying to build librets.
>
> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>
> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>
> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>
> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>
> In any case, a few details I picked up from the thread were:
>
> 1) The librets in macports is "maintained" and should build.
>
> The librets in macports is 1.4.0, which is very old at this point.
>
> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>
> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>
>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>         -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>> :3: Error: Unable to find 'php.swg'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>
>
> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>
>> "port installed swig*"
>>
>> Results:
>> The following ports are currently installed:
>>   swig @1.3.40_1 (active)
>
> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>
> port installed swig
>
> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>
>> port installed "swig*"
>>
>> Result:
>> The following ports are currently installed:
>>   swig @2.0.2_0 (active)
>>   swig-php5 @2.0.1_0 (active)
>
> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>
> In any case, I am still stuck at the missing "php.swg" file.
>
> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>
> There seems to be some thought that this was related to swig:
>
> >From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>
>> > In any case, I got the following error:
>> >
>> > swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>> >     -outdir build/swig/php5 ./project/swig/librets.i
>> > :3: Error: Unable to find 'php.swg'
>> > ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>> > ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>
>>
>> Is this the machine I originally set up or another one? Looks like
>> something is funny in the SWIG installation. What is the result of
>> "port installed swig*"?
>
>
> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>
> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>
> Looking forward to your response.
>
> Alan
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>



--
!!Rp
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ah ok that makes sense. Not sure why a macports was confused about /usr/local -- it normally doesn't do anything outside of /opt/local. MIght've been a bug, but seems like it doesn't matter anymore.

Alan

On Feb 26, 2011, at 11:49 AM, Randy Phillips wrote:

> The problem referenced in that thread from May was I could not get the
> swig-php5 port installed at all. Kept getting the error ...
>
> Error: You have a conflicting install of Berkeley DB in /usr/local,
> please move it aside before building db46
> Error: Target org.macports.extract returned: Berkeley DB in /usr/local
> is in the way
> Error: Failed to install db46
>
> Without swig I'd get :3: Error: Unable to find 'php.swg' when
> attempting to build libRETS, same as you.
>
> I never did figure out where the conflicting db46 was to even move it
> aside. It was not in /usr/local. And I'm not sure what is using it.
> Since this was on my MacBook Pro for my own use I lost interest and
> never got back to it. I've since had no problems building librets on
> other systems by following the instructions.
>
> On Fri, Feb 25, 2011 at 4:36 PM, Alan Pinstein <> wrote:
>> Hi-
>>
>> Thanks for your work on librets. We have a php app that we used librets on a long time ago; at that time the php bindings weren't working so we used the python ones.
>>
>> I am trying to update our application to use the php bindings and am thus trying to build librets.
>>
>> I am on Mac OS X / Snow Leopard. I have just re-built my macports for 64b-bit and that is working fine.
>>
>> I am now running into the same issue described in this very long thread from last May/June where Randy was trying to help out:
>>
>> http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002979.html
>>
>> I read the entire thread in detail. It seems that the issue was never resolved, the conversation looks like it just stopped.
>>
>> In any case, a few details I picked up from the thread were:
>>
>> 1) The librets in macports is "maintained" and should build.
>>
>> The librets in macports is 1.4.0, which is very old at this point.
>>
>> I am trying to patch the Portfile to use the 1.5.2 version. I have a bit of experience writing macports packages as well as building on the CLI in general. However, I don't have SWIG experience.
>>
>> In any case, I was unable to get either 1.4.0 or 1.5.2 to build. They both end up with the same problem:
>>
>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>> -outdir build/swig/php5 /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i
>>> :3: Error: Unable to find 'php.swg'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:86: Error: Unable to find 'std_string.i'
>>> /opt/local/var/macports/build/_Users_Shared_src_ports_devel_librets/work/librets-1.5.2/project/swig/librets.i:90: Error: Unable to find 'std_common.i'
>>
>>
>> 2) The thread got quite sidetracked on the topic of getting swig/php installed. At one point the person did this to "verify" that swig was installed:
>>
>>> "port installed swig*"
>>>
>>> Results:
>>> The following ports are currently installed:
>>> swig @1.3.40_1 (active)
>>
>> I will just point out that this is actually the expected result, even if swig-php5 is installed. The * (glob) operator works *before* being passed as an argument, so really this just ran:
>>
>> port installed swig
>>
>> If you want to pass the * (glob) to the underlying program, you have to put it in quotes, like so:
>>
>>> port installed "swig*"
>>>
>>> Result:
>>> The following ports are currently installed:
>>> swig @2.0.2_0 (active)
>>> swig-php5 @2.0.1_0 (active)
>>
>> It also required the underlying program to support globbing internally. This is a common mistake made in unix shells. Just wanted to point that out as it caused a lot of confusion on that thread.
>>
>> In any case, I am still stuck at the missing "php.swg" file.
>>
>> I would really appreciate any help I could get with this -- I am more than willing to help update the Portfile to the latest librets and share it back with the community.
>>
>> There seems to be some thought that this was related to swig:
>>
>>> From http://mail.crt.realtors.org/pipermail/librets-users/2010-May/002989.html
>>
>>>> In any case, I got the following error:
>>>>
>>>> swig -c++ -php5 -o build/swig/php5/librets_wrap.cpp \
>>>> -outdir build/swig/php5 ./project/swig/librets.i
>>>> :3: Error: Unable to find 'php.swg'
>>>> ./project/swig/librets.i:85: Error: Unable to find 'std_string.i'
>>>> ./project/swig/librets.i:89: Error: Unable to find 'std_common.i'
>>>
>>>
>>> Is this the machine I originally set up or another one? Looks like
>>> something is funny in the SWIG installation. What is the result of
>>> "port installed swig*"?
>>
>>
>> My first question about this is -- which swig version is needed? I did not find it mentioned anywhere.
>>
>> I have both 1.3.31 installed (system) and 2.0.2 (macports). Of course it's set up to use the 2.0.2 version in macports, but I am not sure if maybe that's the problem, maybe you are expecting 1.3.31?
>>
>> Looking forward to your response.
>>
>> Alan
>>
>> _______________________________________________
>> libRETS-users mailing list
>> libRETS-
>> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>>
>
>
>
> --
> !!Rp
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:

>> That's interesting ... the SWIG port is borked. I port upgraded and
>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>
>> server:~ mklein$ port list installed | fgrep swig
>> swig @2.0.2 devel/swig
>> swig-php5 @2.0.1 devel/swig-php5
>
>
> Yep, that's what I'm seeing. I suppose I should open a bug @
> macports for SWIG.

If you do a "swig -swiglib" you can see where SWIG is looking for its
libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
box too after the port upgrade.


_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
Ok, well I posted a comment to the swig port maintainer. Maybe he'll come up with a more robust way to deal with this issue in the future.

Alan

On Feb 26, 2011, at 2:28 PM, Mark Klein wrote:

>
> On Feb 26, 2011, at 8:06 AM, Alan Pinstein wrote:
>
>>> That's interesting ... the SWIG port is borked. I port upgraded and
>>> instead of seeing one set of 2.0.1 and one set of 2.0.2, I see:
>>>
>>> server:~ mklein$ port list installed | fgrep swig
>>> swig @2.0.2 devel/swig
>>> swig-php5 @2.0.1 devel/swig-php5
>>
>>
>> Yep, that's what I'm seeing. I suppose I should open a bug @
>> macports for SWIG.
>
> If you do a "swig -swiglib" you can see where SWIG is looking for its
> libraries. Yup, it's a MacPorts bug. I just got done "cleaning" up my
> box too after the port upgrade.
>
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-
> http://mail.crt.realtors.org/mailman/listinfo/librets-users

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
wow! Homebrew has come a long way since last time I looked at it.
On Feb 26, 2011, at 3:25 AM, Ben Bleything wrote:

> On Fri, Feb 25, 2011 at 9:50 PM, Alan Pinstein <> wrote:
>> What a macports fail. I've been rebuilding macports stuff from scratch today due to a snow leopard upgrade and had so many little issues. Creating packages is hard work, I understand, but man is it frustrating when they are not architected well! I am very surprised to see the swig packages so fragile.
>
> For what it's worth, I switched to Homebrew
> (http://github.com/mxcl/homebrew) about 18 months ago and I've been
> *very* happy.

wow! Homebrew has come a long way since last time I looked at it. I think I see some playing in my future.

Keith

--
Keith T. Garner - - 312-329-3294 - http://realtor.org/
National Association of REALTORS® - VP - Information Technology Services

_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)

On Feb 27, 2011, at 11:39 AM, Keith T. Garner wrote:

> wow! Homebrew has come a long way since last time I looked at it.

I suppose the real test comes when upgrading packages from one release
to the next ... that's where many package mangers either succeed well,
or fail miserably. To date with MacPorts, I've had only one failure
(that was quickly resolved) when doing "sudo port selfupdate && port
update outdated".

I think I'll let one of you "take the plunge" and tell me how things
work down the road ... I'll jump ship then. :-)
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
On Sun, Feb 27, 2011 at 11:52 AM, Mark Klein <> wrote:
> I suppose the real test comes when upgrading packages from one release
> to the next ... that's where many package mangers either succeed well,
> or fail miserably. To date with MacPorts, I've had only one failure
> (that was quickly resolved) when doing "sudo port selfupdate && port
> update outdated".

That's what I like about homebrew. It installs everything into
/usr/local/Cellar// and then symlinks files
appropriately. Removing something means deleting the directory and
then removing dead symlinks from elsewhere in /usr/local. Upgrading
just installs to a new subdir and replaces the symlinks.

> I think I'll let one of you "take the plunge" and tell me how things
> work down the road ... I'll jump ship then. :-)

Like I said, switched over a year and a half ago and haven't looked
back. There's been some pain for sure, but overall it's much, much
better than macports.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)
> On Sun, Feb 27, 2011 at 11:52 AM, Mark Klein <> wrote:
>> I suppose the real test comes when upgrading packages from one release
>> to the next ... that's where many package mangers either succeed well,
>> or fail miserably. To date with MacPorts, I've had only one failure
>> (that was quickly resolved) when doing "sudo port selfupdate && port
>> update outdated".
>
> That's what I like about homebrew. It installs everything into
> /usr/local/Cellar// and then symlinks files
> appropriately. Removing something means deleting the directory and
> then removing dead symlinks from elsewhere in /usr/local. Upgrading
> just installs to a new subdir and replaces the symlinks.

I keep hearing from everyone that homebrew is better, but the arguments they make are not convincing.

I am not sure how Homebrew would've avoided this problem; it is essentially a bug in the swig package definition. The newer version of the swig package didn't remember to move the swig language defs to the right places.

To me the real test is how a system responds when you are upgrading things that have had lots of dependency changes; it's a problem that gets worse as you scale out the # of packages and my gut tells me that homebrew will eventually suffer this problem as well since I don't see any material improvements they've made to deal with the problem. However, I could just be missing something.


On Mon, Feb 28, 2011 at 9:05 AM, Alan Pinstein <> wrote:
> I am not sure how Homebrew would've avoided this problem; it is essentially
> a bug in the swig package definition. The newer version of the swig package
> didn't remember to move the swig language defs to the right places.

It's a philosophy issue. Homebrew tends to install everything as the
upstream maintainer intended... that is, they don't change anything,
they just download the source tarball and install it.

This solves the problem of a package maintainer not keeping up with
upstream changes... it's only in relatively rare cases that Homebrew,
as a packaging system, changes anything about the install. If the swig
distribution suffered a problem, so would homebrew's package... but if
the swig source was fine, so was the homebrew package.

> To me the real test is how a system responds when you are upgrading things
> that have had lots of dependency changes; it's a problem that gets worse as
> you scale out the # of packages and my gut tells me that homebrew will
> eventually suffer this problem as well since I don't see any material
> improvements they've made to deal with the problem. However, I could just be
> missing something.

It's partly mitigated by a pretty rigid adherence to the policy of a)
using dependencies already on the system wherever possible; and b) not
duplicating anything that OSX provides. This is actually a bit of a
problem for the librets package, as it won't build with the version of
swig that Apple ships and the Homebrew maintainers are reluctant to
duplicate swig.

The result is that you don't have a packaging system that's
reinstalling a ton of stuff you already have. That makes the
dependency resolution problem smaller, but certainly doesn't "solve"
it.

All I can tell you is that my experience has been that I never fight
with homebrew, whereas I was fighting with macports all the time.

Ben
_______________________________________________
libRETS-users mailing list
libRETS-
http://mail.crt.realtors.org/mailman/listinfo/librets-users
)