Re: [Xastir] Xastir virtual machine now available for download

[Tom Russo]

On Mon, Dec 18, 2006 at 08:30:50PM -0700, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> The Wiki instructions fall into the usual *nix trap. Rather than
> simple straight forward instructions, they fall off track talking
> about options available. You need to read a couple paragraphs, skip a
> few, read another, skip 2 more, and then all of the sudden you're at
> "Hey, I'm done".

I've added a pair of quick-start guides to the page for those who don't
want to use the navigation links to hop around.  At the very least
it will give the user an idea of the rough process they'll be following.

I also rearranged sections so they flow more in the order of the quick start
guides.

Feel free to improve the documentation as you see fit.  After the number
of hours I've spent refining both the VM and the documentation of it, I'm 
pretty much tapped out.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Tom Russo]

On Mon, Dec 18, 2006 at 08:32:02PM -0800, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> On Mon, 18 Dec 2006, Tom Russo wrote:
> 
> > If the user plans never to use shapefiles, then we should recommend that the
> > user specifiy "--without-rtree."  Six of one, half a dozen of another
> > right now.
> > 
> > rtree is a tiny, tiny library, and if shapefiles aren't used then rtree 
> > being
> > compiled in has no effect at all.
> 
> I agree.  Make it so.

Done.

I should correct my statement there: if shapefile support is not compiled in
to xastir, rtree is not either.  But shapefile support is pretty much always
compiled in to xastir now, since we bundle it.  At any rate, the impact of 
having rtree support compiled in when the user is not using the shapefile 
support (even if it's compiled in) is negligible.

Turning off rtree is done by adding the "--without-rtree" flag when 
configuring.  Those who have been routinely using "--with-rtree" can just 
leave that off now, but leaving it there will do no harm.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Darryl Gibson]

Curt Mills wrote:

On Mon, 18 Dec 2006, Tom Russo wrote:


If the user plans never to use shapefiles, then we should recommend that the
user specifiy "--without-rtree."  Six of one, half a dozen of another
right now.

rtree is a tiny, tiny library, and if shapefiles aren't used then rtree being
compiled in has no effect at all.


I agree.  Make it so.


Danger!? Where is my phaser!?

--
Darryl Gibson N2DIY
RLU X 182668/379552

“Arms are the only true badges of liberty. The possession of arms is the 
distinction of a free man from a slave.”   --  Andrew Fletcher, A 
Discourse of Government with relation to Militias (1698)

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Curt Mills]

On Mon, 18 Dec 2006, Tom Russo wrote:

> If the user plans never to use shapefiles, then we should recommend that the
> user specifiy "--without-rtree."  Six of one, half a dozen of another
> right now.
> 
> rtree is a tiny, tiny library, and if shapefiles aren't used then rtree being
> compiled in has no effect at all.

I agree.  Make it so.

-- 
Curt, WE7U. archer at eskimo dot com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Tom Russo]

On Mon, Dec 18, 2006 at 09:18:43PM -0500, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> On Mon, 18 Dec 2006, Tom Russo wrote:
> 
> > On Mon, Dec 18, 2006 at 03:07:47PM -0700, we recorded a bogon-computron 
> > collision of the <[EMAIL PROTECTED]> flavor, containing:
> > > xastir 1.8.5 has been configured to use the following
> > 
> > > Building with rtree indexing ... : no
> > 
> > So, does anyone here still think that rtree should remain off by default?
> > It's been in the code for almost two years, and I think it's had a good 
> > experimental run.  The speed-up vs. memory trade-off seems worth it, 
> > at least if you're doing a bunch of zooming and panning.  Time to turn it
> > on by default?
> > 
> 
> I'd say Yes, but with the caveat that it be such that if it won't ever
> get used, it isn't built or included. 

How do you propose that we detect at compile time whether it will ever get used?

If the user plans never to use shapefiles, then we should recommend that the
user specifiy "--without-rtree."  Six of one, half a dozen of another
right now.

rtree is a tiny, tiny library, and if shapefiles aren't used then rtree being
compiled in has no effect at all.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] OSX & Cygwin test please?

[Curt Mills]

On Mon, 18 Dec 2006, William McKeehan wrote:

> conftest.c:155: warning: function declaration isn't a prototype
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot
> find -ldpstk
> 
> Then it went on to test for ImageMagick. It failed with the same error.

That one bugs me.  If it actually found IM at that point there
shouldn't have been an error, so I wonder if I failed to restore
some variables after the GM test.  Another possibility is that GM
installed with the same names as IM, so either search would find the
GM library on Cygwin.


> I then removed GM from my cygwin setup and tried configure again. It found IM
> and seemed happy with it.

I have both GM and IM installed on Linux.  configure finds GM
unless I add the --without-graphicsmagick flag at which point it
finds and uses IM.  I kind'a halfway expected the same sort of
operation on Cygwin.  With the broken GM package there I now expect
it to do an auto-failover to the IM tests and compil IM in fine.  It
bugs me that it's not doing that.

-- 
Curt, WE7U. archer at eskimo dot com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Xastir virtual machine now available for download

[James Ewen]

On 12/2/06, Tom Russo <[EMAIL PROTECTED]> wrote:

Thanks to Jason Winningham, the Xastir virtual machine I made for use in
VMware player is now available for download


I was finally able to get a chance to download and install the Xastir
virtual machine...

Jason's server rocks! I was able to pull down the file at an average
of 3.5 Mbps, with peaks to 4.5 Mbps. If I were on a fast connection, I
wonder what I could have done!

The Wiki instructions fall into the usual *nix trap. Rather than
simple straight forward instructions, they fall off track talking
about options available. You need to read a couple paragraphs, skip a
few, read another, skip 2 more, and then all of the sudden you're at
"Hey, I'm done".

Simple linear instructions with no branches are what is required to
make these things easy to follow. After the fact, you can add in all
the options, and let people know what they can do if desired.

The Cygwin instructions are written in a very linear fashion, and are
very easy to follow. I was able to follow the VMWare instructions, but
had to skip around a bit to get the proper path.

I had a bit of trouble with getting access to the ethernet device, but
that was my own fault. I had disabled the VMWare network devices
manually attempting to solve a networking problem in the week between
VMWare download and the Xastir appliance download. I did manage to get
the ethernet screwed up again, which I have not yet determined if it
was a one time problem, or a repeatable event.

I also discovered that one needs to disable any screen savers in the
VMWare world. My CPU cycles maxed out on me, which I was able to track
down to the VMWare process. Switching back into it, I found the "radar
screen" screen saver merrily chugging along. Killing the screen saver
brought the CPU cycles down a whole lot, but about that time is when
the ethernet broke.

For being a minimalist desktop environment, Xubuntu presents a nice
user interface!

James
VE6SRV
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Greg Eigsti]

> Side topic -- At what point does something like libxastir get created?

Or the command line version of Xastir server? ;)

Greg
KD7UBJ



___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Dan Brown]

On Mon, 18 Dec 2006, Tom Russo wrote:

> On Mon, Dec 18, 2006 at 03:07:47PM -0700, we recorded a bogon-computron 
> collision of the <[EMAIL PROTECTED]> flavor, containing:
> > xastir 1.8.5 has been configured to use the following
> 
> > Building with rtree indexing ... : no
> 
> So, does anyone here still think that rtree should remain off by default?
> It's been in the code for almost two years, and I think it's had a good 
> experimental run.  The speed-up vs. memory trade-off seems worth it, 
> at least if you're doing a bunch of zooming and panning.  Time to turn it
> on by default?
> 

I'd say Yes, but with the caveat that it be such that if it won't ever
get used, it isn't built or included. 

Side topic -- At what point does something like libxastir get created? 


--
Dan Brown 
[EMAIL PROTECTED]

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Jason Winningham]

On Dec 18, 2006, at 5:28 PM, Tom Russo wrote:


Time to turn it on by default?


yep.  I've been ready for a while now.

-Jason
kg4wsv



___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[N1OFZ]

Yes!

On Dec 18, 2006, at 6:28 PM, Tom Russo wrote:

So, does anyone here still think that rtree should remain off by  
default?
It's been in the code for almost two years, and I think it's had a  
good

