On Sat, May 23, 2015 at 11:01 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2015-05-23 10:51 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
If the macro and everything in the GRASS source tree have been
changed, the only issue would be if any out-of-tree code (add-ons or
private
Martin Landa wrote:
I'll let release manager to decide if it is safe to do so and just
backport if it is.
@Glynn: please do you have any opinion?
If the macro and everything in the GRASS source tree have been
changed, the only issue would be if any out-of-tree code (add-ons or
private
Hi,
2015-05-23 10:51 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
If the macro and everything in the GRASS source tree have been
changed, the only issue would be if any out-of-tree code (add-ons or
private code) were using it.
yes, GRASS addon `v.delaunay3d` has this issue. My vote is
On May 22, 2015 5:58 PM, Maris Nartiss maris@gmail.com wrote:
Sorry, no.
I'll let release manager to decide if it is safe to do so
I'm not able to judge this.
and just backport if it is.
If OK I can do that.
Markus
Māris.
2015-05-21 13:19 GMT+03:00 Martin Landa
Sorry, no.
I'll let release manager to decide if it is safe to do so and just
backport if it is.
Māris.
2015-05-21 13:19 GMT+03:00 Martin Landa landa.mar...@gmail.com:
Hi,
2015-05-21 11:26 GMT+02:00 Maris Nartiss maris@gmail.com:
Done in r65297 and r65298.
are you planning backport
2015-05-22 17:58 GMT+02:00 Maris Nartiss maris@gmail.com:
Sorry, no.
I'll let release manager to decide if it is safe to do so and just
backport if it is.
@Glynn: please do you have any opinion?
Thanks, Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
Done in r65297 and r65298.
2015-05-20 15:47 GMT+03:00 Glynn Clements gl...@gclements.plus.com:
Maris Nartiss wrote:
As it is used by GRASS internally only, a simple sed (+ documentation
change) should be enough. The only question remains - change to what?
n_()?
--
Glynn Clements
Hi,
2015-05-21 11:26 GMT+02:00 Maris Nartiss maris@gmail.com:
Done in r65297 and r65298.
are you planning backport to relbr70? Thanks, Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev
2015-05-19 11:18 GMT+03:00 Martin Landa landa.mar...@gmail.com:
It's GRASS' fault for using a reserved name (_n() was added in r59156,
r59189, now 137 occurrences in 52 files), and particularly for using
it as a macro.
Any suggestion to solve this issue?
As it is used by GRASS internally
Maris Nartiss wrote:
As it is used by GRASS internally only, a simple sed (+ documentation
change) should be enough. The only question remains - change to what?
n_()?
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
Hi,
2015-05-18 14:34 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
Boost isn't using any _n() macro; that's the C++ syntax for
initialising a member variable named _n upon construction.
At least, it isn't trying to use a macro. The fact that there happens
to be a macro called _n() in
Martin Landa wrote:
recently I got problem compiling GRASS module against CGAL library.
The source of problem is duplicated definition of _n() macro.
In file included from /usr/include/boost/random.hpp:37:0,
from /usr/local/include/CGAL/spatial_sort.h:31,
12 matches
Mail list logo
