[GRASS-dev] [GRASS GIS] #2845: Build failure with 7.0.3RC1 on Linux

GRASS GIS trac at osgeo.org
Mon Jan 11 12:57:00 PST 2016


#2845: Build failure with 7.0.3RC1 on Linux
-------------------------+-------------------------------------------------
  Reporter:  scimmia     |      Owner:  grass-dev@…
      Type:  defect      |     Status:  new
  Priority:  blocker     |  Milestone:  7.0.4
 Component:  Compiling   |    Version:  unspecified
Resolution:              |   Keywords:  xml, toolboxes, Makefile, svnprop,
                         |  wxGUI, releasing
       CPU:  x86-64      |   Platform:  Linux
-------------------------+-------------------------------------------------

Comment (by glynn):

 Replying to [comment:27 wenzeslaus]:

 > It's hard for me to tell what's right at this point but the `OBJ.*` are
 generated during compilation and ignored by `svn status`, so shouldn't be
 the desired behavior the same for all the generated files. Or should go
 all the generated files to `OBJ.*` dirs?

 That would be nice for various reasons, but isn't always practical.

 At present, if you build with e.g.
 {{{
 make 'OBJDIR=$(HOME)/grass_objdir/$(RELDIR)'
 }}}
 you still end up with the following files being created in the source
 tree:
 {{{
 lib/python/ctypes/ctypesgencore/*.pyc
 locale/scriptstrings/*_to_translate.c

 gui/wxpython/menustrings.py
 gui/wxpython/xml/menudata.xml
 gui/wxpython/xml/module_tree_menudata.xml
 lib/db/sqlp/sqlp.output
 lib/db/sqlp/sqlp.tab.c
 lib/db/sqlp/sqlp.tab.h
 lib/db/sqlp/sqlp.yy.c
 lib/python/script/setup.py.tmp
 man/build_html.pyc
 raster/r.mapcalc/mapcalc.output
 raster/r.mapcalc/mapcalc.tab.c
 raster/r.mapcalc/mapcalc.tab.h
 raster/r.mapcalc/mapcalc.yy.c
 }}}

 If we could get all of those to be created in $(OBJDIR), it would be
 possible to build GRASS from a read-only source tree, or run multiple
 builds in a single source tree without them interfering with each other,
 or clean up simply by "rm -rf"ing $(OBJDIR).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2845#comment:32>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list