experimental run.  The speed-up vs. memory trade-off seems worth it,
at least if you're doing a bunch of zooming and panning.  Time to  
turn it

on by default?


___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Steve Friis]

Tom Russo wrote:

On Mon, Dec 18, 2006 at 03:07:47PM -0700, we recorded a bogon-computron collision of 
the <[EMAIL PROTECTED]> flavor, containing:
  

xastir 1.8.5 has been configured to use the following



  

Building with rtree indexing ... : no



So, does anyone here still think that rtree should remain off by default?
It's been in the code for almost two years, and I think it's had a good 
experimental run.  The speed-up vs. memory trade-off seems worth it, 
at least if you're doing a bunch of zooming and panning.  Time to turn it

on by default?

  


I am willing to play with that, to turn it on manually do I do 
<./configure --with-rtree> ??


Z

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Reporting configure report

[Tom Russo]

On Mon, Dec 18, 2006 at 03:07:47PM -0700, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> xastir 1.8.5 has been configured to use the following

> Building with rtree indexing ... : no

So, does anyone here still think that rtree should remain off by default?
It's been in the code for almost two years, and I think it's had a good 
experimental run.  The speed-up vs. memory trade-off seems worth it, 
at least if you're doing a bunch of zooming and panning.  Time to turn it
on by default?

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] OSX & Cygwin test please?

[Greg Eigsti]

Woohoo!  I got PPC OS X and x86 FreeBSD 6.1 xastir building/running with
GraphicsMagick (OS X MacPorts, FreeBSD pkg_add)!!!

The key for me seems to be removing the ImageMagick package from the
machines or else it is preferred.

On both machines I ran configure as follows:
./configure --with-bdb-incdir=/usr/local/include/db42 --with-rtree


Greg
KD7UBJ


On 12/18/06 2:00 PM, "William McKeehan" <[EMAIL PROTECTED]>
wrote:

> Sorry for the delay in testing.
> 
> I added the GraphicsMagick library and run-time stuff to my cygwin setup and
> tried to reconfigure. The config process found GM, but failed to find ldpstk:
> 
> conftest.c:155: warning: function declaration isn't a prototype
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot
> find -ldpstk
> 
> Then it went on to test for ImageMagick. It failed with the same error.
> 
> I then removed GM from my cygwin setup and tried configure again. It found IM
> and seemed happy with it.
> 



___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

[Xastir] Reporting configure report

[Steve Friis]

xastir 1.8.5 has been configured to use the following
options and external libraries:

Building with AX25 . : no
Building with Festival . : yes
Building with GPSMan ... : yes
Building with GraphicsMagick/ImageMagick ... : ImageMagick
Building with libproj .. : yes
Building with GeoTiff .. : yes
Building with GDAL/OGR . : yes
Building with ShapeLib . : yes
Building with pcre . : yes
Building with dbfawk ... : yes
Building with map caching .. : yes
Building with rtree indexing ... : no
--
Building with ErrorPopups (Old Method) . : no
Building with libgc (Debug)  : no
Building with profiling (Debug)  : no
Building with Linux Standard Base .. : no



Steve/WM5Z

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] OSX & Cygwin test please?

[William McKeehan]

Sorry for the delay in testing.

I added the GraphicsMagick library and run-time stuff to my cygwin setup and
tried to reconfigure. The config process found GM, but failed to find ldpstk:

conftest.c:155: warning: function declaration isn't a prototype
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot
find -ldpstk

Then it went on to test for ImageMagick. It failed with the same error.

I then removed GM from my cygwin setup and tried configure again. It found IM
and seemed happy with it.


-- 
William McKeehan

On Mon, December 18, 2006 2:42 pm, Curt, WE7U wrote:
>
> If someone could try the latest configure.ac/acinclude.m4 files from
> CVS and let me know how they perform on OSX and/or Cygwin, it'd be
> most appreciated.
>
> I'd like to see it run against a Cygwin system that has both
> GraphicsMagick and ImageMagick installed to see if the failover
> from GM to IM works as it should now.
>
> If anyone has any ideas on how to get rid of the below sorts of
> includes when configuring on OSX, I'd like to hear about them.  If
> it's just not plausible to auto-search for these, I'd like to hear
> that as well:
>
> --with-bdb-libdir=/opt/local/lib/db45 \
> --with-bdb-incdir=/opt/local/include/db45
>
> --
> Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
> "Lotto:A tax on people who are bad at math." -- unknown
> "Windows:  Microsoft's tax on computer illiterates." -- WE7U
> "The world DOES revolve around me:  I picked the coordinate system!"
> ___
> Xastir mailing list
> Xastir@xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>

