RE: RPM package

RE: RPM package

[William Gacquer]

Many thanks to you Artem!
	Now it's up to the sn team to integrate it directly into their CVS
repository.
	But I believe that this RPM distribution will fail cos' it's missing
the recent patches, won't it?

	William


-----Original Message-----
From: Artem Khodush [ mailto:kaa@comail.ru ]
Sent: lundi 31 juillet 2000 23:31
To: sourcenav@sources.redhat.com
Subject: Re: RPM package


> Now I am wondering if you will release RPM packages of it or if you
> could give us the RPM spec file so that we could build our own packages.

Here is the spec file that worked for me (RedHat 6.0, rpm 3.0)

Summary: Source Navigator
Name: source-navigator
Version: 4.5.1
Release: 1
Group: Local/Development Tools
URL: http://sources.redhat.com/sourcenav/
Copyright: GPL
Packager: Artem Khodush <kaa@comail.ru>
Source: SN451.tar.bz2
%define install_dir /usr/local
%define source_dir %{_builddir}/SN451
%define build_dir %{_topdir}/zOBJDIR/SN451
Buildroot: %{_topdir}/zINSTALL/SN451
Prefix: %{install_dir}

%description
Source-Navigator is a unique source code analysis tool that is ideal for
any situation where developers are working with an unfamiliar or complex
code base -- new engineers on projects, reengineering or code inheritance
situations, or large-scale, team driven projects.

Source-Navigator parses multi language code and builds a powerful database
of project symbol information.  Then, with S-N's intuitive GUI, developers
can navigate and browse symbol tables, class structure, cross reference
realationship, inculde structures, and more.  S-N also provides efficient
text search tools for strings in the project files as well as symbols in
the database.

With the APIs, S-N integrates into existing environments including
configuration management systems, as a framework for launching other tools
or IDEs, and allows direct access to the GUI and database for customized
tools.

%prep
%setup -n SN451 -c -T
cd ..
tar x --use-compress-program=bzip2 -f %{_sourcedir}/SN451.tar.bz2
rm -rf %{build_dir}
mkdir -p %{build_dir}
cd %{build_dir}
%{source_dir}/configure --prefix=%{install_dir}

%build
cd %{build_dir}
make all-snavigator 1>log 2>err

%install
rm -rf %{buildroot}/%{install_dir}
cd %{build_dir}
make prefix=%{buildroot}/%{install_dir} install-snavigator
#mkdir -p %{buildroot}/%{install_dir}/doc/snavigator-%{version}
#mv %{buildroot}/%{install_dir}/html
%{buildroot}/%{install_dir}/doc/snavigator-%{version}

cd %{buildroot}/%{install_dir}/bin
strip -s abrowser cbrowser dbcp dbdump dbimp fbrowser grep hyper jbrowser
obrowser tbrowser wish

%files
%{install_dir}/bin/abrowser
%{install_dir}/bin/cbrowser
%{install_dir}/bin/dbcp
%{install_dir}/bin/dbdump
%{install_dir}/bin/dbimp
%{install_dir}/bin/elix-link
%{install_dir}/bin/fbrowser
%{install_dir}/bin/grep
%{install_dir}/bin/hyper
%{install_dir}/bin/jbrowser
%{install_dir}/bin/obrowser
%{install_dir}/bin/snavigator
%{install_dir}/bin/tbrowser
%{install_dir}/bin/wish

#%{install_dir}/doc/snavigator-%{version}/
%{install_dir}/html/
%{install_dir}/share/bitmaps/*
%{install_dir}/share/cygnus/gui/*
%{install_dir}/share/demos/*
%{install_dir}/share/etc/*
%{install_dir}/share/gui/*
%{install_dir}/share/itcl1.5/*
%{install_dir}/share/sdk/*
%{install_dir}/share/tcl8.1/*
%{install_dir}/share/tix4.1/*
%{install_dir}/share/tk8.1/*

Re: RPM package

[Artem Khodush]

> Now it's up to the sn team to integrate it directly into their CVS
> repository.

... if they find appropriate for themselves to maintain binary distribution.

> But I believe that this RPM distribution will fail cos' it's missing
> the recent patches, won't it?

When I wrote the spec file, there was no patches around, but it worked. 
Anyway, before RPM distrubution becomes generally usable, some issues 
should be sorted out, e.g. users expect the documentation for the package 
FOO to appear in %{prefix}/doc/FOO, but sourcenav runtime help expects 
it to be in %{prefix}/html. Also there might be a conflict between  tcl/tk 
libraries wich are installed along with sourcenav and those already present
on user's system.

Best regards,
Artem.

Re: RPM package

[Syd Polk]

At 01:40 AM 8/2/00 +0400, Artem Khodush wrote:
> > Now it's up to the sn team to integrate it directly into their CVS
> > repository.
>
>... if they find appropriate for themselves to maintain binary distribution.
>
> > But I believe that this RPM distribution will fail cos' it's missing
> > the recent patches, won't it?
>
>When I wrote the spec file, there was no patches around, but it worked.
>Anyway, before RPM distrubution becomes generally usable, some issues
>should be sorted out, e.g. users expect the documentation for the package
>FOO to appear in %{prefix}/doc/FOO, but sourcenav runtime help expects
>it to be in %{prefix}/html. Also there might be a conflict between  tcl/tk
>libraries wich are installed along with sourcenav and those already present
>on user's system.

One of the reasons we never bothered with a shared build is that we 
currently rely on our own version of Tcl/Tk. It should not conflict with a 
pre-installed version.

%prefix%/html is the standard that Cygnus has had for years, and is not 
likely to change any time soon.

The biggest thing that needs to be fixed before we start distributing our 
own RPMs is grep. You might have noticed we have our own grep, and it will 
end up on your path. We have removed it in our development version, but 
that version is not ready for prime time yet.

Also, please don't include %prefix%/bin/wish; it is only used for the SN 
graphical installer. You don't want two wishes on the path.

>Best regards,
>Artem.
>

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

Infrastructure work

[Ben Elliston]

   One of the reasons we never bothered with a shared build is that we
   currently rely on our own version of Tcl/Tk. It should not conflict
   with a pre-installed version.

Speaking of which, some thoughts I had yesterday on "big" infrastructure
work that really needs to be done:

	* Removing the dependency on Tix.

	* Removing the dependency on local changes to Tcl and Tk.

	* Making the extensions to the Tcl interpreter a loadable
	  library (ie. "hyper.so").

	* Making the syntax highlighters loadable libraries, too.

Thoughts?

Ben

Re: Infrastructure work

[Syd Polk]

At 09:24 AM 8/2/00 +1000, Ben Elliston wrote:
>    One of the reasons we never bothered with a shared build is that we
>    currently rely on our own version of Tcl/Tk. It should not conflict
>    with a pre-installed version.
>
>Speaking of which, some thoughts I had yesterday on "big" infrastructure
>work that really needs to be done:
>
>         * Removing the dependency on Tix.
>
>         * Removing the dependency on local changes to Tcl and Tk.
>
>         * Making the extensions to the Tcl interpreter a loadable
>           library (ie. "hyper.so").
>
>         * Making the syntax highlighters loadable libraries, too.
>
>Thoughts?
>
>Ben

Yes, all of these need to be done. They are a lot of work.


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

Re: RPM package

[Artem Khodush]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

Syd Polk wrote: 
> One of the reasons we never bothered with a shared build is that we 
> currently rely on our own version of Tcl/Tk. It should not conflict with a 
> pre-installed version.
> 
> %prefix%/html is the standard that Cygnus has had for years, and is not 
> likely to change any time soon.
> 
> The biggest thing that needs to be fixed before we start distributing our 
> own RPMs is grep. You might have noticed we have our own grep, and it will 
> end up on your path. We have removed it in our development version, but 
> that version is not ready for prime time yet.
> 
> Also, please don't include %prefix%/bin/wish; it is only used for the SN 
> graphical installer. You don't want two wishes on the path.

Thanks for the corrections. Here's second try, in case if there is anyone
interested.

Best regards,
Artem.

[-- Attachment #2: sn.spec --]
[-- Type: text/plain, Size: 2467 bytes --]

Summary: Source Navigator
Name: source-navigator
Version: 4.5.1
Release: 1
Group: Local/Development Tools
URL: http://sources.redhat.com
Copyright: GPL
Packager: Artem Khodush <kaa@comail.ru>
Source: SN451.tar.bz2
%define install_dir /usr/local
%define source_dir %{_builddir}/SN451
%define build_dir %{_topdir}/zOBJDIR/SN451
Buildroot: %{_topdir}/zINSTALL/SN451
Prefix: %{install_dir}

%description
Source-Navigator is a unique source code analysis tool that is ideal for
any situation where developers are working with an unfamiliar or complex
code base -- new engineers on projects, reengineering or code inheritance
situations, or large-scale, team driven projects.

Source-Navigator parses multi language code and builds a powerful database
of project symbol information.  Then, with S-N's intuitive GUI, developers
can navigate and browse symbol tables, class structure, cross reference
realationship, inculde structures, and more.  S-N also provides efficient
text search tools for strings in the project files as well as symbols in
the database.

With the APIs, S-N integrates into existing environments including
configuration management systems, as a framework for launching other tools
or IDEs, and allows direct access to the GUI and database for customized
tools.

%prep
%setup -n SN451 -c -T
cd ..
tar x --use-compress-program=bzip2 -f %{_sourcedir}/SN451.tar.bz2
rm -rf %{build_dir}
mkdir -p %{build_dir}
cd %{build_dir}
%{source_dir}/configure --prefix=%{install_dir}

%build
cd %{build_dir}
make all-snavigator 1>log 2>err

%install
rm -rf %{buildroot}/%{install_dir}
cd %{build_dir}
make prefix=%{buildroot}/%{install_dir} install-snavigator

cd %{buildroot}/%{install_dir}/bin
strip -s abrowser cbrowser dbcp dbdump dbimp fbrowser grep hyper jbrowser obrowser tbrowser

%files 
%{install_dir}/bin/abrowser
%{install_dir}/bin/cbrowser
%{install_dir}/bin/dbcp
%{install_dir}/bin/dbdump
%{install_dir}/bin/dbimp
%{install_dir}/bin/elix-link
%{install_dir}/bin/fbrowser
%{install_dir}/bin/grep
%{install_dir}/bin/hyper
%{install_dir}/bin/jbrowser
%{install_dir}/bin/obrowser
%{install_dir}/bin/snavigator
%{install_dir}/bin/tbrowser

%{install_dir}/html/*
%{install_dir}/share/bitmaps/*
%{install_dir}/share/cygnus/gui/*
%{install_dir}/share/demos/*
%{install_dir}/share/etc/*
%{install_dir}/share/gui/*
%{install_dir}/share/itcl1.5/*
%{install_dir}/share/sdk/*
%{install_dir}/share/tcl8.1/*
%{install_dir}/share/tix4.1/*
%{install_dir}/share/tk8.1/*

Re: Infrastructure work

[Gilles J. Seguin]

Ian Roxborough wrote:
> 
> On Wed, 2 Aug 2000, Ben Elliston wrote:
> >    This would be cool, but then we are dependent on the user having a
> >    "clean" Tcl version (Some Tcl/Tk apps require core patching before
> >    they run).  (Of course I'm assume you mean that we should load into
> >    the users local Tcl/Tk and not a version from us.)
> >
> > Couldn't snavigator's configure script test the installed Tcl/Tk to
> > determine if it was usable?  That's precisely what Autoconf is for!
> 
> We could, but how many tests? and what needs tested to make
> sure we're not running on a SN safe tcl/tk.  Is it really important?
> I know it's going to be hard tracking down reported bugs only to
> find out the user is running on a none standard tcl/tk.

Can we target tcl/tk version 8.3 supposedly the version for
the upcoming Red Hat 7.0 version (pinestripe)

tcl/tk version 8.4, can you provide information how difficult
it will be.

The question here, how do I will manage all those versions
of tcl/tk. In the sense that nearly every application
require their own version of it.

> > Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.
> > Perhaps they already allow it to be built shared?
> 
> I'd like to see a more generic DB interface first so we can swap
> out our DB back ends.  I've not look at this yet, but may be they
> both go hand in hand.
> 
> Ian.

Re: Infrastructure work

[Mo DeJong]

On Tue, 1 Aug 2000, Ian Roxborough wrote:
 
> On Wed, 2 Aug 2000, Ben Elliston wrote:
> >    This would be cool, but then we are dependent on the user having a
> >    "clean" Tcl version (Some Tcl/Tk apps require core patching before
> >    they run).  (Of course I'm assume you mean that we should load into
> >    the users local Tcl/Tk and not a version from us.)
> > 
> > Couldn't snavigator's configure script test the installed Tcl/Tk to
> > determine if it was usable?  That's precisely what Autoconf is for!
> 
> We could, but how many tests? and what needs tested to make
> sure we're not running on a SN safe tcl/tk.  Is it really important?
> I know it's going to be hard tracking down reported bugs only to
> find out the user is running on a none standard tcl/tk.

I think we have to face reality here. People are never going to
have the "right" versions of Tcl/Tk on all systems. It is just
a lot easier to provide our own. Even if the versions of Tcl/Tk
matched, what if we fix a really critical bug in Tcl, we don't
want people to upgrade to a new OS to get a new version of Tcl
just so they can run SN.

> > Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.  
> > Perhaps they already allow it to be built shared?
> 
> I'd like to see a more generic DB interface first so we can swap
> out our DB back ends.  I've not look at this yet, but may be they
> both go hand in hand.

http://www.qs.co.nz/Tcl/DAS.html
http://zork.net/~phil/projects.html

I am sure there are others.

Mo DeJong
Red Hat Inc

Re: Infrastructure work

[Ian Roxborough]

On Wed, 2 Aug 2000, Ben Elliston wrote:
>    This would be cool, but then we are dependent on the user having a
>    "clean" Tcl version (Some Tcl/Tk apps require core patching before
>    they run).  (Of course I'm assume you mean that we should load into
>    the users local Tcl/Tk and not a version from us.)
> 
> Couldn't snavigator's configure script test the installed Tcl/Tk to
> determine if it was usable?  That's precisely what Autoconf is for!

We could, but how many tests? and what needs tested to make
sure we're not running on a SN safe tcl/tk.  Is it really important?
I know it's going to be hard tracking down reported bugs only to
find out the user is running on a none standard tcl/tk.

> Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.  
> Perhaps they already allow it to be built shared?

I'd like to see a more generic DB interface first so we can swap
out our DB back ends.  I've not look at this yet, but may be they
both go hand in hand.
 
Ian.

Re: Infrastructure work

[Ben Elliston]

   This would be cool, but then we are dependent on the user having a
   "clean" Tcl version (Some Tcl/Tk apps require core patching before
   they run).  (Of course I'm assume you mean that we should load into
   the users local Tcl/Tk and not a version from us.)

Couldn't snavigator's configure script test the installed Tcl/Tk to
determine if it was usable?  That's precisely what Autoconf is for!

Yes, that's what I meant.

   > 	* Making the syntax highlighters loadable libraries, too.
   
   Hmmmm, I like this one a lot.
   
Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.  
Perhaps they already allow it to be built shared?

Ben

Re: Infrastructure work

[Ian Roxborough]

On Wed, 2 Aug 2000, Ben Elliston wrote:
> 	* Removing the dependency on Tix.

They are a number of things that can be done,
using BWidgets it one of my favs. also BLT, which
could also be use to replace the Tree Widget which
is more of plain than Tix.

> 	* Removing the dependency on local changes to Tcl and Tk.

We are actively working towards this. 
(Are you using the development version?)

> 	* Making the extensions to the Tcl interpreter a loadable
> 	  library (ie. "hyper.so").

This would be cool, but then we are dependent on the user
having a "clean" Tcl version (Some Tcl/Tk apps require
core patching before they run).   (Of course I'm assume
you mean that we should load into the users local Tcl/Tk
and not a version from us.)

> 	* Making the syntax highlighters loadable libraries, too.

Hmmmm, I like this one a lot.

Ian.