Re: First questions...

Re: First questions...

[Ben Elliston]

Hi Nils,

   [this will not make it to the list; I'm ORBS blocked atm and our
   admins are working on it...)

I know the feeling.

   ... and why does it have it's own grep that it installs in the
   $prefix/bin directory??!?

S-N required a special version of grep that did things like a) took a list
of files to grep from an input file and b) indicated its progress as it
went.  As I understand it, that requirement has been lifted from the
development tree--Mo, can you explain how you got around these requirements
so you could use the any old grep?

   It definitely does install parts of tcl and TK, and almost all of the
   manpages.  I assume that if there are namespace collisions, the newer
   manpages that I had installed are overwritten.  Wonderful.

I hear you.

   It also installs a TON of executables in the main bin dir.  Why not
   have it install them in its own share/SN/bin dir and add the path when
   the main executable is loaded?

What you are suggesting doesn't conform to the GNU directory layout.  If
there are a lot of executables in the bin/ directory, perhaps we need to
look at moving them to libexec if they aren't programs that a user would
invoke directly themselves.

From the directory listing you've given, I can see straight away that all of
the parsers (abrowser, cbrowser, fbrowser, etc) could be moved into libexec/
right now.  Thoughts, guys?

And as you suggest, removing the dependency on installing Tcl and Tk will
help a lot.

Ben

Re: First questions...

[Mo DeJong]

On Mon, 7 Aug 2000, Ben Elliston wrote:

>    ... and why does it have it's own grep that it installs in the
>    $prefix/bin directory??!?
> 
> S-N required a special version of grep that did things like a) took a list
> of files to grep from an input file and b) indicated its progress as it
> went.  As I understand it, that requirement has been lifted from the
> development tree--Mo, can you explain how you got around these requirements
> so you could use the any old grep?

The custom grep was used in the % done meter, that little meter
that goes from 1% to 100% as the grep is running. We are not going to
have a % done meter in 5.0. It is just not worth it, we just can't
require a custom version of grep. The custom grep was also used
for some result highlighting, but it will be faster to do that
with a Tcl regexp command once we move up to 8.3.

>    It definitely does install parts of tcl and TK, and almost all of the
>    manpages.  I assume that if there are namespace collisions, the newer
>    manpages that I had installed are overwritten.  Wonderful.
> 
> I hear you.

Yes, it installs Tcl/Tk, I already mentioned that Tcl/Tk is required
by SN.

>    It also installs a TON of executables in the main bin dir.  Why not
>    have it install them in its own share/SN/bin dir and add the path when
>    the main executable is loaded?
> 
> What you are suggesting doesn't conform to the GNU directory layout.  If
> there are a lot of executables in the bin/ directory, perhaps we need to
> look at moving them to libexec if they aren't programs that a user would
> invoke directly themselves.

If you don't like it, just use --prefix.

> >From the directory listing you've given, I can see straight away that all of
> the parsers (abrowser, cbrowser, fbrowser, etc) could be moved into libexec/
> right now.  Thoughts, guys?
> 
> And as you suggest, removing the dependency on installing Tcl and Tk will
> help a lot.

We are still going to need to build Tcl/Tk, it is unlikely that
a given system is going to have the right versions or Tcl, Tk,
Itcl, BLT, Tix, or whatever. We need to supply them. It may be possible
to allow the user to tell the system not to use its own version
and use the system ones instead, but that will not be the default.
Come on, folks can not even fix a missing chmod, there is no
way everyone is going to be able to figure out problems related
to building with the wrong version of Tcl/Tk.

Mo DeJong
Red Hat Inc

Re: First questions...

[Ben Elliston]

   > What you are suggesting doesn't conform to the GNU directory layout.  If
   > there are a lot of executables in the bin/ directory, perhaps we need to
   > look at moving them to libexec if they aren't programs that a user would
   > invoke directly themselves.
   
   If you don't like it, just use --prefix.

It's not good style to leave non-user-visible programs lying around in the
bin directory.  That's what the libexec directory is for.

   We are still going to need to build Tcl/Tk, it is unlikely that a
   given system is going to have the right versions or Tcl, Tk, Itcl,
   BLT, Tix, or whatever. We need to supply them. It may be possible to
   allow the user to tell the system not to use its own version and use
   the system ones instead, but that will not be the default. Come on,
   folks can not even fix a missing chmod, there is no way everyone is
   going to be able to figure out problems related to building with the
   wrong version of Tcl/Tk.