___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] OSX & Cygwin test please?

[Greg Eigsti]

> I haven't done much work yet on libdb.  Was this with the latest CVS
Yes

> As far as GraphicsMagick, you may want to install GM again and check
Am doing so on FreeBSD 6.1 right now; will do so on OS X soon.  Want to
re-read Dan Brown's OS X email before doing so.

We lost phone/internet again last night so I was unable to get to it
earlier.

Greg

On 12/18/06 1:05 PM, "Curt, WE7U" <[EMAIL PROTECTED]> wrote:

> On Mon, 18 Dec 2006, Greg Eigsti wrote:
> 
>> I am using Fink db42 on PPC OS X 10.4.8 and still need to use configure's
>> --with-bdb-incdir switch to get map caching.  Did not try with GM as that
>> never seems to work (build fails) on my OS X systems.
>> 
>> ./configure --with-bdb-incdir=/usr/local/include/db42 --with-rtree
> 
> I haven't done much work yet on libdb.  Was this with the latest CVS
> as of this morning?  If so, I'm happy.
> 
> As far as GraphicsMagick, you may want to install GM again and check
> Xastir's config.log file to see if GM is complaining about some
> library that it needs.  That is common with GM or IM.
> 
> --
> Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
> "Lotto:A tax on people who are bad at math." -- unknown
> "Windows:  Microsoft's tax on computer illiterates." -- WE7U
> "The world DOES revolve around me:  I picked the coordinate system!"
> 



___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] OSX & Cygwin test please?

[Greg Eigsti]

And I am still having to use --with-bdb-incdir on my vanilla FreeBSD 6.1
system (using pkg_add ports).

I'll try to get to MacTel OS X later today...

Greg
KD7UBJ

On 12/18/06 11:42 AM, "Curt, WE7U" <[EMAIL PROTECTED]> wrote:

> 
> If someone could try the latest configure.ac/acinclude.m4 files from
> CVS and let me know how they perform on OSX and/or Cygwin, it'd be
> most appreciated.
> 
> I'd like to see it run against a Cygwin system that has both
> GraphicsMagick and ImageMagick installed to see if the failover
> from GM to IM works as it should now.
> 
> If anyone has any ideas on how to get rid of the below sorts of
> includes when configuring on OSX, I'd like to hear about them.  If
> it's just not plausible to auto-search for these, I'd like to hear
> that as well:
> 
> --with-bdb-libdir=/opt/local/lib/db45 \
> --with-bdb-incdir=/opt/local/include/db45
> 
> --
> Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
> "Lotto:A tax on people who are bad at math." -- unknown
> "Windows:  Microsoft's tax on computer illiterates." -- WE7U
> "The world DOES revolve around me:  I picked the coordinate system!"
> ___
> Xastir mailing list
> Xastir@xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
> 



___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] OSX & Cygwin test please?

[Curt, WE7U]

On Mon, 18 Dec 2006, Greg Eigsti wrote:

> I am using Fink db42 on PPC OS X 10.4.8 and still need to use configure's
> --with-bdb-incdir switch to get map caching.  Did not try with GM as that
> never seems to work (build fails) on my OS X systems.
>
> ./configure --with-bdb-incdir=/usr/local/include/db42 --with-rtree

I haven't done much work yet on libdb.  Was this with the latest CVS
as of this morning?  If so, I'm happy.

As far as GraphicsMagick, you may want to install GM again and check
Xastir's config.log file to see if GM is complaining about some
library that it needs.  That is common with GM or IM.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] OSX & Cygwin test please?

[Greg Eigsti]

I am using Fink db42 on PPC OS X 10.4.8 and still need to use configure's
--with-bdb-incdir switch to get map caching.  Did not try with GM as that
never seems to work (build fails) on my OS X systems.

