[libRETS-users] Re: Building retsLib and ezRets on Mac OS X 10.4

[Keith T. Garner]

Tom Wiebe wrote:
> Yeah, a transcription error, I'm actually building a macport (formerly
> darwinport)

I'm very familiar with ports.  I couldn't live without them.  :)

> for librets and, hopefully ezrets after that. The portfile
> entry was actually:
> 
> build.env        CFLAGS=-I${prefix}/include LDFLAGS=-L${prefix}/lib
> 
> I put it into a configure statement and edited the path to make it
> clearer, deleting the -L as I went.
> 
>>
>>> is the configure statement I'm passing for librets and, all the
>>> appropriate goodies are living in the locations noted above.
>>
>> It looks good otherwise.
>>
>> [snip]
>>
>>> and my JAVA_HOME is set to
>>> JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home, which I
>>> believe to be correct.
>>
>> I haven't had to do this on my MacBook Pro, but it probably doesn't hurt.
>>
>> Anyway, it doesn't effect the error you're seeing.  The test is to see if
>> the we can link against the C++ level antlr lib.
> 
> 
> Yeah, I don't think it's actually using any Java bits here (but am not
> sure), it was mentioned in the readme's though so thought it best to try
> setting it first.

The runtime for antlr that does code generation is in java.  Its used after
you type make it comes into play.  However, that code that is generated
depends on the native runtime library.

> I'm suspecting a problem with my macports build of Antlr right now. I've
> built a new portfile to install the latest antlr (2.7.7) and am
> installing it now. Seems to be a problem with the antlr download site at
> the moment though, I've got 15% of it 10 minutes in so I'll have to wait
> a bit to see if that makes a difference, it seems.

I'm not using the antlr port, I have it installed by hand (but encapped, of
course.)  I can't remember why I'm using a hand compile off the top of my head.

I just did a test where I uninstalled my hand compiled antlr and used the
ports version.  I figured out the source of your problem.  You want to use
CPPFLAGS (since this is C++) and not CFLAGS.  Using CFLAGS, the antlr test
fails.  Using CPPFLAGS it works fine with the antlr in ports.

Actually, thanks for having me do this test.  I found a type-o in the make
system that was causing compiles with cppunit to fail.  Must have been
awhile since we ran unit tests.  (cppunit also coming out of ports.)

Keith

-- 
  Keith T. Garner - Managing Director - Center for REALTOR® Technology
   kgarner at realtors.org - 312-329-3294 - http://blog.realtors.org/crt