So what changed to make it show up now? The main question is how to fix it.
My configure string always has included a set of paths to proj. I'm using the same configure string now that I was using a few days back when GRASS 7 compiled without errors. ./configure --with-freetype --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2 /Library/Frameworks/FreeType.framework/unix/include" --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj --with-geos=/Library/Frameworks/GEOS.framework/Programs/geos-config --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-cairo --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo /Library/Frameworks/cairo.framework/unix/include" --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql --with-odbc --with-sqlite --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x --with-cxx --with-opengl=aqua --without-readline --prefix=/Applications/GRASS --enable-macosx-app --with-python --with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.11.0/bin/wx-config --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders" --with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386 x86_64" Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 28, 2010, at 9:33 PM, Glynn Clements wrote: > > William Kyngesburye wrote: > >> It's VECT_INC and is set in one of the makefile fragments, I think. It >> used to be all in grass.make. Glynn's the master of all that makefile >> magic. > > VECT_INC has been empty for a long time now, and it never contained > $(PROJINC) directly or indirectly. > > It was first added to Grass.make.in in r11189 on 2003-02-27, at which > time it had the value $(PQINCPATH). It stayed that way until r12781 on > 2004-05-21, when it became empty. And it has been empty ever since. > > Any code which uses PROJ headers should be using $(PROJINC). > > You may be thinking of VECT_CFLAGS, which is defined as: > > VECT_CFLAGS = $(GDALCFLAGS) $(GEOSCFLAGS) > > FWIW, I suspect that this issue may have been hidden in the past due > to "gdal-config --cflags" providing the necessary switches. GDAL > itself uses PROJ, although its headers don't require the PROJ headers. > > -- > Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
