[GRASS-dev] GRASS 6.3.0

Hi all,

we are a little bit late with releasing 6.3.0, looking at [1,2] I
don't see any (really) blocker issue (maybe vdigit linking problem,
but this can wait for 6.3.1 I guess). The wxPython seems to work on
Windows (basically), needs a lot fixes and some speed-up optimization
(especially for GUI module dialogs which are generated on the fly) --
issues for 6.4.

BTW I do not fully understood if there was consensus to create
directly releasebranch_6_4 in SVN or first to create develbranch_6 and
then releasebranch_6_4 based on develbranch_6. In any case it would be
great to start grass7 development finally:-)

Regards, Martin

[1] http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=6.3.0
[2] http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

Martin Landa wrote:

Hi all,

we are a little bit late with releasing 6.3.0, looking at [1,2] I
don't see any (really) blocker issue (maybe vdigit linking problem,
but this can wait for 6.3.1 I guess). The wxPython seems to work on
Windows (basically), needs a lot fixes and some speed-up optimization
(especially for GUI module dialogs which are generated on the fly) --
issues for 6.4.

With a fresh checkout from SVN done about 1h ago, I can confirm that
the wxPython GUI works on native Win32 using MSYS/MinGW (see attached
screenshot). GREAT STUFF!

I have not followed the v.digit development, but I can get a digitizing
toolbar to come up in the Map window (see screenshot). Only problem is:
the drop-down box for layer selection is empty, so I can't start editing
on any layer!

If I start v.digit.exe with a map name from the command line, it simply
crashes.

Cheers,

Benjamin

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel.: ++44 (0)1865 263 800
benjamin.ducke@oxfordarch.co.uk

(attachments)

grass-wxgui-win32.jpg

Hi,

2008/3/14, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:

I have not followed the v.digit development, but I can get a digitizing
toolbar to come up in the Map window (see screenshot). Only problem is:
the drop-down box for layer selection is empty, so I can't start editing
on any layer!

If I start v.digit.exe with a map name from the command line, it simply
crashes.

v.digit.exe refers to 'vector/v.digit' -- TCL/TK-fashioned digitizer.
To enable digitizer in wxPython GUI you need to compile
'gui/wxpython/vdigit' -> grass6_wxvdigit Python extension. There is
still problem with direct linking to _gdi_.so Python module, undefined
symbols should be possible to load on runtime. It needs to be fixed
for Unix-based system first, then I will look at winGRASS port too.
For now no wxPython-based digitizer under Windows.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

Martin Landa wrote:

we are a little bit late with releasing 6.3.0,

no big hurry.

looking at [1,2] I don't see any (really) blocker issue (maybe vdigit
linking problem, but this can wait for 6.3.1 I guess).

Before 6.3.0 I would like to finish making r.tileset "echo -n" portable
(trac bug #81) and then backport r.in.wms fixes, and also see if we can
fix the GIS.m off-by-one fill/boundary rendering (trac bug #72)

http://trac.osgeo.org/grass/ticket/81
http://trac.osgeo.org/grass/ticket/72

As r.in.wms has been reported to work on Mac 10.5, I infer that the
#!/bin/bash used by r.tileset makes it use bash's internal echo (which
supports echo -n) instead of a system BSD /bin/echo which does not. (??)
Even if that is so, it's probably a good idea to fix anyway. The eval
within a function within another function and array quoting makes my head
hurt, so for clarity's sake I am leaning towards going with Paul's
suggestion of using GRASS's own $GISBASE/etc/echo there and keeping the
-n, versus Glynn's patch which I find hard to review beyond trial & error
tests which I can't properly do without OSX 10.5, which I don't have.

Not having to resort to using our own echo.c is preferable, but for the
pending 6.3.0 release this seems to me the less worrisome solution.

There are a lot of other script fixes not backported to 6.3.0, mostly
bulk quoting of variables. I didn't backport them as I have not
individually tested the changes and so don't guarantee they are no
introduced typos. These will help with the spaces in pathnames problems,
which are mostly a MS Windows phenomenon. I did not systematically quote
everything, so it is almost certain that there will be more unquoted path
and file names. These fixes might be nice to get out to MS Windows users
in a 6.3.1 after more testing in SVN/trunk. Probably easier to cut a new
6_3_1 branch from the main grass6 line than to bother backporting things
to 6.3.0's branch.
(unless a major bug is discovered and we want to release a quick 6.3.1)

Is there a need for one last 6.3.0rc6 before release since all the new wx
backport changes?

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

On Mar 14, 2008, at 10:28 PM, Hamish wrote:

As r.in.wms has been reported to work on Mac 10.5, I infer that the
#!/bin/bash used by r.tileset makes it use bash's internal echo (which
supports echo -n) instead of a system BSD /bin/echo which does not. (??)
Even if that is so, it's probably a good idea to fix anyway. The eval
within a function within another function and array quoting makes my head
hurt, so for clarity's sake I am leaning towards going with Paul's
suggestion of using GRASS's own $GISBASE/etc/echo there and keeping the
-n, versus Glynn's patch which I find hard to review beyond trial & error
tests which I can't properly do without OSX 10.5, which I don't have.

