[GRASS-dev] GRASS 6.1.0 release preparation

[Michael Barton]

Benjamin,

I don't think this would work for precompiled binaries. They may be
installed on a system that doesn't have some of the dependencies. For
example, you can compile with MySQL support and then put GRASS on a system
without MySQL.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Benjamin Ducke <benjamin.ducke at ufg.uni-kiel.de>
> Date: Wed, 05 Jul 2006 10:20:56 +0200
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation
> 
> I have one request concerning the GRASS configure script:
> would it be possible for configure to write a small one-line
> ASCII file into GISBASE/etc after a successful configuration,
> which contains all the options that the user passed to the
> configure script?
> 
> Having such a file in a standard location would make it
> much easier to compile external modules with exactly the
> same external dependencies as the GRASS system installation.
> 
> Best,
> 
> Benjamin
> 
> Markus Neteler wrote:
>> On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote:
>> ...
>> 
>>> Some modules have problems running on 64bit (maybe that is also
>>> #4725?
>> 
>> 
>> The nviz volume bug was recently introduces, I think. As far
>> as I remember it worked some time ago on 64bit.
>> 
>> https://intevation.de/rt/webrt?serial_num=4725
>> " 
>>   I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode()
>>   and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost.
>> "
>> 
>> ?
>> 
>> 
>>> but it is for sure #4546
>> 
>> 
>> https://intevation.de/rt/webrt?serial_num=4546
>> r.sim.water crashes in simlib/input.c line 403, function grad_check():
>> 
>>  if (cchez[k][l] != 0.) {
>> 
>>    with k=700 and l=0
>> 
>> Not sure why.
>> 
>> 
>> 
>>> and supposedly also r.sun - probably due to uninitialized
>>> variables).
>> 
>> 
>> Right, It crashes in INPUT () at main.c:656
>>               if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] ==
>> UNDEFZ)
>> 
>> Here a Spearfish test script:
>> 
>> ELEV=elevation.dem
>> TMP=$$
>> SLOPE=$TMP.slope
>> ASP=$TMP.aspect
>> r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o
>> r.mapcalc global_shadow.rad=0
>> DAY=055
>> r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \
>>       beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY
>>  
>> 
>> 
>> 
>>> I don't think that this should stop the release.
>> 
>> 
>> I would appreciate if those two bugs would be fixed, but we
>> can backport the fixes later.
>> 
>> 
>>> Also I believe that we should thoroughly test gis.m before release -
>>> we were getting all kinds of error messages but I think that it all
>>> has been fixed by now.
>> 
>> 
>> Yes, gis.m should get a consolidation cycle now.
>> 
>> Markus
>>  
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>> 
>> 
> 
> -- 
> Benjamin Ducke, M.A.
> Archäoinformatik
> (Archaeoinformation Science)
> Institut für Ur- und Frühgeschichte
> (Inst. of Prehistoric and Historic Archaeology)
> Christian-Albrechts-Universität zu Kiel
> Johanna-Mestorf-Straße 2-6
> D 24098 Kiel
> Germany
> 
> Tel.: ++49 (0)431 880-3378 / -3379
> Fax : ++49 (0)431 880-7300
> www.uni-kiel.de/ufg
> 
>