[GRASS5] nviz / tcl compile problem

M_Lennert · February 13, 2002, 10:22am

Hello,

I have trouble compiling nviz. Here's the message just before the compiler stops:

****snip*****
-I/home/mlennert/SRC/grass/src/include -O3 -mcpu=pentium -Wall -I/usr/X11R6/include -I/usr/include/tcl8.2 -I/usr/include/tcl8.2 -
I/home/mlennert/SRC/grass/src/libes/ogsf -D_NO_PROTO -D__STDC__ -I/usr/include/postgresql -c togl.c -o OBJ.i586-pc-linux-gnu/togl.o
In file included from togl.c:146:
tkInt8.2.3.h:36: conflicting types for `Tk_PostscriptInfo'
/usr/include/tcl8.2/tk.h:116: previous declaration of `Tk_PostscriptInfo'
togl.c: In function `Togl_Cmd':
togl.c:1088: warning: `main' is usually a function
make[1]: *** [OBJ.i586-pc-linux-gnu/togl.o] Error 1
make[1]: Leaving directory `/home/mlennert/SRC/grass/src.contrib/GMSL/NVIZ2.2/src'
make: *** [nvwish] Error 2
*****snip*****

It sounds like a problem linked to the tcl versions (as you can see I have 8.2)

Could someone help me with this ?

Moritz

Markus_Neteler1 · February 13, 2002, 10:32am

On Wed, Feb 13, 2002 at 10:22:44AM +0000, M Lennert wrote:

Hello,

I have trouble compiling nviz. Here's the message just before the compiler stops:

****snip*****
-I/home/mlennert/SRC/grass/src/include -O3 -mcpu=pentium -Wall -I/usr/X11R6/include -I/usr/include/tcl8.2 -I/usr/include/tcl8.2 -
I/home/mlennert/SRC/grass/src/libes/ogsf -D_NO_PROTO -D__STDC__ -I/usr/include/postgresql -c togl.c -o OBJ.i586-pc-linux-gnu/togl.o
In file included from togl.c:146:
tkInt8.2.3.h:36: conflicting types for `Tk_PostscriptInfo'
/usr/include/tcl8.2/tk.h:116: previous declaration of `Tk_PostscriptInfo'
togl.c: In function `Togl_Cmd':
togl.c:1088: warning: `main' is usually a function
make[1]: *** [OBJ.i586-pc-linux-gnu/togl.o] Error 1
make[1]: Leaving directory `/home/mlennert/SRC/grass/src.contrib/GMSL/NVIZ2.2/src'
make: *** [nvwish] Error 2
*****snip*****

It sounds like a problem linked to the tcl versions (as you can see I have 8.2)

Hi,

a few days ago I have added
src.contrib/GMSL/NVIZ2.2/src/tkInt8.2.3.h etc.
to the source code:

2002-02-06 15:43 markus

        * tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h,
        tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h:
        added tkIntDecls8.2.3.h tkIntDecls8.1.1.h to fix Irix compile
        problem

obviously it's less easy. This include stuff of Tcl/TK is really
a mess in general. Do we have to conditionalize the function in
tkInt8.2.3.h?

Moritz: try to comment line 36 in tkInt8.2.3.h.

Markus

M_Lennert · February 13, 2002, 10:42am

On 13 Feb 02, at 11:32, Markus Neteler wrote:

On Wed, Feb 13, 2002 at 10:22:44AM +0000, M Lennert wrote:
> Hello,
>
> I have trouble compiling nviz. Here's the message just before the compiler stops:
>
> ****snip*****
> -I/home/mlennert/SRC/grass/src/include -O3 -mcpu=pentium -Wall -I/usr/X11R6/include -I/usr/include/tcl8.2 -I/usr/include/tcl8.2 -
> I/home/mlennert/SRC/grass/src/libes/ogsf -D_NO_PROTO -D__STDC__ -I/usr/include/postgresql -c togl.c -o OBJ.i586-pc-linux-gnu/togl.o
> In file included from togl.c:146:
> tkInt8.2.3.h:36: conflicting types for `Tk_PostscriptInfo'
> /usr/include/tcl8.2/tk.h:116: previous declaration of `Tk_PostscriptInfo'
> togl.c: In function `Togl_Cmd':
> togl.c:1088: warning: `main' is usually a function
> make[1]: *** [OBJ.i586-pc-linux-gnu/togl.o] Error 1
> make[1]: Leaving directory `/home/mlennert/SRC/grass/src.contrib/GMSL/NVIZ2.2/src'
> make: *** [nvwish] Error 2
> *****snip*****
>
> It sounds like a problem linked to the tcl versions (as you can see I have 8.2)

Hi,

a few days ago I have added
src.contrib/GMSL/NVIZ2.2/src/tkInt8.2.3.h etc.
to the source code:

2002-02-06 15:43 markus

        * tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h,
        tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h:
        added tkIntDecls8.2.3.h tkIntDecls8.1.1.h to fix Irix compile
        problem

As far as I could tell this change is already in the Feb 8 snapshot, so that did not solve the problem.

obviously it's less easy. This include stuff of Tcl/TK is really
a mess in general. Do we have to conditionalize the function in
tkInt8.2.3.h?

As a sidenote to that: the configure script for grass51 finds my tcl includes without a problem, but for grass5 I have to give the location (/usr/include/tcl8.2) explicitly.

> Moritz: try to comment line 36 in tkInt8.2.3.h.

I'll try that tonight.

Moritz

Bernhard_Reiter · February 13, 2002, 11:40am

On Wed, Feb 13, 2002 at 10:42:55AM +0000, M Lennert wrote:

On 13 Feb 02, at 11:32, Markus Neteler wrote:

> a few days ago I have added
> src.contrib/GMSL/NVIZ2.2/src/tkInt8.2.3.h etc.
> to the source code:
>
> 2002-02-06 15:43 markus
>
> * tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h,
> tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h:
> added tkIntDecls8.2.3.h tkIntDecls8.1.1.h to fix Irix compile
> problem

This seem to be files from tcl tk?
It does not look like a real solution to distribute them
with GRASS. Is there no other way?

Bernhard

Markus_Neteler1 · February 13, 2002, 12:23pm

On Wed, Feb 13, 2002 at 12:40:10PM +0100, Bernhard Reiter wrote:

On Wed, Feb 13, 2002 at 10:42:55AM +0000, M Lennert wrote:
> On 13 Feb 02, at 11:32, Markus Neteler wrote:

> > a few days ago I have added
> > src.contrib/GMSL/NVIZ2.2/src/tkInt8.2.3.h etc.
> > to the source code:
> >
> > 2002-02-06 15:43 markus
> >
> > * tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h,
> > tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h:
> > added tkIntDecls8.2.3.h tkIntDecls8.1.1.h to fix Irix compile
> > problem

This seem to be files from tcl tk?
It does not look like a real solution to distribute them
with GRASS. Is there no other way?

As far as I understand these files are not part of the binary distribution
of tcl/tk. They only appear in the source packages.
Probably we need a change in togl.[ch] to get rid of these extra
include stuff. any experts out there?

Markus

Bernhard_Reiter · February 13, 2002, 12:57pm

On Wed, Feb 13, 2002 at 01:23:34PM +0100, Markus Neteler wrote:

On Wed, Feb 13, 2002 at 12:40:10PM +0100, Bernhard Reiter wrote:
> On Wed, Feb 13, 2002 at 10:42:55AM +0000, M Lennert wrote:
> > On 13 Feb 02, at 11:32, Markus Neteler wrote:
>
> > > a few days ago I have added
> > > src.contrib/GMSL/NVIZ2.2/src/tkInt8.2.3.h etc.
> > > to the source code:
> > >
> > > 2002-02-06 15:43 markus
> > >
> > > * tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h,
> > > tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h:
> > > added tkIntDecls8.2.3.h tkIntDecls8.1.1.h to fix Irix compile
> > > problem
>
> This seem to be files from tcl tk?
> It does not look like a real solution to distribute them
> with GRASS. Is there no other way?

As far as I understand these files are not part of the binary distribution
of tcl/tk. They only appear in the source packages.

Well someone who wants to compile this part of GRASS,
also needs the development packages of tcl/tk.
There should be no need for GRASS to include them.

--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

Markus_Neteler1 · February 13, 2002, 1:09pm

On Wed, Feb 13, 2002 at 01:57:53PM +0100, Bernhard Reiter wrote:

On Wed, Feb 13, 2002 at 01:23:34PM +0100, Markus Neteler wrote:
> On Wed, Feb 13, 2002 at 12:40:10PM +0100, Bernhard Reiter wrote:
> > On Wed, Feb 13, 2002 at 10:42:55AM +0000, M Lennert wrote:
> > > On 13 Feb 02, at 11:32, Markus Neteler wrote:
> >
> > > > a few days ago I have added
> > > > src.contrib/GMSL/NVIZ2.2/src/tkInt8.2.3.h etc.
> > > > to the source code:
> > > >
> > > > 2002-02-06 15:43 markus
> > > >
> > > > * tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h,
> > > > tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h:
> > > > added tkIntDecls8.2.3.h tkIntDecls8.1.1.h to fix Irix compile
> > > > problem
> >
> > This seem to be files from tcl tk?
> > It does not look like a real solution to distribute them
> > with GRASS. Is there no other way?
>
> As far as I understand these files are not part of the binary distribution
> of tcl/tk. They only appear in the source packages.

Well someone who wants to compile this part of GRASS,
also needs the development packages of tcl/tk.
There should be no need for GRASS to include them.

Yes, but no. The tcl/tk include packages does unfortunately *not* include
above files. That's why we have all the confusion. Means: The include
package tcl-devel.rpm/tk-devel.rpm (or however it is called) lacks
those files. This is a togl.c specific problem.

Markus

Glynn_Clements · February 13, 2002, 8:00pm

Markus Neteler wrote:

> > > > > a few days ago I have added
> > > > > src.contrib/GMSL/NVIZ2.2/src/tkInt8.2.3.h etc.
> > > > > to the source code:
> > > > >
> > > > > 2002-02-06 15:43 markus
> > > > >
> > > > > * tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h,
> > > > > tkInt8.1.1.h, tkInt8.2.3.h, tkIntDecls8.1.1.h, tkIntDecls8.2.3.h:
> > > > > added tkIntDecls8.2.3.h tkIntDecls8.1.1.h to fix Irix compile
> > > > > problem
> > >
> > > This seem to be files from tcl tk?
> > > It does not look like a real solution to distribute them
> > > with GRASS. Is there no other way?
> >
> > As far as I understand these files are not part of the binary distribution
> > of tcl/tk. They only appear in the source packages.
>
> Well someone who wants to compile this part of GRASS,
> also needs the development packages of tcl/tk.
> There should be no need for GRASS to include them.

Yes, but no. The tcl/tk include packages does unfortunately *not* include
above files. That's why we have all the confusion. Means: The include
package tcl-devel.rpm/tk-devel.rpm (or however it is called) lacks
those files. This is a togl.c specific problem.

The problem is specific to creating new Tk widgets; this requires the
"internal" headers, while other uses of Tk only require tk.h.

Basically, the Tk packages available from Linux distribution vendors
don't usually include the header files which are necessary for
creating new widgets.

The only options for NVIZ are to either:

1. Require a working Tk development environment, including TkInt.h
etc; this will typically require the user to build Tk from source.

2. Supply the missing files for all common versions of Tk.

--
Glynn Clements <glynn.clements@virgin.net>

Bernhard_Reiter · February 13, 2002, 8:28pm

On Wed, Feb 13, 2002 at 08:00:51PM +0000, Glynn Clements wrote:

The problem is specific to creating new Tk widgets; this requires the
"internal" headers, while other uses of Tk only require tk.h.

Basically, the Tk packages available from Linux distribution vendors
don't usually include the header files which are necessary for
creating new widgets.

The only options for NVIZ are to either:

1. Require a working Tk development environment, including TkInt.h
etc; this will typically require the user to build Tk from source.

Or at least get the right sources.

2. Supply the missing files for all common versions of Tk.

Then 1. is the better choice in my views.
And tell the tcl/tk people and package maintainers about the problem.

Markus_Neteler1 · February 13, 2002, 9:32pm

On Wed, Feb 13, 2002 at 09:28:17PM +0100, Bernhard Reiter wrote:

On Wed, Feb 13, 2002 at 08:00:51PM +0000, Glynn Clements wrote:
> The problem is specific to creating new Tk widgets; this requires the
> "internal" headers, while other uses of Tk only require tk.h.
>
> Basically, the Tk packages available from Linux distribution vendors
> don't usually include the header files which are necessary for
> creating new widgets.
>
> The only options for NVIZ are to either:
>
> 1. Require a working Tk development environment, including TkInt.h
> etc; this will typically require the user to build Tk from source.

Or at least get the right sources.

> 2. Supply the missing files for all common versions of Tk.

Then 1. is the better choice in my views.

Here I disagree - 60-90% of the GRASS users won't be willing or able to
compile the tcl/tk from scratch. That would be the way to loose a lot of
friends when adding this dependency.

And tell the tcl/tk people and package maintainers about the problem.

Probably better. But it will solve it only for the next year unless
the old tcl/tk versions are swept away by evolution.

Markus

Bernhard_Reiter · February 13, 2002, 9:38pm

On Wed, Feb 13, 2002 at 10:32:59PM +0100, Markus Neteler wrote:

> > The only options for NVIZ are to either:
> >
> > 1. Require a working Tk development environment, including TkInt.h
> > etc; this will typically require the user to build Tk from source.
>
> Or at least get the right sources.
>
> > 2. Supply the missing files for all common versions of Tk.
>
> Then 1. is the better choice in my views.

Here I disagree - 60-90% of the GRASS users won't be willing or able to
compile the tcl/tk from scratch. That would be the way to loose a lot of
friends when adding this dependency.

The mistake is at the tcl/tk site, hopefully they are loosing
friends then... We will loose friend if we add further maintenance
overhead for us and get even more bulkier in the end...

Seriously, they do not need to recompile.
They just need the right sources. We can offer a convinient package
with the headers, but the base line has to be that this is not GRASS' fault.

> And tell the tcl/tk people and package maintainers about the problem.

Probably better. But it will solve it only for the next year unless
the old tcl/tk versions are swept away by evolution.

Convinient tarballs only containing the header files for _one_
tcl/tk versions might help here.

--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

M_Lennert · February 14, 2002, 12:58pm

On 13 Feb 02, at 11:32, Markus Neteler wrote:

On Wed, Feb 13, 2002 at 10:22:44AM +0000, M Lennert wrote:
> Hello,
>
Moritz: try to comment line 36 in tkInt8.2.3.h.

I did this and the sources compiled, but now I get the following error:

***********
Loading Data
Update elev null mask
Loading Data
building color table
Adding panels from /usr/local/grass5/etc/nviz2.2/scripts
Nv_(panels)
toplevel made
child killed: segmentation violation
    while executing
"exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdout"
    ("eval" body line 1)
    invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdout"
    invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
    (file "/usr/local/grass5/bin/nviz" line 13)
**********

This is the error documented in bug #783 which was declared resolved as fo 5.0.0pre2. Any ideas ?

Moritz

Markus_Neteler1 · February 14, 2002, 1:11pm

On Thu, Feb 14, 2002 at 12:58:19PM +0000, M Lennert wrote:

On 13 Feb 02, at 11:32, Markus Neteler wrote:

> On Wed, Feb 13, 2002 at 10:22:44AM +0000, M Lennert wrote:
> > Hello,
> >
> Moritz: try to comment line 36 in tkInt8.2.3.h.
>

I did this and the sources compiled, but now I get the following error:

Moritz,

can you check the tk version? It is defined in
/usr/include/tk.h

Probably you are not using 8.2.3, but something similar
(means that we have to add another tkInt8.2.X.h).

Markus

***********
Loading Data
Update elev null mask
Loading Data
building color table
Adding panels from /usr/local/grass5/etc/nviz2.2/scripts
Nv_(panels)
toplevel made
child killed: segmentation violation
    while executing
"exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdout"
    ("eval" body line 1)
    invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdout"
    invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
    (file "/usr/local/grass5/bin/nviz" line 13)
**********

This is the error documented in bug #783 which was declared resolved as fo 5.0.0pre2. Any ideas ?

Moritz
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Bernhard_Reiter · February 14, 2002, 1:17pm

On Thu, Feb 14, 2002 at 02:11:20PM +0100, Markus Neteler wrote:

On Thu, Feb 14, 2002 at 12:58:19PM +0000, M Lennert wrote:
> On 13 Feb 02, at 11:32, Markus Neteler wrote:
>
> > On Wed, Feb 13, 2002 at 10:22:44AM +0000, M Lennert wrote:
> > > Hello,
> > >
> > Moritz: try to comment line 36 in tkInt8.2.3.h.
> >
>
> I did this and the sources compiled, but now I get the following error:

Moritz,

can you check the tk version? It is defined in
/usr/include/tk.h

Probably you are not using 8.2.3, but something similar
(means that we have to add another tkInt8.2.X.h).

I can only hope that we remove code from tcl/tk distributions
from the GRASS codebase as soon as possible.
It will be a nightmare to maintain and support.

Markus_Neteler1 · February 14, 2002, 1:27pm

On Thu, Feb 14, 2002 at 02:17:07PM +0100, Bernhard Reiter wrote:

On Thu, Feb 14, 2002 at 02:11:20PM +0100, Markus Neteler wrote:
> On Thu, Feb 14, 2002 at 12:58:19PM +0000, M Lennert wrote:
> > On 13 Feb 02, at 11:32, Markus Neteler wrote:
> >
> > > On Wed, Feb 13, 2002 at 10:22:44AM +0000, M Lennert wrote:
> > > > Hello,
> > > >
> > > Moritz: try to comment line 36 in tkInt8.2.3.h.
> > >
> >
> > I did this and the sources compiled, but now I get the following error:
>
> Moritz,
>
> can you check the tk version? It is defined in
> /usr/include/tk.h
>
> Probably you are not using 8.2.3, but something similar
> (means that we have to add another tkInt8.2.X.h).

I can only hope that we remove code from tcl/tk distributions
from the GRASS codebase as soon as possible.
It will be a nightmare to maintain and support.

Bernhard,

On Wed, Feb 13, 2002 at 09:28:17PM +0100, Bernhard Reiter wrote:

We can offer a convinient package
with the headers, but the base line has to be that this is not GRASS' fault.

do you think of providing a tcl/tk binaries package including the
additional header file? That's not fully clear to me.
If yes, it will be another dependency for GRASS as the standard
tcl/tk package delivered on Linux distros would be needed to be replaced.
You also had to prepare such a package for all the architectures and
OSes, right? Or am I missing something?

If we "just" add the missing header files to NVIZ, we are at least
compliant up to tcl/tk8.3. But let me know, it seems I didn't understand
your proposal

Markus

Bernhard_Reiter · February 14, 2002, 3:12pm

On Thu, Feb 14, 2002 at 02:27:17PM +0100, Markus Neteler wrote:

On Wed, Feb 13, 2002 at 09:28:17PM +0100, Bernhard Reiter wrote:
>We can offer a convinient package
>with the headers, but the base line has to be that this is not GRASS' fault.

do you think of providing a tcl/tk binaries package including the
additional header file? That's not fully clear to me.

If tcl/tk binary packages miss these headers,
that is bug on their side. So we tell people:

This is a fault of the binary package maintainers!

Then we can create tarballs for each of the most common
tcl/tk binary packages to easily add these headers and tell people:

  For your convinience we occasionally package
  these missing header files for some tcl/tk binary
  packages as add on package: Check ...

If yes, it will be another dependency for GRASS as the standard
tcl/tk package delivered on Linux distros would be needed to be replaced.

We should avoid this at any costs.

You also had to prepare such a package for all the architectures and
OSes, right?

Instead of making them official part of GRASS,
we just packages the header files. We would not need to do anything
more than what we would need to do when we add it as official part
of GRASS. Because we do no promisse to support all tcl/tk packages,
it would save us efforts.

If we "just" add the missing header files to NVIZ, we are at least
compliant up to tcl/tk8.3.

This would be flawed by design.
To "just" add the missing header we somehow get some sort of
responsibility that this works. We also dublicate work and add a
workaround for a bug that should be fixed at the cause.

Bernhard

Markus_Neteler1 · February 14, 2002, 4:32pm

On Thu, Feb 14, 2002 at 04:12:18PM +0100, Bernhard Reiter wrote:

On Thu, Feb 14, 2002 at 02:27:17PM +0100, Markus Neteler wrote:
> On Wed, Feb 13, 2002 at 09:28:17PM +0100, Bernhard Reiter wrote:
> >We can offer a convinient package
> >with the headers, but the base line has to be that this is not GRASS' fault.
>
> do you think of providing a tcl/tk binaries package including the
> additional header file? That's not fully clear to me.

If tcl/tk binary packages miss these headers,
that is bug on their side. So we tell people:

This is a fault of the binary package maintainers!

agreed.

Then we can create tarballs for each of the most common
tcl/tk binary packages to easily add these headers and tell people:

  For your convinience we occasionally package
  these missing header files for some tcl/tk binary
  packages as add on package: Check ...

However:
- who is creating this tarball?
- who is maintaining it?

> If yes, it will be another dependency for GRASS as the standard
> tcl/tk package delivered on Linux distros would be needed to be replaced.

We should avoid this at any costs.

But you propose that an additional tarball is needed. Or not?

> You also had to prepare such a package for all the architectures and
> OSes, right?

Instead of making them official part of GRASS,
we just packages the header files. We would not need to do anything
more than what we would need to do when we add it as official part
of GRASS. Because we do no promisse to support all tcl/tk packages,
it would save us efforts.

not really, because you just change the work to maintaining the headers
tarball. Instead we can also include it (same amount of work for us (me))
and the users do not have to download this extra tarball.
If the Tcl/Tk people fix their problem, we stop to fill in new headers.

> If we "just" add the missing header files to NVIZ, we are at least
> compliant up to tcl/tk8.3.

This would be flawed by design.
To "just" add the missing header we somehow get some sort of
responsibility that this works. We also dublicate work and add a
workaround for a bug that should be fixed at the cause.

But generating a new tarball is the same work, or not?
I don't see the difference... (please speak slowly to me...

Markus

Bernhard_Reiter · February 14, 2002, 6:24pm

On Thu, Feb 14, 2002 at 05:32:40PM +0100, Markus Neteler wrote:

> If tcl/tk binary packages miss these headers,
> that is bug on their side. So we tell people:
>
> This is a fault of the binary package maintainers!

agreed.

Okay. We place a big stricker on GRASS with this warning.
This is important or they never fix it.

> Then we can create tarballs for each of the most common
> tcl/tk binary packages to easily add these headers and tell people:
>
> For your convinience we occasionally package
> these missing header files for some tcl/tk binary
> packages as add on package: Check ...

However:
- who is creating this tarball?
- who is maintaining it?

Any who volenteers.
If you think we need to have this to not to loose friends,
you should start to make one.

> > If yes, it will be another dependency for GRASS as the standard
> > tcl/tk package delivered on Linux distros would be needed to be replaced.
>
> We should avoid this at any costs.

But you propose that an additional tarball is needed. Or not?

I propose the tarball.
But it is not a dependency towards the tarball,
but towards the header files thus a correct distribution of tcl/tk.

> Instead of making them official part of GRASS,
> we just packages the header files. We would not need to do anything
> more than what we would need to do when we add it as official part
> of GRASS. Because we do no promisse to support all tcl/tk packages,
> it would save us efforts.

not really, because you just change the work to maintaining the headers
tarball. Instead we can also include it (same amount of work for us (me))
and the users do not have to download this extra tarball.
If the Tcl/Tk people fix their problem, we stop to fill in new headers.

My experience with Free Software projects tells me:
  It will be more work for us in the end the way you propose it.
  Because:
    * User will mostly think it is our responsibility.
      And not the tcl/tk people. So they will bug us
      not them.

    * We would need to ensure that it is working
    for reasonable number of versions to be fair.
      If we make convenience packages, we can
       create less and make sure that there is pressure
      in the right direction.

> > If we "just" add the missing header files to NVIZ, we are at least
> > compliant up to tcl/tk8.3.
>
> This would be flawed by design.
> To "just" add the missing header we somehow get some sort of
> responsibility that this works. We also dublicate work and add a
> workaround for a bug that should be fixed at the cause.

But generating a new tarball is the same work, or not?

One extra tarball for tcl/tk8.3: Yes.

I don't see the difference... (please speak slowly to me...

Less people will complain about that it does not work to us,
because they know it is not our fault!
Chances will rise that tcl/tk packagers will fix the problem.
Otherwise it looks like being our fault.

Then we have more time to do the core stuff,
that only the core team can do.
The bug-database is big.

M_Lennert · February 15, 2002, 10:46am

On 14 Feb 02, at 14:11, Markus Neteler wrote:

On Thu, Feb 14, 2002 at 12:58:19PM +0000, M Lennert wrote:
> On 13 Feb 02, at 11:32, Markus Neteler wrote:
>
> > On Wed, Feb 13, 2002 at 10:22:44AM +0000, M Lennert wrote:
> > > Hello,
> > >
> > Moritz: try to comment line 36 in tkInt8.2.3.h.
> >
>
> I did this and the sources compiled, but now I get the following error:

Moritz,

can you check the tk version? It is defined in
/usr/include/tk.h

Probably you are not using 8.2.3, but something similar
(means that we have to add another tkInt8.2.X.h).

in /usr/include/tcl8.2/tk.h:

#define TK_MAJOR_VERSION 8
#define TK_MINOR_VERSION 2
#define TK_RELEASE_LEVEL TCL_FINAL_RELEASE
#define TK_RELEASE_SERIAL 3

#define TK_VERSION "8.2"
#define TK_PATCH_LEVEL "8.2.3+"

I don't know if that patch level makes a difference, but otherwise it looks like 8.2.3 to me...

Moritz