I was just comparing the 10.4 and 10.5 man pages for echo and bash - ALL have the -n flag. So really, it must be broken in 10.5's bash. Or not? Just to verify, on its own:

echo -n "asdf"
/bin/echo -n "asdf"

both suppress the newline. Strange. Was it reported to not work in r.tileset, or was it relation to another command?

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

The equator is so long, it could encircle the earth completely once.

William Kyngesburye wrote:

> As r.in.wms has been reported to work on Mac 10.5, I infer that the
> #!/bin/bash used by r.tileset makes it use bash's internal echo (which
> supports echo -n) instead of a system BSD /bin/echo which does not.
> (??)
> Even if that is so, it's probably a good idea to fix anyway. The eval
> within a function within another function and array quoting makes my
> head
> hurt, so for clarity's sake I am leaning towards going with Paul's
> suggestion of using GRASS's own $GISBASE/etc/echo there and keeping
> the
> -n, versus Glynn's patch which I find hard to review beyond trial &
> error
> tests which I can't properly do without OSX 10.5, which I don't have.
>
I was just comparing the 10.4 and 10.5 man pages for echo and bash -
ALL have the -n flag. So really, it must be broken in 10.5's bash.
Or not? Just to verify, on its own:

echo -n "asdf"
/bin/echo -n "asdf"

both suppress the newline. Strange. Was it reported to not work in
r.tileset, or was it relation to another command?

r.tileset is totally dependent upon bash, so the "echo -n" issue
doesn't apply there.

Scripts which use #!/bin/sh have to allow for the possibility that
"echo" follows POSIX, which doesn't support -n (or, for that matter,
any switches at all).

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

Hi,

2008/3/15, Hamish <hamish_b@yahoo.com>:

Martin Landa wrote:
> we are a little bit late with releasing 6.3.0,

Hamish:

no big hurry.

well, just comparing rc5-rc1 --- almost 5 months (to be honest,
postponed mainly because wxGUI backport). Anyway I would personally
prefer *smaller* release intervals (more releases in the result). Just
to illustrate

6.0.0 20050310
~ 1y5m
6.1.0 20060811
~ 2m
6.2.0 20061031
~ 1y5m
6.3.0 2008???
6.4.0 2008?
7.0.0 ? (development not started)

> looking at [1,2] I don't see any (really) blocker issue (maybe vdigit
> linking problem, but this can wait for 6.3.1 I guess).

Hamish:

Before 6.3.0 I would like to finish making r.tileset "echo -n" portable
(trac bug #81) and then backport r.in.wms fixes, and also see if we can
fix the GIS.m off-by-one fill/boundary rendering (trac bug #72)

http://trac.osgeo.org/grass/ticket/81
http://trac.osgeo.org/grass/ticket/72

As r.in.wms has been reported to work on Mac 10.5, I infer that the
#!/bin/bash used by r.tileset makes it use bash's internal echo (which
supports echo -n) instead of a system BSD /bin/echo which does not. (??)
Even if that is so, it's probably a good idea to fix anyway. The eval
within a function within another function and array quoting makes my head
hurt, so for clarity's sake I am leaning towards going with Paul's
suggestion of using GRASS's own $GISBASE/etc/echo there and keeping the
-n, versus Glynn's patch which I find hard to review beyond trial & error
tests which I can't properly do without OSX 10.5, which I don't have.

Not having to resort to using our own echo.c is preferable, but for the
pending 6.3.0 release this seems to me the less worrisome solution.

OK, I cannot judge it, anyway could be maybe fixed for 6.3.1 or 6.4.0.

There are a lot of other script fixes not backported to 6.3.0, mostly
bulk quoting of variables. I didn't backport them as I have not
individually tested the changes and so don't guarantee they are no
introduced typos. These will help with the spaces in pathnames problems,
which are mostly a MS Windows phenomenon. I did not systematically quote
everything, so it is almost certain that there will be more unquoted path
and file names. These fixes might be nice to get out to MS Windows users
in a 6.3.1 after more testing in SVN/trunk. Probably easier to cut a new
6_3_1 branch from the main grass6 line than to bother backporting things
to 6.3.0's branch.

Hm, creating branch for 6.3.1 seems to be a bit complicated to me. I
would prefer releasing 6.3.0, creating branch for 6_4 (trunk for 7.x).
Releasebranch_6_3 used for 6.3.1 (after tagging 6.3.0) as usually.

(unless a major bug is discovered and we want to release a quick 6.3.1)

Is there a need for one last 6.3.0rc6 before release since all the new wx
backport changes?

Maybe yes. I don't know maybe this kind of decisions should be done
through PSC or at least by release manager.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

Martin Landa wrote:

> There are a lot of other script fixes not backported to 6.3.0, mostly
> bulk quoting of variables. I didn't backport them as I have not
> individually tested the changes and so don't guarantee they are no
> introduced typos. These will help with the spaces in pathnames problems,
> which are mostly a MS Windows phenomenon. I did not systematically quote
> everything, so it is almost certain that there will be more unquoted path
> and file names. These fixes might be nice to get out to MS Windows users
> in a 6.3.1 after more testing in SVN/trunk. Probably easier to cut a new
> 6_3_1 branch from the main grass6 line than to bother backporting things
> to 6.3.0's branch.

Hm, creating branch for 6.3.1 seems to be a bit complicated to me. I
would prefer releasing 6.3.0, creating branch for 6_4 (trunk for 7.x).
Releasebranch_6_3 used for 6.3.1 (after tagging 6.3.0) as usually.

I would suggest keeping with releasebranch_6_3 for 6.3.1 (if it
occurs).

If you were planning on a release which (roughly) corresponds to the
current trunk, that should probably be 6.4.0. The differences between
6.3.1 should consist only of changes which have been vetted and deemed
necessary.

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

Well given all the troubles reported recently we may as well need RC6 unless you and Markus have a good sense that these troubles are only in the svn version and not backported to the release.

I would love to get GRASS6.3 out soon - people are still downloading 6.2 as the stable GRASS and GRASS6.3 is just so much better. And I need to get some stable, official release installed in some labs and don't want to use 6.2

thanks a lot, Helena

On Mar 17, 2008, at 6:54 PM, Martin Landa wrote:

Hi,

2008/3/15, Hamish <hamish_b@yahoo.com>:

Martin Landa wrote:

we are a little bit late with releasing 6.3.0,

Hamish:

no big hurry.

well, just comparing rc5-rc1 --- almost 5 months (to be honest,
postponed mainly because wxGUI backport). Anyway I would personally
prefer *smaller* release intervals (more releases in the result). Just
to illustrate

6.0.0 20050310
~ 1y5m
6.1.0 20060811
~ 2m
6.2.0 20061031
~ 1y5m
6.3.0 2008???
6.4.0 2008?
7.0.0 ? (development not started)

looking at [1,2] I don't see any (really) blocker issue (maybe vdigit
linking problem, but this can wait for 6.3.1 I guess).

Hamish:

Before 6.3.0 I would like to finish making r.tileset "echo -n" portable
(trac bug #81) and then backport r.in.wms fixes, and also see if we can
fix the GIS.m off-by-one fill/boundary rendering (trac bug #72)

http://trac.osgeo.org/grass/ticket/81
http://trac.osgeo.org/grass/ticket/72

As r.in.wms has been reported to work on Mac 10.5, I infer that the
#!/bin/bash used by r.tileset makes it use bash's internal echo (which
supports echo -n) instead of a system BSD /bin/echo which does not. (??)
Even if that is so, it's probably a good idea to fix anyway. The eval
within a function within another function and array quoting makes my head
hurt, so for clarity's sake I am leaning towards going with Paul's
suggestion of using GRASS's own $GISBASE/etc/echo there and keeping the
-n, versus Glynn's patch which I find hard to review beyond trial & error
tests which I can't properly do without OSX 10.5, which I don't have.

Not having to resort to using our own echo.c is preferable, but for the
pending 6.3.0 release this seems to me the less worrisome solution.

OK, I cannot judge it, anyway could be maybe fixed for 6.3.1 or 6.4.0.

There are a lot of other script fixes not backported to 6.3.0, mostly
bulk quoting of variables. I didn't backport them as I have not
individually tested the changes and so don't guarantee they are no
introduced typos. These will help with the spaces in pathnames problems,
which are mostly a MS Windows phenomenon. I did not systematically quote
everything, so it is almost certain that there will be more unquoted path
and file names. These fixes might be nice to get out to MS Windows users
in a 6.3.1 after more testing in SVN/trunk. Probably easier to cut a new
6_3_1 branch from the main grass6 line than to bother backporting things
to 6.3.0's branch.

Hm, creating branch for 6.3.1 seems to be a bit complicated to me. I
would prefer releasing 6.3.0, creating branch for 6_4 (trunk for 7.x).
Releasebranch_6_3 used for 6.3.1 (after tagging 6.3.0) as usually.

(unless a major bug is discovered and we want to release a quick 6.3.1)

Is there a need for one last 6.3.0rc6 before release since all the new wx
backport changes?

Maybe yes. I don't know maybe this kind of decisions should be done
through PSC or at least by release manager.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Mon, Mar 17, 2008 at 11:54 PM, Martin Landa <landa.martin@gmail.com> wrote:

2008/3/15, Hamish <hamish_b@yahoo.com>:

...

> Is there a need for one last 6.3.0rc6 before release since all the new wx
> backport changes?

Maybe yes. I don't know maybe this kind of decisions should be done
through PSC or at least by release manager.

I think that we should go for 6.3.0RC6 asap.

Proposal: tag 6.3.0RC6 tomorrow, 19 March 2008.
I can do that as before.

Markus

On Tue, Mar 18, 2008 at 1:52 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Martin Landa wrote:

> > There are a lot of other script fixes not backported to 6.3.0, mostly
> > bulk quoting of variables. I didn't backport them as I have not
> > individually tested the changes and so don't guarantee they are no
> > introduced typos. These will help with the spaces in pathnames problems,
> > which are mostly a MS Windows phenomenon. I did not systematically quote
> > everything, so it is almost certain that there will be more unquoted path
> > and file names. These fixes might be nice to get out to MS Windows users
> > in a 6.3.1 after more testing in SVN/trunk. Probably easier to cut a new
> > 6_3_1 branch from the main grass6 line than to bother backporting things
> > to 6.3.0's branch.
>
> Hm, creating branch for 6.3.1 seems to be a bit complicated to me. I
> would prefer releasing 6.3.0, creating branch for 6_4 (trunk for 7.x).
> Releasebranch_6_3 used for 6.3.1 (after tagging 6.3.0) as usually.

I would suggest keeping with releasebranch_6_3 for 6.3.1 (if it
occurs).

I agree. That's the most cost effective way.

If you were planning on a release which (roughly) corresponds to the
current trunk, that should probably be 6.4.0. The differences between
6.3.1 should consist only of changes which have been vetted and deemed
necessary.

This corresponds to the graph in
http://trac.osgeo.org/grass/wiki/Grass7Planning

Proposal

End of this month:
* Get out 6.3.0final (releasebranch_6_3)
* Immediately branch off 6.4.0 to releasebranch_6_4
* rename trunk to 7.0.svn

Markus

Hamish:

> > Is there a need for one last 6.3.0rc6 before release since all
> > the new wx backport changes?

Martin:

> Maybe yes. I don't know maybe this kind of decisions should be done
> through PSC or at least by release manager.

The PSC is the formal venue for dealing with meta-issues, like legal
stuff. Technical decisions are explicitly the domain of the developers.
see rfc/RFC1_PSC.dox

If code is ready to release or not seems to me to clearly be a technical
issue (or at least for a OSS project it should be), and thus it is up to
the consensus of the grass-dev list to decide, with the release manager
acting as the chair.

I think that we should go for 6.3.0RC6 asap.

Proposal: tag 6.3.0RC6 tomorrow, 19 March 2008.
I can do that as before.

fine by me.

6.3.0 wishlist:
  http://trac.osgeo.org/grass/ticket/72
  gis.m: boundary rendering is off by one pixel

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Hi,

2008/3/19, Markus Neteler <neteler@osgeo.org>:
[snip]

I think that we should go for 6.3.0RC6 asap.

Proposal: tag 6.3.0RC6 tomorrow, 19 March 2008.
I can do that as before.

OK, today I will backport the last changes in wxGUI and test it out on
Linux and Windows. You mean tomorrow, 20th March?

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

On Wed, Mar 19, 2008 at 3:02 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2008/3/19, Markus Neteler <neteler@osgeo.org>:
[snip]

> I think that we should go for 6.3.0RC6 asap.
>
> Proposal: tag 6.3.0RC6 tomorrow, 19 March 2008.
> I can do that as before.

OK, today I will backport the last changes in wxGUI and test it out on
Linux and Windows.

Thanks!

You mean tomorrow, 20th March?

Yes sure, sorry.

Markus

Hi all,

I’m very busy at the moment (I’ll have important university exams on 1st and 2nd April) but I’ll try do my best and prepare RC6 Windows package as soon as possible.

Marco


Da: grass-dev-bounces@lists.osgeo.org per conto di Markus Neteler
Inviato: mer 19/03/2008 15.12
A: Martin Landa
Cc: GRASS developers list
Oggetto: Re: [GRASS-dev] GRASS 6.3.0

On Wed, Mar 19, 2008 at 3:02 PM, Martin Landa landa.martin@gmail.com wrote:

Hi,

2008/3/19, Markus Neteler neteler@osgeo.org:
[snip]

I think that we should go for 6.3.0RC6 asap.

Proposal: tag 6.3.0RC6 tomorrow, 19 March 2008.
I can do that as before.

OK, today I will backport the last changes in wxGUI and test it out on
Linux and Windows.

Thanks!

You mean tomorrow, 20th March?

Yes sure, sorry.

Markus


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Hi,

2008/3/19, Markus Neteler <neteler@osgeo.org>:

> > I think that we should go for 6.3.0RC6 asap.
> >
> > Proposal: tag 6.3.0RC6 tomorrow, 19 March 2008.
> > I can do that as before.
>
> OK, today I will backport the last changes in wxGUI and test it out on
> Linux and Windows.

I think we can release RC6 tomorrow. BTW I have slightly tested wxGUI
(GNU/Linux and MS Windows), anyway it is experimental, added after
RC4, not blocker for 6.3.0. Looking forward 6.3.0/branch for 6.4/trunk
for 7.x development:-) Regards, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

On Thu, Mar 20, 2008 at 12:11 AM, Martin Landa <landa.martin@gmail.com> wrote:

2008/3/19, Markus Neteler <neteler@osgeo.org>:

> > > I think that we should go for 6.3.0RC6 asap.
> > >
> > > Proposal: tag 6.3.0RC6 tomorrow, 19 March 2008.
> > > I can do that as before.
> >
> > OK, today I will backport the last changes in wxGUI and test it out on
> > Linux and Windows.

I think we can release RC6 tomorrow.

I have received an important LatLong fix for r.sun/r.sun2 from
Thomas Huld (JRC). I have submitted it to r.sun2 already (Addons)
and await a feedback for the r.sun backport and test.

BTW I have slightly tested wxGUI
(GNU/Linux and MS Windows), anyway it is experimental, added after
RC4, not blocker for 6.3.0.

I found that
gui/wxpython/vdigit/
fails on
make -j4

Something needs to be serialized there. no showstopper of course!

Looking forward 6.3.0/branch for 6.4/trunk for 7.x development

me too :slight_smile:

Markus

Markus Neteler wrote:

I found that
gui/wxpython/vdigit/
fails on
make -j4

Something needs to be serialized there.

Fixed in SVN:

  -default: $(SHLIB) install_vdigit
  +default: install_vdigit
   
  -install_vdigit:
  +install_vdigit: $(SHLIB)
     $(INSTALL_DATA) _grass6_wxvdigit.so $(ETCDIR)/vdigit/
     $(INSTALL_DATA) grass6_wxvdigit.py $(ETCDIR)/vdigit/

Note to anyone writing Makefiles: a dependency line such as:

  target: source1 source2

states that source1 and source2 must be built before running the
commands for the rule. It does not require that source1 and source2
are built in that order. Although that will typically be the case for
a single-threaded build, a parallel build will attempt to build
source1 and source2 concurrently.

If source1 needs to be built before source2, this must be expressed through
dependencies, e.g.:

  target: source2

  source2: source1

Another problem with vdigit: the C++ wrapper file grass6_wxvdigit_wrap.cpp
is *not* a source file (it is built from the .i files using SWIG), and
should not be stored in the SVN repository. It should be generated by SWIG
during the build process.

However, this also lacks correct dependency information. First,
grass6_wxvdigit.i doesn't list the various .i files as dependencies,
so it won't be re-built if one of them is modified. Secondly, the rule
which generates grass6_wxvdigit_wrap.cpp doesn't actually have that
file as a target, so it won't get run if the file needs to be
re-built.

Finally, while writing this, I've just noticed that gui/wxpython/Makefile
has:

  default: install_scripts parsubdirs

which will run both targets concurrently. This is theoretically
problematic, as vdigit/Makefile assumes that the etc/wxpython/vdigit
directory has already been created. In practice, you'll get away with it,
as the chances of compiling the entire vdigit module before a mkdir
command has completed are essentially nil.

However, to avoid setting a bad example which may cause actual problems if
someone follows it, I've changed the rule to:

  default: install_scripts
    $(MAKE) parsubdirs

Note that parsubdirs is a "phony" target, so the following *won't* work:

  default: parsubdirs

  parsubdirs: install_scripts

Okay, I was wrong about the "finally" above; I've also changed:

  - $(INSTALL_DATA) _grass6_wxvdigit.so $(ETCDIR)/vdigit/
  + $(INSTALL_DATA) $(SHLIB) $(ETCDIR)/vdigit/

as the suffix won't be ".so" on all platforms.

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

Thanks Glynn, I backported your fixes to releasebranch_6_3.

Martin

2008/3/21, Glynn Clements <glynn@gclements.plus.com>:

Markus Neteler wrote:

> I found that
> gui/wxpython/vdigit/
> fails on
> make -j4
>
> Something needs to be serialized there.

Fixed in SVN:

        -default: $(SHLIB) install_vdigit
        +default: install_vdigit

        -install_vdigit:
        +install_vdigit: $(SHLIB)
                $(INSTALL_DATA) _grass6_wxvdigit.so $(ETCDIR)/vdigit/
                $(INSTALL_DATA) grass6_wxvdigit.py $(ETCDIR)/vdigit/

Note to anyone writing Makefiles: a dependency line such as:

        target: source1 source2

states that source1 and source2 must be built before running the
commands for the rule. It does not require that source1 and source2
are built in that order. Although that will typically be the case for
a single-threaded build, a parallel build will attempt to build
source1 and source2 concurrently.

If source1 needs to be built before source2, this must be expressed through
dependencies, e.g.:

        target: source2

        source2: source1

Another problem with vdigit: the C++ wrapper file grass6_wxvdigit_wrap.cpp
is *not* a source file (it is built from the .i files using SWIG), and
should not be stored in the SVN repository. It should be generated by SWIG
during the build process.

However, this also lacks correct dependency information. First,
grass6_wxvdigit.i doesn't list the various .i files as dependencies,
so it won't be re-built if one of them is modified. Secondly, the rule
which generates grass6_wxvdigit_wrap.cpp doesn't actually have that
file as a target, so it won't get run if the file needs to be
re-built.

Finally, while writing this, I've just noticed that gui/wxpython/Makefile
has:

        default: install_scripts parsubdirs

which will run both targets concurrently. This is theoretically
problematic, as vdigit/Makefile assumes that the etc/wxpython/vdigit
directory has already been created. In practice, you'll get away with it,
as the chances of compiling the entire vdigit module before a mkdir
command has completed are essentially nil.

However, to avoid setting a bad example which may cause actual problems if
someone follows it, I've changed the rule to:

        default: install_scripts
                $(MAKE) parsubdirs

Note that parsubdirs is a "phony" target, so the following *won't* work:

        default: parsubdirs

        parsubdirs: install_scripts

Okay, I was wrong about the "finally" above; I've also changed:

        - $(INSTALL_DATA) _grass6_wxvdigit.so $(ETCDIR)/vdigit/
        + $(INSTALL_DATA) $(SHLIB) $(ETCDIR)/vdigit/

as the suffix won't be ".so" on all platforms.

--

Glynn Clements <glynn@gclements.plus.com>

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

On Mar 21, 2008, at 1:29 AM, Glynn Clements wrote:

Another problem with vdigit: the C++ wrapper file grass6_wxvdigit_wrap.cpp
is *not* a source file (it is built from the .i files using SWIG), and
should not be stored in the SVN repository. It should be generated by SWIG
during the build process.

Correct or not, I'vee seen it as a convention in many projects to include pre-SWIG'd sources (ie Mapserver, Qgis, GDAL). While developers may be OK with adding SWIG to their toolbox (though I haven't installed it on my new Mac because I don't need it any more), users who build from source may not have SWIG, and may not want to install something that's not used at runtime but only for compilation.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin