Re: building with AquaTerm

[Mojca M. <moj...@gm...>]

2011/3/9 Hans-Bernhard Bröker wrote:
> On 09.03.2011 19:59, Mojca Miklavec wrote:
>
>> If I use
>>     CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
>> --disable-wxwidgets
>
> A side note: for quite some time this hasn't been the recommended way of
> setting flags.  That had better be
>
>  ./configure CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib
> --disable-wxwidgets
>
> i.e. with the flags initializations as arguments to ./configure, rather than
> environment variables.

Thanks for the hint. I will remember it (I was trying to use that on
several other programs and many don't favour it).

>> then it works, but it would be much better if it wasn't required to
>> manually set flags.
>
> It's up to _you_ to choose.  You can
>
> a) make sure libraries are only in places where the compiler already looks
> by default.  This is what places like /usr/local are for, and how systems
> like MacPorts supposedly work.

I would like to avoid that. *everything else* works without having to
install it separately but aquaterm.

Here are the instructions:
    http://slashusr.wordpress.com/2010/01/17/gnuplot-with-aquaterm-on-osx-snow-leopard/
But please note that it get *way* more ugly than that

Here is where all the fun begins. I *have to* install AquaTerm to
/usr/local/..., but then gnuplot will nevertheless use the version
from /opt/local/... Worse. Gnuplot will link against
/opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
and when running gnuplot, it will open /Applications/AquaTerm.app
(instead of /Applications/MacPorts/AquaTerm.app) which links against
/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm. So it will
use to possibly completely different and incompatible libraries.

And unless both the version under /opt and the "system-wide" versions
are *exactly* the same, nothing will work at all. (It simply hangs
forever.)

> b) change your compiler's configuration so the places you keep libraries get
> added to the list of places the compiler looks in (C_INCLUDE_PATH,
> D_LIBRARY_PATH or whatever), or

Thanks. This seems to make most sense, but I would still prefer if it
would work out of the box. I have found:
       C_INCLUDE_PATH
       CPLUS_INCLUDE_PATH
       OBJC_INCLUDE_PATH
       LIBRARY_PATH
But I need to check how this inferferes with other switches like
MACOSX_DEPLOYMENT_TARGET which has its own idea about default paths to
search for. I didn't test it yet.

> c) go the hard way: explicitly add those directories to the CFLAGS etc.
> every time you ./configure or otherwise build a program.

That is tedious. I find it nasty enough that I have to keep disabling
xwidgets to aviod problems. And it is even less obvious for users with
very little experience in compiling. (Those who have to compile
gnuplot on mac for one reason or the other.)

> You really have to make up your mind: either you work _with_ systems like
> MacPorts, Find or whatever, or against them.

I'm not sure that I understood this sentence (what exactly it means in
this particular context).
What do you refer to with "work _with_ system like MacPorts"?

>> It's a problem of missing -I and -L switches to search for header and
>> library files.
>
> Or it's a problem of having put libraries in a place where the compiler
> never knew to look.

But then why do all the other libraries work? Or better: why do all
the other libraries get included even when I don't want them to be
included at all (wxterminal being the most obvious one which forces me
to use --disable-wxwidgets every time when I want to build gnuplot)?

Whenever I want to "get rid" of libraries that gnuplot or any other
program would take from MacPorts, I have to explicitely exclude
macports from PATH. AquaTerm is the only exception to the rule.

Mojca