Package Details: grass 8.4.0-1

Git Clone URL: https://aur.archlinux.org/grass.git (read-only, click to copy)
Package Base: grass
Description: Geospatial data management and analysis, image processing, graphics/maps production, spatial modeling and visualization
Upstream URL: http://grass.osgeo.org/
Keywords: analysis GIS remote sensing spatial
Licenses: GPL
Submitter: Scimmia
Maintainer: kikislater
Last Packager: kikislater
Votes: 38
Popularity: 0.000000
First Submitted: 2015-09-06 15:10 (UTC)
Last Updated: 2024-07-30 06:17 (UTC)

Latest Comments

« First ‹ Previous 1 .. 11 12 13 14 15 16

czk commented on 2015-10-03 23:56 (UTC)

> I'm not dropping the user's CPPFLAGS. I'm missing something then. What does the `unset CPPFLAGS' do? > --with-cxx is the default I missed --with-cxx being enabled by default in G7 these days. > for things of limited value Parallel r.mapcalc is not something to give up on too easily. > aren't those addons called with "$GRASS_PYTHON" instead of just run directly? Hmm, I don't know, yet. Are you sure that it works this way?

Scimmia commented on 2015-10-03 23:18 (UTC)

--with-cxx is the default, so I'm not touching that. I had thought about --with-pthread but hadn't looked into it. As for the others, I'm reluctant to pull in too many deps, especially from the AUR, for things of limited value. I'll look into netcdf and nls more. The main goal here was to get this all working again with default settings. We can look into things from there.

czk commented on 2015-10-03 22:59 (UTC)

Please bring back the following: --with-nls enables interface translations, --with-cxx enables building some cool modules written in C++: r.terraflow, i.attcor, r.viewshed, --with-pthread enables parallel processing boost for r.mapcalc, the core GRASS raster module, --with-netcdf: required for r3.out.netcdf, and maybe for old NetCDF format support in r.out.bin (not sure about the latter), --with-liblas: I will ask you to bring it back when I upload liblas to new AUR. It is required for r.in.lidar and v.in.lidar. Please mind that some great GRASS addons depend on the missing modules, too.

Scimmia commented on 2015-10-03 22:25 (UTC) (edited on 2015-10-03 22:52 (UTC) by Scimmia)

Read the PKGBUILD again, I'm not dropping the user's CPPFLAGS. As for the advantage of using sed, it's an actual fix instead of a hack. Correct me if I'm wrong, but aren't those addons called with "$GRASS_PYTHON" instead of just run directly? If so, the shebang won't really matter.

czk commented on 2015-10-03 21:40 (UTC)

What is the advantage of: sed -i 's/\(env \|\/usr\/bin\/\)python$/&2/' $(find . -name "*.py") over: ln -sf "`which python2`" "${pkgdir}/opt/${pkgname}/bin/python" ? I thought that linking `python2' as `python' in GRASS $GISBASE is better, as it does not require each *future* python script (eg. addons installed with g.extension) to be patched. Or have you maybe identified some issues with my approach that you decided to drop it?

czk commented on 2015-10-03 21:25 (UTC) (edited on 2015-10-03 21:41 (UTC) by czk)

Doug, I think that dropping all user's CPPFLAGS is not right. A user can set his CPPFLAGS in /etc/makepkg.conf as he likes them, and will want them to be honored in a makepg build. GRASS 7 can't (or couldn't? I haven't tried building it for a while) cope with -D_FORTIFY_SOURCE=2, but that doesn't mean that all user's CPPFLAGS should be dropped.

« First ‹ Previous 1 .. 11 12 13 14 15 16