I'm not suggesting that we try to run with the installed versions of these
packages.  I'm just suggesting that we don't _include_ the source to all of
them in the snavigator tarball.  If we require _exactly_ Tcl 8.3 or
whatever, then we can have `configure' test for this.

Ben

Re: First questions...

[Mark Brown]

On Sun, Aug 06, 2000 at 04:03:37PM -0700, Mo DeJong wrote:

> Itcl, BLT, Tix, or whatever. We need to supply them. It may be possible
> to allow the user to tell the system not to use its own version
> and use the system ones instead, but that will not be the default.

Is it not possible to write an autoconf test to detect what you need?

> Come on, folks can not even fix a missing chmod, there is no
> way everyone is going to be able to figure out problems related
> to building with the wrong version of Tcl/Tk.

If you make installing the versions you ship non-optional you're 
going to annoy people who actually look at what you're trying to do.  
I certainly feel unhappy installing a program that seems to want to
stomp over as much of my system as Source Navigator does - particularly
things like TCL/Tk.

-- 
Mark Brown  mailto:broonie@tardis.ed.ac.uk   (Trying to avoid grumpiness)
            http://www.tardis.ed.ac.uk/~broonie/
EUFS        http://www.eusa.ed.ac.uk/societies/filmsoc/

Re: First questions...

[Mo DeJong]

On Mon, 7 Aug 2000, Mark Brown wrote:

> On Sun, Aug 06, 2000 at 04:03:37PM -0700, Mo DeJong wrote:
> 
> > Itcl, BLT, Tix, or whatever. We need to supply them. It may be possible
> > to allow the user to tell the system not to use its own version
> > and use the system ones instead, but that will not be the default.
> 
> Is it not possible to write an autoconf test to detect what you need?

Not unless the autoconf test downloads, builds, and installs
the correct versions of each package you do not have.

> > Come on, folks can not even fix a missing chmod, there is no
> > way everyone is going to be able to figure out problems related
> > to building with the wrong version of Tcl/Tk.
> 
> If you make installing the versions you ship non-optional you're 
> going to annoy people who actually look at what you're trying to do.  
> I certainly feel unhappy installing a program that seems to want to
> stomp over as much of my system as Source Navigator does - particularly
> things like TCL/Tk.

Why can't you just use --prefix=/usr/local/SN? Perhaps the current
approach is non-optimal. Are you willing to help improve it?

Mo DeJong
Red Hat Inc

Re: First questions...

[Mark Brown]

On Sun, Aug 06, 2000 at 04:58:40PM -0700, Mo DeJong wrote:
> On Mon, 7 Aug 2000, Mark Brown wrote:

> > Is it not possible to write an autoconf test to detect what you need?

> Not unless the autoconf test downloads, builds, and installs
> the correct versions of each package you do not have.

People should be able to cope with installing things - other packages
seem to manage to avoid shipping and/or installing all the stuff they
need unconditionally.  It's probably worth remembering that a lot of 
the users you're worrying about are going to wind up getting a 
prepackaged version.  

> Why can't you just use --prefix=/usr/local/SN? Perhaps the current

That's horrible.  With my sysadmin hat on, it sets off lots of alarm
bells about the effort that's going to be required to maintain the
software.  With my developer hat on, things like that make me worry
that the software might be fragile.  I can introduce enough bugs by
myself without worrying about tools being buggy :-) .

It's not insurmountable by any stretch of the imagination, but it's 
definately broken.

> approach is non-optimal. Are you willing to help improve it?

Potentially; there doesn't seem much point looking at it right now
while these custom versions are still required.

-- 
Mark Brown  mailto:broonie@tardis.ed.ac.uk   (Trying to avoid grumpiness)
            http://www.tardis.ed.ac.uk/~broonie/
EUFS        http://www.eusa.ed.ac.uk/societies/filmsoc/

Re: First questions...

[Mo DeJong]

On Mon, 7 Aug 2000, Mark Brown wrote:

> On Sun, Aug 06, 2000 at 04:58:40PM -0700, Mo DeJong wrote:
> > On Mon, 7 Aug 2000, Mark Brown wrote:
> 
> > > Is it not possible to write an autoconf test to detect what you need?
> 
> > Not unless the autoconf test downloads, builds, and installs
> > the correct versions of each package you do not have.
> 
> People should be able to cope with installing things - other packages
> seem to manage to avoid shipping and/or installing all the stuff they
> need unconditionally.  It's probably worth remembering that a lot of 
> the users you're worrying about are going to wind up getting a 
> prepackaged version.  

One would hope. The sad fact is that most people are not
able to build and install unless it is really simple.
./configure ; make install is nice and simple, building
with external packages is not.

> > Why can't you just use --prefix=/usr/local/SN? Perhaps the current
> 
> That's horrible.  With my sysadmin hat on, it sets off lots of alarm
> bells about the effort that's going to be required to maintain the
> software.  With my developer hat on, things like that make me worry
> that the software might be fragile.  I can introduce enough bugs by
> myself without worrying about tools being buggy :-) .
> 
> It's not insurmountable by any stretch of the imagination, but it's 
> definately broken.
> 
> > approach is non-optimal. Are you willing to help improve it?
> 
> Potentially; there doesn't seem much point looking at it right now
> while these custom versions are still required.

Agreed. For right now, just use --prefix. This should be addressed
in 5.0, after we finish moving up to 8.3.

Mo DeJong
Red Hat Inc

Re: First questions...

[Bruce Stephens]

Mo DeJong <mdejong@cygnus.com> writes:

> On Mon, 7 Aug 2000, Mark Brown wrote:

[...]

> > People should be able to cope with installing things - other packages
> > seem to manage to avoid shipping and/or installing all the stuff they
> > need unconditionally.  It's probably worth remembering that a lot of 
> > the users you're worrying about are going to wind up getting a 
> > prepackaged version.  
> 
> One would hope. The sad fact is that most people are not
> able to build and install unless it is really simple.
> ./configure ; make install is nice and simple, building
> with external packages is not.

Things are typically different with GNU/Linux and *BSD, though.  In
both cases, you surely want to make it easy to build SN so that it
uses preinstalled versions of Tcl, Tk, itcl, BLT, because the people
getting the binary packages can also easily get binary packages of the
external packages which will install in sane places.

-- 
Bruce Stephens			Bruce.Stephens@MessagingDirect.com
MessagingDirect(UK) Ltd		<URL: http://www.MessagingDirect.com/ >

Re: First questions...

[Syd Polk]

>    It also installs a TON of executables in the main bin dir.  Why not
>    have it install them in its own share/SN/bin dir and add the path when
>    the main executable is loaded?
> 
> What you are suggesting doesn't conform to the GNU directory layout.  If
> there are a lot of executables in the bin/ directory, perhaps we need to
> look at moving them to libexec if they aren't programs that a user would
> invoke directly themselves.

The problem with that is that making a libexec directory makes it really hard to
launch from Windows. It makes it necessary to put some of the sourcenav
directories on the path. It is not really feasible.

The best solution is to configure with a prefixdir:

configure --prefix=/usr/local/sourcenav

and then do make; make install

Re: First questions...

[Thomas Heller]

> >    It also installs a TON of executables in the main bin dir.  Why not
> >    have it install them in its own share/SN/bin dir and add the path
when
> >    the main executable is loaded?
> >
> > What you are suggesting doesn't conform to the GNU directory layout.  If
> > there are a lot of executables in the bin/ directory, perhaps we need to
> > look at moving them to libexec if they aren't programs that a user would
> > invoke directly themselves.
>
> The problem with that is that making a libexec directory makes it really
hard to
> launch from Windows. It makes it necessary to put some of the sourcenav
> directories on the path. It is not really feasible.
Would not a key in the registry under
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths"
work?

Thomas

Re: First questions...

[Syd Polk]

At 06:27 PM 8/7/00 +0200, Thomas Heller wrote:
> > >    It also installs a TON of executables in the main bin dir.  Why not
> > >    have it install them in its own share/SN/bin dir and add the path
>when
> > >    the main executable is loaded?
> > >
> > > What you are suggesting doesn't conform to the GNU directory layout.  If
> > > there are a lot of executables in the bin/ directory, perhaps we need to
> > > look at moving them to libexec if they aren't programs that a user would
> > > invoke directly themselves.
> >
> > The problem with that is that making a libexec directory makes it really
>hard to
> > launch from Windows. It makes it necessary to put some of the sourcenav
> > directories on the path. It is not really feasible.
>Would not a key in the registry under
>"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths"
>work?
>
>Thomas

The only registry entries that SN makes right now are setting up the Start 
Menu. The actual exe does not depend on any path or registry values. This 
means you can move SN around to anywhere on your file system.

In general, after 12 years of Windows programming, I really want all of my 
.exe and .dll files in the same directory. It just makes things so much easier.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: First questions...

[Mark Brown]

On Mon, Aug 07, 2000 at 10:59:51AM -0700, Syd Polk wrote:

> In general, after 12 years of Windows programming, I really want all of my 
> .exe and .dll files in the same directory. It just makes things so much easier.

Would it be possible to do things differently on Windows?  Looking at
the source I'm guessing not, but it looks like the main problems are
the differences in SOP between Windows and Unix.  It's normal and
expected for Windows pacakges to do a lot of what you're doing, but on
Unix it's not generally considered acceptable to do things in the same
way.

Incidentally, there seems to be a dependancy problem with building the
Fortran parser - a parallel build failed for me earlier on today because
something tried to build using the output of yacc before yacc had been
run.  Unfortuntately, I lost the log and automake is a little too opaque
for me right now.

-- 
Mark Brown  mailto:broonie@tardis.ed.ac.uk   (Trying to avoid grumpiness)
            http://www.tardis.ed.ac.uk/~broonie/
EUFS        http://www.eusa.ed.ac.uk/societies/filmsoc/

Re: First questions...

[Syd Polk]

At 10:43 PM 8/8/00 +0100, Mark Brown wrote:
>On Mon, Aug 07, 2000 at 10:59:51AM -0700, Syd Polk wrote:
>
> > In general, after 12 years of Windows programming, I really want all of my
> > .exe and .dll files in the same directory. It just makes things so much 
> easier.
>
>Would it be possible to do things differently on Windows?  Looking at
>the source I'm guessing not, but it looks like the main problems are
>the differences in SOP between Windows and Unix.  It's normal and
>expected for Windows pacakges to do a lot of what you're doing, but on
>Unix it's not generally considered acceptable to do things in the same
>way.

This is a lot of work with configure and make. If I get some time, I might 
get motivated, but I doubt it.

What we will do short term is make the default make install dir to be 
/usr/local/sourcenav.

>Incidentally, there seems to be a dependancy problem with building the
>Fortran parser - a parallel build failed for me earlier on today because
>something tried to build using the output of yacc before yacc had been
>run.  Unfortuntately, I lost the log and automake is a little too opaque
>for me right now.

We don't build using a parallel system. There might be something wrong, but 
I think those parts of the Makefile.am are fairly straightfoward.

>--
>Mark Brown  mailto:broonie@tardis.ed.ac.uk   (Trying to avoid grumpiness)
>             http://www.tardis.ed.ac.uk/~broonie/
>EUFS        http://www.eusa.ed.ac.uk/societies/filmsoc/

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: First questions...

[Ben Elliston]

   > What you are suggesting doesn't conform to the GNU directory layout.  If
   > there are a lot of executables in the bin/ directory, perhaps we need to
   > look at moving them to libexec if they aren't programs that a user would
   > invoke directly themselves.
   
   The problem with that is that making a libexec directory makes it
   really hard to launch from Windows. It makes it necessary to put some
   of the sourcenav directories on the path. It is not really feasible.

Many packages that use `configure' aren't as ambitious as Source-Nav with
respect to relocation.  They use $prefix everywhere to make it possible to
track down supporting files, programs, etc.  The expectation is that if you
need to relocate it to somewhere else, you can just build it again from the
source.

If S-N took this approach, wouldn't it be possible to run supporting
programs by providing their absolute path?  Surely Windows could find them
then?

Ben

First questions...

[Nils Lohner]

Hello, 
  I've just downloaded sourcenav and am in the process of compiling it under 
solaris.  I already have a few comments and questions.

1.  Why isn't it available from CVS?  at 14M for the source its a pain to 
keep up, especially over slow (<=ISDN) links.  cvs would help this project 
develop more quickly IMO.

2. Why on earth is tcl/tk 8.1 _included_ in the sourceball??!!??
/sup/build/SN451 > du -s t*8.1
13846   tcl8.1
10195   tk8.1

I won't do a 'make install' until I'm sure it won't try to overwrite my 
current 8.3.1 installation.  Can someone please explain why its included?

3. an online TODO list would be useful.

Well, it's still building... I'll try it with tcl/tk 8.3.1 as soon as its 
done.  What else is being done on this project at the moment?

Regards, Nils.

Re: First questions...

[Mo DeJong]

On Sat, 5 Aug 2000, Nils Lohner wrote:
 
> Hello, 
>   I've just downloaded sourcenav and am in the process of compiling it under 
> solaris.  I already have a few comments and questions.
> 
> 1.  Why isn't it available from CVS?  at 14M for the source its a pain to 
> keep up, especially over slow (<=ISDN) links.  cvs would help this project 
> develop more quickly IMO.

It will be available as a CVS module "soon". We need to do some work
upgrading Tcl/Tk for both sourcenav and insight before we can make
them available in the sourceware CVS.
 
> 2. Why on earth is tcl/tk 8.1 _included_ in the sourceball??!!??
> /sup/build/SN451 > du -s t*8.1
> 13846   tcl8.1
> 10195   tk8.1

Because you need Tcl/Tk to run Source-Navigator.

> I won't do a 'make install' until I'm sure it won't try to overwrite my 
> current 8.3.1 installation.  Can someone please explain why its included?

Because the code does not work with Tcl/Tk 8.3 yet, we are in the
process of upgrading. You do not need to worry about overwriting
anything, just configure with --prefix=${HOME}/sourcenav or something.

> 3. an online TODO list would be useful.
> 
> Well, it's still building... I'll try it with tcl/tk 8.3.1 as soon as its 
> done.  What else is being done on this project at the moment?

That is a known problem, we need to put a TODO list and a
projects list on the website.

Mo DeJong
Red Hat Inc

Re: First questions...

[Ben Elliston]

   2. Why on earth is tcl/tk 8.1 _included_ in the sourceball??!!??

S-N requires local patches to Tcl and Tk.  I understand work is underway to
remove these dependencies--presumably by ensuring that these patches are a)
completely necessary, and b) included in the Tcl/Tk core release.

Ben

Re: First questions...

[Syd Polk]

Nils Lohner wrote:
> 
> Hello,
>   I've just downloaded sourcenav and am in the process of compiling it under
> solaris.  I already have a few comments and questions.
> 
> 1.  Why isn't it available from CVS?  at 14M for the source its a pain to
> keep up, especially over slow (<=ISDN) links.  cvs would help this project
> develop more quickly IMO.

There are multiple reasons. One is that this version of the source is not the
active development branch. The other is related to below.

> 
> 2. Why on earth is tcl/tk 8.1 _included_ in the sourceball??!!??
> /sup/build/SN451 > du -s t*8.1
> 13846   tcl8.1
> 10195   tk8.1
> 
> I won't do a 'make install' until I'm sure it won't try to overwrite my
> current 8.3.1 installation.  Can someone please explain why its included?

This will not impact you tcl 8.3.1 install. There are many reasons why we
include our own tcl version:

- This version of tcl builds in more environments
- Not everybody has tcl installed, esp. on non-Linux environments
- We share versions of Tcl with other cygnus projects. We are in the process of
upgrading tcl versions accross the board, and having our own tcl version insures
we won't screw ourselves or other projects.
- There are unfortunately Cyngus-local Tcl/Tk changes which we are in the
process of removing or submitting as patches to the mainline distribution.
 
> 3. an online TODO list would be useful.
> 
> Well, it's still building... I'll try it with tcl/tk 8.3.1 as soon as its
> done.  What else is being done on this project at the moment?

You are going to get compile and/or link errors if you try to use tcl/tk 8.3.1.

I would suggest you browse the mailing list archives.
 
> Regards, Nils.

Re: First questions...

[Syd Polk]

>
>2. Why on earth is tcl/tk 8.1 _included_ in the sourceball??!!??
>/sup/build/SN451 > du -s t*8.1
>13846   tcl8.1
>10195   tk8.1
>
>I won't do a 'make install' until I'm sure it won't try to overwrite my
>current 8.3.1 installation.  Can someone please explain why its included?

One thing that people can do to minimize the amount of files copied is to do:

configure
make all-snavigator
make install-snavigator

This will only install the bare minimum of files necessary for Tcl, Tk, Tix 
and itcl to work.

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.