./configure --with-bdb-incdir=/usr/local/include/db42 --with-rtree

Greg
KD7UBJ



On 12/18/06 11:42 AM, "Curt, WE7U" <[EMAIL PROTECTED]> wrote:

> 
> If someone could try the latest configure.ac/acinclude.m4 files from
> CVS and let me know how they perform on OSX and/or Cygwin, it'd be
> most appreciated.
> 
> I'd like to see it run against a Cygwin system that has both
> GraphicsMagick and ImageMagick installed to see if the failover
> from GM to IM works as it should now.
> 
> If anyone has any ideas on how to get rid of the below sorts of
> includes when configuring on OSX, I'd like to hear about them.  If
> it's just not plausible to auto-search for these, I'd like to hear
> that as well:
> 
> --with-bdb-libdir=/opt/local/lib/db45 \
> --with-bdb-incdir=/opt/local/include/db45
> 
> --
> Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
> "Lotto:A tax on people who are bad at math." -- unknown
> "Windows:  Microsoft's tax on computer illiterates." -- WE7U
> "The world DOES revolve around me:  I picked the coordinate system!"
> ___
> Xastir mailing list
> Xastir@xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
> 



___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Need Feedback: CVS, plus LSB Xastir info

[Bob Nielsen]

On Dec 18, 2006, at 11:23 AM, Curt, WE7U wrote:


On Fri, 15 Dec 2006, Jason Winningham wrote:


on Mac OS X, depends on if fink, darwinports, or standard install is
used.  The base dir will be one of

/sw
/opt
/usr/local


Is this a correct and complete list?

In particular, is it "/opt/local", or "/opt"?

Are both "/opt/local" and "/opt" possible?

I've got a new version of the configure files that checks in
"/sw/bin", "/opt/local/bin", and the standard places (/usr/bin,
/usr/local/bin, etc).  The extra two places are checked only if
configuring on OSX.

Do I need to add "/opt/bin" (for OSX only) as well?


In my OS X box with Darwinports installed, the only subdirectory  
under /opt is /opt/local and everything else is under that.  Fink  
installs stuff under /sw.  I had both Darwinports and fink installed  
at one time, but there were occasional conflicts (which probably  
could have been taken care of by ordering the $PATH and search  
order).  I haven't tried compiling Xastir from scratch on that box  
yet, but 'port install xastir' will bring in 1.8.0.


Bob, N7XY




___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

[Xastir] OSX & Cygwin test please?

[Curt, WE7U]

If someone could try the latest configure.ac/acinclude.m4 files from
CVS and let me know how they perform on OSX and/or Cygwin, it'd be
most appreciated.

I'd like to see it run against a Cygwin system that has both
GraphicsMagick and ImageMagick installed to see if the failover
from GM to IM works as it should now.

If anyone has any ideas on how to get rid of the below sorts of
includes when configuring on OSX, I'd like to hear about them.  If
it's just not plausible to auto-search for these, I'd like to hear
that as well:

--with-bdb-libdir=/opt/local/lib/db45 \
--with-bdb-incdir=/opt/local/include/db45

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] Need Feedback: CVS, plus LSB Xastir info

[Curt, WE7U]

On Fri, 15 Dec 2006, Jason Winningham wrote:

> on Mac OS X, depends on if fink, darwinports, or standard install is
> used.  The base dir will be one of
>
> /sw
> /opt
> /usr/local

Is this a correct and complete list?

In particular, is it "/opt/local", or "/opt"?

Are both "/opt/local" and "/opt" possible?

I've got a new version of the configure files that checks in
"/sw/bin", "/opt/local/bin", and the standard places (/usr/bin,
/usr/local/bin, etc).  The extra two places are checked only if
configuring on OSX.

Do I need to add "/opt/bin" (for OSX only) as well?

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] mac osx 10.4.8 Xastir 1.8.5 working here, mostly.

[Curt, WE7U]

On Sat, 16 Dec 2006, Dan Brown wrote:

> re-re-ran get-maptools.sh
>
> Fixed tar definition in get-maptools.sh /usr/bin/tar

I removed the path from that line so at least that part should be
better now.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Curt, WE7U]

On Mon, 18 Dec 2006, Curt, WE7U wrote:

> So... On to the next question:
>
> Does AC_CHECK_PROG(), which we use to find Magick-config,
> GraphicsMagick-config, and gdal-config, also use one of the
> environment variables for its path?  If so our code there can be
> made simpler via the same method.  I can go hunt down the macro
> later to check if need be.

Never mind:  Found AC_PATH_PROG() which looks to do what I want.
This should simplify our IM/GM code somewhat and make it easier to
add more search paths in the future.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Curt, WE7U]

On Mon, 18 Dec 2006, Tom Russo wrote:

> What with systems like LSB stuffing things in /opt that we might not actually
> want to find, I think it's not an optimum idea.

They go into /opt//lib, /opt//include,
etc.


> Adding a special-casing block at the top is almost as easy as adding the
> thing you suggest, and establishes a pattern for fleshing out with other
> special cases as needed (when, say, darfink comes out and starts dumping
> libraries in /optsw/ or whatever).

Roger.  I'll accept that.  My idea was simpler but may have led to
problems in the future.

So... On to the next question:

Does AC_CHECK_PROG(), which we use to find Magick-config,
GraphicsMagick-config, and gdal-config, also use one of the
environment variables for its path?  If so our code there can be
made simpler via the same method.  I can go hunt down the macro
later to check if need be.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Tom Russo]

On Mon, Dec 18, 2006 at 07:50:32AM -0800, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> 
> Since we only use the "darwin" flag in two places, and since things
> like /sw, /opt, and /opt/local wouldn't normally hurt to search on
> non-OSX systems, how about adding those search paths at the
> beginning of configure.ac and/or acinclude.m4 in all cases?  I don't
> see a reason to make it system-specific in this case.

What with systems like LSB stuffing things in /opt that we might not actually
want to find, I think it's not an optimum idea.

I really think it's best to add non-standard search paths only when it is known
that they're needed, and leave them out on systems that have standard libraries
in the standard paths that configure assumes.  Trying to do otherwise is the
path to madness.  Let's keep special cases as special cases, where their
specialness can be isolated and not turned into globalness.

Adding a special-casing block at the top is almost as easy as adding the
thing you suggest, and establishes a pattern for fleshing out with other
special cases as needed (when, say, darfink comes out and starts dumping
libraries in /optsw/ or whatever).

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Tom Russo]

On Mon, Dec 18, 2006 at 07:30:41AM -0800, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> On Mon, 18 Dec 2006, Curt, WE7U wrote:
> 
> > So I see your point Tom...  Is there a way we can use
> > AC_CHECK_HEADERS() and AC_CHECK_LIB() against non-standard
> > locations?  My Autoconf/automake/libtool book doesn't go into much
> > detail on things like this.  Maybe the only way to know for sure is
> > to go look at the code for the m4 macros themselves?
> >
> > If we could set up some paths before we called the m4 macros it
> > might simplify a lot of our configure code.
> 
> I see some examples here:
> 
> 
> 
> Grep for "/sw/lib" or "/opt/lib".

Ick.

That looks like a brute force attempt to search every possible combination
of non-standard locations.  Furthermore, they're searching in a completely
non-standard way for the existence of certain header files, which is not
how AC_CHECK_HEADER and AC_CHECK_LIB work --- the latter actually check if
the compiler can find and use the headers, not just that they exist.

Using system-specific CPPFLAGS and LDFLAGS is a much better way to do this
than the kinds of hacks present in the gnash-commit you posted up there.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Curt, WE7U]

On Mon, 18 Dec 2006, Tom Russo wrote:

> Have a block early on that adds those non-standard locations to LDFLAGS
> and CPPFLAGS, e.g. (fudging on syntax here):
>
> switch ($target)
>
>
>  *darwin*)
> LDFLAGS="-L/sw/lib $LDFLAGS"
> CPPFLAGS="-I/sw/include $CPPFLAGS"
>
> ... etc.
>
> AC_CHECK_HEADERS and AC_CHECK_LIB use LDFLAGS and CPPFLAGS in the compile
> and link lines they create, and setting them at the beginning like this takes
> care of all the idiosyncrasies once and for all.  We do stuff like this in
> the configure script of our project at work.  It makes for a fairly ugly
> block of system-dependent crud at the top of the configure.ac file, but really
> saves you a ton of system-dependent crud scattered all over the configure.ac
> file.
>
> Autotools are good for picking up most system details like "does the compiler
> support left-handed ternary operators on user-defined bogons?" but are not
> meant for searching the entire system for matching libraries --- which leads
> to a real pain when systems come up with their own arbitrary choices for
> where to put things (/opt, /sw/, /whatevertheheck/).  Fortunately, the
> macros make consistent use of things like LDFLAGS and CPPFLAGS, so there's
> a clean way to force it for specific systems.

Since we only use the "darwin" flag in two places, and since things
like /sw, /opt, and /opt/local wouldn't normally hurt to search on
non-OSX systems, how about adding those search paths at the
beginning of configure.ac and/or acinclude.m4 in all cases?  I don't
see a reason to make it system-specific in this case.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Tom Russo]

On Mon, Dec 18, 2006 at 07:16:03AM -0800, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> On Mon, 18 Dec 2006, Curt, WE7U wrote:
> 
> > > Of course, that shouldn't happen if we're doing an AC_CHECK_LIB, which 
> > > will
> > > attempt a link --- those should catch the missing "dipstick" issue by 
> > > failing
> > > to link the conftest.  As long as that's what's happening, it's all good. 
> > >  But
> > > I thought I heard that it was bombing badly.  Perhaps I misread things.
> >
> > Without a system to test on I can't be sure.
> >
> > Looks like we use AC_CHECK_PROG() to find "GraphicsMagick-config".
> > In the following section we use AC_CHECK_HEADERS() and
> > AC_CHECK_LIB(), but only if "darwin" isn't defined.  The comments
> > state that we don't want to use these additional functions on OSX
> > 'cuz the standard macros won't find them.  The GM section is VERY
> > similar to the IM section immediately preceeding it.
> 
> So I see your point Tom...  Is there a way we can use
> AC_CHECK_HEADERS() and AC_CHECK_LIB() against non-standard
> locations?  My Autoconf/automake/libtool book doesn't go into much
> detail on things like this.  Maybe the only way to know for sure is
> to go look at the code for the m4 macros themselves?

Yes.

Have a block early on that adds those non-standard locations to LDFLAGS
and CPPFLAGS, e.g. (fudging on syntax here):

switch ($target)


 *darwin*)
LDFLAGS="-L/sw/lib $LDFLAGS"
CPPFLAGS="-I/sw/include $CPPFLAGS"

... etc.

AC_CHECK_HEADERS and AC_CHECK_LIB use LDFLAGS and CPPFLAGS in the compile
and link lines they create, and setting them at the beginning like this takes
care of all the idiosyncrasies once and for all.  We do stuff like this in
the configure script of our project at work.  It makes for a fairly ugly
block of system-dependent crud at the top of the configure.ac file, but really 
saves you a ton of system-dependent crud scattered all over the configure.ac 
file.

Autotools are good for picking up most system details like "does the compiler 
support left-handed ternary operators on user-defined bogons?" but are not
meant for searching the entire system for matching libraries --- which leads
to a real pain when systems come up with their own arbitrary choices for 
where to put things (/opt, /sw/, /whatevertheheck/).  Fortunately, the
macros make consistent use of things like LDFLAGS and CPPFLAGS, so there's
a clean way to force it for specific systems.

> If we could set up some paths before we called the m4 macros it
> might simplify a lot of our configure code.

You betcha.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Curt, WE7U]

On Mon, 18 Dec 2006, Curt, WE7U wrote:

> So I see your point Tom...  Is there a way we can use
> AC_CHECK_HEADERS() and AC_CHECK_LIB() against non-standard
> locations?  My Autoconf/automake/libtool book doesn't go into much
> detail on things like this.  Maybe the only way to know for sure is
> to go look at the code for the m4 macros themselves?
>
> If we could set up some paths before we called the m4 macros it
> might simplify a lot of our configure code.

I see some examples here:



Grep for "/sw/lib" or "/opt/lib".

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Curt, WE7U]

On Mon, 18 Dec 2006, Curt, WE7U wrote:

> > Of course, that shouldn't happen if we're doing an AC_CHECK_LIB, which will
> > attempt a link --- those should catch the missing "dipstick" issue by 
> > failing
> > to link the conftest.  As long as that's what's happening, it's all good.  
> > But
> > I thought I heard that it was bombing badly.  Perhaps I misread things.
>
> Without a system to test on I can't be sure.
>
> Looks like we use AC_CHECK_PROG() to find "GraphicsMagick-config".
> In the following section we use AC_CHECK_HEADERS() and
> AC_CHECK_LIB(), but only if "darwin" isn't defined.  The comments
> state that we don't want to use these additional functions on OSX
> 'cuz the standard macros won't find them.  The GM section is VERY
> similar to the IM section immediately preceeding it.

So I see your point Tom...  Is there a way we can use
AC_CHECK_HEADERS() and AC_CHECK_LIB() against non-standard
locations?  My Autoconf/automake/libtool book doesn't go into much
detail on things like this.  Maybe the only way to know for sure is
to go look at the code for the m4 macros themselves?

If we could set up some paths before we called the m4 macros it
might simplify a lot of our configure code.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Curt, WE7U]

On Mon, 18 Dec 2006, Tom Russo wrote:

> But it sounded like what was happening was that Xastir's configure was finding
> GraphicsMagick, *NOT* failing during configure, not going on and using
> ImageMagick, and then ultimately failing during the final link of Xastir.

This may have been a slightly earlier version of
configure.ac/acinclude.m4.  The latest versions of each should do
the failover just fine.


> Of course, that shouldn't happen if we're doing an AC_CHECK_LIB, which will
> attempt a link --- those should catch the missing "dipstick" issue by failing
> to link the conftest.  As long as that's what's happening, it's all good.  But
> I thought I heard that it was bombing badly.  Perhaps I misread things.

Without a system to test on I can't be sure.

Looks like we use AC_CHECK_PROG() to find "GraphicsMagick-config".
In the following section we use AC_CHECK_HEADERS() and
AC_CHECK_LIB(), but only if "darwin" isn't defined.  The comments
state that we don't want to use these additional functions on OSX
'cuz the standard macros won't find them.  The GM section is VERY
similar to the IM section immediately preceeding it.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Tom Russo]

On Mon, Dec 18, 2006 at 06:46:38AM -0800, we recorded a bogon-computron 
collision of the <[EMAIL PROTECTED]> flavor, containing:
> On Fri, 15 Dec 2006, Tom Russo wrote:
> 
> > Apparently, though, GraphicsMagick is still in that state.  Either pitch
> > GraphicsMagick on Cygwin (if xastir's the only thing that's using it), 
> > downgrade
> > xorg to the previous version, or force xastir's configure script to ignore
> > the installed GraphicsMagick.
> 
> Xastir's "configure" will automatically search out GraphicsMagick.
> If the tests fail it'll then search out ImageMagick, so no hacks
> necessary to get the operation you describe.

But it sounded like what was happening was that Xastir's configure was finding
GraphicsMagick, *NOT* failing during configure, not going on and using 
ImageMagick, and then ultimately failing during the final link of Xastir.

Of course, that shouldn't happen if we're doing an AC_CHECK_LIB, which will
attempt a link --- those should catch the missing "dipstick" issue by failing 
to link the conftest.  As long as that's what's happening, it's all good.  But 
I thought I heard that it was bombing badly.  Perhaps I misread things.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Re: [Xastir] cygwin compile problem

[Curt, WE7U]

On Fri, 15 Dec 2006, Tom Russo wrote:

> Apparently, though, GraphicsMagick is still in that state.  Either pitch
> GraphicsMagick on Cygwin (if xastir's the only thing that's using it), 
> downgrade
> xorg to the previous version, or force xastir's configure script to ignore
> the installed GraphicsMagick.

Xastir's "configure" will automatically search out GraphicsMagick.
If the tests fail it'll then search out ImageMagick, so no hacks
necessary to get the operation you describe.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir