[GRASS-dev] build errors in trunk with make -j 4

Glynn Clements glynn at gclements.plus.com
Wed Jan 13 19:18:03 EST 2010


Markus Neteler wrote:

> > in trunk I get errors detected building wxpython and v.kridge, but if I
> > cd into their dirs and re-run make they build ok.
> 
> (not using parallel build)
> This problem currently breaks the creation of the GRASS 7 binary snapshot
> on the Web server:
> 
> ...
> -------------------------
> Started compilation: Wed Jan 13 13:35:27 PST 2010
> --
> Errors in:
> /home/neteler/grass7_svn_head_bin_snapshot/trunk/scripts/v.krige
> --
> ...
> --
> Finished compilation: Wed Jan 13 13:59:38 PST 2010
> make: *** [default] Error 1
> ERROR: compilation error.
> 
> I hope it can be solved since the binary GRASS 7 isn't packaged
> at this point.

This issue should already be resolved by r40303.

The other issue (needing to use $GRASS_PYTHON for actual usage) is
still outstanding.

> Glynn suggested to change the compile order of "gui" and "scripts"
> as far as I understand.

No; I merely commented that having something in scripts try to use
wxGUI modules would fail due to the order in which they were built.

This should no longer be an issue, and even if it was, changing the
order is the wrong solution. We shouldn't be relying upon the order in
which the subdirectories are built any more than is strictly
necessary.

The only ordering which should be required is:

demolocation + tools + include > lib > [everything else] > locale + man > macosx

The ones at the beginning inherently form the foundation on which the
rest of GRASS is built. The ones at the end are based upon GRASS as a
whole (locale needs to extract translatable strings from C files, some
of which need are generated from non-C files, man builds global and
category indices, macosx creates a GRASS package).

The rest should ideally be able to be built in any order. E.g. I
recently added tools/g.echo[1] to convert MSys pathnames to Windows
pathnames during the build process (previously, g.dirseps was being
used, but that doesn't work when you're creating a manpage for a
subdirectory of lib as g.dirseps hasn't been built yet, and it can't
be built before lib/gis).

[1] g.echo just echoes its argument, but MSys automatically converts
MSys paths to Windows paths when running anything which isn't part of
MSys.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list