cgdb-devel — Development activity -- bug reports, patches, related questions

Re: [Cgdb-devel] New libraries for CGDB

[Bob R. <bo...@br...>]

On Mon, Mar 01, 2004 at 02:42:33PM +0100, Ronald Landheer-Cieslak wrote:
> Bob Rossi wrote:
>=20
> >Hi,
> >
> >It's been a long time. However, some of the developers of CGDB are ready
> >to start another round of development, which will make CGDB's interface
> >much more VI compatible.
> >
> >There will be several new libraries created to ease the task of
> >implementing CGDB. libkui will be one of them. This stands for "key user
> >interface". It will be the library responsible for catching user
> >commands. For example, when you hit "5Control-wj" in vim, you expect vim
> >to move you down 5 windows. Well, libkui will be responsible for getting
> >these sequences and returning what command the user requested.
> >
> >There will be several other libraries created and talked about in the
> >near future. I am proposing we place all of the new libraries in
> >cgdb/lib. This will be a new directory. Each library will get a
> >directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these
> >directories will have a src/ and inc/ which implements the library. So,
> >for libkui I will add
> >  cgdb/lib
> >  cgdb/lib/kui
> >  cgdb/lib/kui/inc
> >  cgdb/lib/kui/src
> >
> >Does everyone think this is reasonable? If so, I'll add this
> >infrastructure to the CGDB CVS tree.
> >=20
> >
> Seems reasonable enough to me, but for the time being, I'll keep to porti=
ng.
> However, one thing that may be of interest for cgdb is the container=20
> library I wrote for Jail-ust (also on SourceForge) which I think will=20
> respond to the needs for a hashing implementation discussed here earlier.
> If you check it out like this:
> $ export CVSROOT=3D:pserver:an...@cv...:/cvsroot/jail-ust
> $ cvs login
> anoncvs
> $ cvs co release-libcontain
> you'll get the current version with all of its dependencies (libreplace=
=20
> and the architecture-dependent code)

Sorry for the long delay.

This sounds interesting. Unfortunately, it was written in C++ and cgdb is
written only in C. The reason CGDB is written in C is because we believe
it should be able to port anywhere that GDB does. This way, it can be
used in all the same environments.

Thanks,
Bob Rossi

Re: [Cgdb-devel] New libraries for CGDB

[Ronald Landheer-C. <ro...@la...>]

Bob Rossi wrote:

>Hi,
>
>It's been a long time. However, some of the developers of CGDB are ready
>to start another round of development, which will make CGDB's interface
>much more VI compatible.
>
>There will be several new libraries created to ease the task of
>implementing CGDB. libkui will be one of them. This stands for "key user
>interface". It will be the library responsible for catching user
>commands. For example, when you hit "5Control-wj" in vim, you expect vim
>to move you down 5 windows. Well, libkui will be responsible for getting
>these sequences and returning what command the user requested.
>
>There will be several other libraries created and talked about in the
>near future. I am proposing we place all of the new libraries in
>cgdb/lib. This will be a new directory. Each library will get a
>directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these
>directories will have a src/ and inc/ which implements the library. So,
>for libkui I will add
>   cgdb/lib
>   cgdb/lib/kui
>   cgdb/lib/kui/inc
>   cgdb/lib/kui/src
>
>Does everyone think this is reasonable? If so, I'll add this
>infrastructure to the CGDB CVS tree.
>  
>
Seems reasonable enough to me, but for the time being, I'll keep to porting.
However, one thing that may be of interest for cgdb is the container 
library I wrote for Jail-ust (also on SourceForge) which I think will 
respond to the needs for a hashing implementation discussed here earlier.
If you check it out like this:
$ export CVSROOT=:pserver:an...@cv...:/cvsroot/jail-ust
$ cvs login
anoncvs
$ cvs co release-libcontain
you'll get the current version with all of its dependencies (libreplace 
and the architecture-dependent code)

The included hash implementation comes from the libhash library I wrote 
for other applications, all my own work (so there are no licensing 
worries). Everything is available under GPL (unless I say otherwise in 
writing, in which case the BSD license applies). Th hash implementation 
is the part of the library that has been tested most, the rest is 
alpha-quality (the hash has already been used in production software)

Just thought this could interest you :)

As I am the author of the library, I will of course be happy to support 
it for CGDB.

rlc

Re: [Cgdb-devel] Test suite

[Bob R. <bo...@br...>]

On Sun, Feb 29, 2004 at 10:50:59AM -0500, Mike Mueller wrote:
> $ runtest --version
> WARNING: Couldn't find the global config file.
> Expect version is       5.37.1
> Tcl version is          8.3
> Framework version is    1.4.3

Ok, this looks good. Did you do make && make install before you did make
check?

> I'm mainly referring to the fact that we're writing libraries to do
> things like KUI, so the dejagnu tests might apply there too.  I'm
> not saying we should be testing the gui, because that would probably
> be impossible.  Since there are libraries in tgdb and cgdb that
> merit testing, shouldn't the test suite be at the top level?

I agree with you. Initially, the idea was to not couple tgdb to cgdb.
This way, another process could check out just cgdb/tgdb and have a
working testsuite. Can you think of a good solution that would keep this
relationship true? or should we abandon this relationship and combine
the testsuite into a top-level testsuite?

Bob Rossi

Re: [Cgdb-devel] Test suite

[Mike M. <mmu...@cs...>]

$ runtest --version
WARNING: Couldn't find the global config file.
Expect version is       5.37.1
Tcl version is          8.3
Framework version is    1.4.3

I'm mainly referring to the fact that we're writing libraries to do
things like KUI, so the dejagnu tests might apply there too.  I'm
not saying we should be testing the gui, because that would probably
be impossible.  Since there are libraries in tgdb and cgdb that
merit testing, shouldn't the test suite be at the top level?

Mike

On Sat, 28 Feb 2004, Bob Rossi wrote:

:Do you have dejagnu installed?
:Try
:$ runtest --version
:I am ~/.dejagnurc
:Expect version is 5.32.2
:Tcl version is    8.3
:Framework version is 1.4.2.x
:
:Ok, here is the deal. The testsuite was originally written for TGDB
:only. The dejagnu tool, is good for testing programs that receive text
:as input and then have text as output. Basically, it uses regexp to
:determine if you think it passed based of off it's output.
:
:How do you propose we test the functionality of CGDB? Make CGDB work in
:a mode were it just output's text. (It doesn't  display a gui?)
:
:Or should we fire off a few Email's to the dejagnu list and see if they
:have any advice?
:
:Thanks,
:Bob Rossi
:

Re: [Cgdb-devel] Test suite

[Bob R. <bo...@br...>]

On Sun, Feb 29, 2004 at 01:12:10AM -0500, Mike Mueller wrote:
> The test suite in tgdb isn't working for me... I get the following
> result:
>=20
>                 =3D=3D=3D tgdb tests =3D=3D=3D
>=20
> Schedule of variations:
>     unix
>=20
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description
> file for target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file
> for target.
> Using /home/mike/prog/cgdb/tgdb/testsuite/config/unix.exp as
> tool-and-target-specific interface file.
> Running /home/mike/prog/cgdb/tgdb/testsuite/tgdb.base/_sanity.exp
> ...
> Running /home/mike/prog/cgdb/tgdb/testsuite/tgdb.base/basic.exp ...
> FAIL: timeout buffering commands
> FAIL: timeout sink_after_buffered_commands
> Running /home/mike/prog/cgdb/tgdb/testsuite/tgdb.base/overloaded.exp
> ...
> ERROR: couldn't load tgdb.base/overloaded into tgdb_driver.
> make[2]: *** [check-DEJAGNU] Error 1
>=20
>=20
> On a related note... do you think we should create a top level test
> suite directory so that one 'make check' can test all the aspects of
> the tool that we have tests for?  Since we're creating new classes,
> I feel like testing should be integrated into the development from
> the start.  Does this make any sense?

Do you have dejagnu installed?
Try=20
$ runtest --version
I am ~/.dejagnurc
Expect version is 5.32.2
Tcl version is    8.3
Framework version is 1.4.2.x

Ok, here is the deal. The testsuite was originally written for TGDB
only. The dejagnu tool, is good for testing programs that receive text
as input and then have text as output. Basically, it uses regexp to
determine if you think it passed based of off it's output.

How do you propose we test the functionality of CGDB? Make CGDB work in
a mode were it just output's text. (It doesn't  display a gui?)

Or should we fire off a few Email's to the dejagnu list and see if they
have any advice?

Thanks,
Bob Rossi

[Cgdb-devel] Test suite

[Mike M. <mmu...@cs...>]

The test suite in tgdb isn't working for me... I get the following
result:

                === tgdb tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description
file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file
for target.
Using /home/mike/prog/cgdb/tgdb/testsuite/config/unix.exp as
tool-and-target-specific interface file.
Running /home/mike/prog/cgdb/tgdb/testsuite/tgdb.base/_sanity.exp
...
Running /home/mike/prog/cgdb/tgdb/testsuite/tgdb.base/basic.exp ...
FAIL: timeout buffering commands
FAIL: timeout sink_after_buffered_commands
Running /home/mike/prog/cgdb/tgdb/testsuite/tgdb.base/overloaded.exp
...
ERROR: couldn't load tgdb.base/overloaded into tgdb_driver.
make[2]: *** [check-DEJAGNU] Error 1


On a related note... do you think we should create a top level test
suite directory so that one 'make check' can test all the aspects of
the tool that we have tests for?  Since we're creating new classes,
I feel like testing should be integrated into the development from
the start.  Does this make any sense?

Mike

Re: [Cgdb-devel] New libraries for CGDB

[Bob R. <bo...@br...>]

On Fri, Feb 27, 2004 at 10:37:03AM -0500, Mike Mueller wrote:
> > on a side note: gereal usability of cgdb would probably increase most
> > not by changes to the code but by adding more documentation ;)
>=20
> We all agree on this point.  The point of reworking CGDB now is because
> the current design prohibits us from doing things we'd like to do with it.
>  One of those things is an integrated help system (:help).  Another is
> emulating vi's behavior to a high degree (which we believe will improve
> usability, because most of our users are already vi users).

Good point Robert. I also agree.

One of the goals for CGDB 1.0 would be to have a fully functional help
system that can be in html,info and man format. As well as integrated
into CGDBs soon to be :help functionality.

Bob Rossi

Re: [Cgdb-devel] New libraries for CGDB

[Mike M. <mmu...@cs...>]

> on a side note: gereal usability of cgdb would probably increase most
> not by changes to the code but by adding more documentation ;)

We all agree on this point.  The point of reworking CGDB now is because
the current design prohibits us from doing things we'd like to do with it=
.
 One of those things is an integrated help system (:help).  Another is
emulating vi's behavior to a high degree (which we believe will improve
usability, because most of our users are already vi users).

Mike

Re: [Cgdb-devel] New libraries for CGDB

[Robert L. <rob...@se...>]

On Fri, Feb 27, 2004 at 12:03:19AM -0500, Bob Rossi wrote:
> It's been a long time. However, some of the developers of CGDB are ready
> to start another round of development, which will make CGDB's interface
> much more VI compatible.

sounds cool to me, everything should be more vi compatible!

on a side note: gereal usability of cgdb would probably increase most
not by changes to the code but by adding more documentation ;)

cu  robert

--=20
Robert Lemmen                               http://www.semistable.com=20

Re: [Cgdb-devel] New libraries for CGDB

[Mike M. <mmu...@cs...>]

> There will be several other libraries created and talked about in the
> near future. I am proposing we place all of the new libraries in
> cgdb/lib. This will be a new directory. Each library will get a
> directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these
> directories will have a src/ and inc/ which implements the library. So,
> for libkui I will add
>    cgdb/lib
>    cgdb/lib/kui
>    cgdb/lib/kui/inc
>    cgdb/lib/kui/src
>
> Does everyone think this is reasonable? If so, I'll add this
> infrastructure to the CGDB CVS tree.

Sounds perfect to me.

Mike

[Cgdb-devel] New libraries for CGDB

[Bob R. <bo...@br...>]

Hi,

It's been a long time. However, some of the developers of CGDB are ready
to start another round of development, which will make CGDB's interface
much more VI compatible.

There will be several new libraries created to ease the task of
implementing CGDB. libkui will be one of them. This stands for "key user
interface". It will be the library responsible for catching user
commands. For example, when you hit "5Control-wj" in vim, you expect vim
to move you down 5 windows. Well, libkui will be responsible for getting
these sequences and returning what command the user requested.

There will be several other libraries created and talked about in the
near future. I am proposing we place all of the new libraries in
cgdb/lib. This will be a new directory. Each library will get a
directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these
directories will have a src/ and inc/ which implements the library. So,
for libkui I will add
   cgdb/lib
   cgdb/lib/kui
   cgdb/lib/kui/inc
   cgdb/lib/kui/src

Does everyone think this is reasonable? If so, I'll add this
infrastructure to the CGDB CVS tree.

Thanks,
Bob Rossi

[Cgdb-devel] merge'd cygwin_package_0_4_0 into HEAD.

[Bob R. <bo...@br...>]

Hi,

I merged Ronald's cygwin_package_0_4_0 branch into HEAD tonight.
This patch fixed up a lot of the autotool problems and made it possible
to build CGDB from out of the tree. (This is really cool)

After that, I updated all of the generated files in CVS with the
documented version number of autotools located in the FAQ.
(Ronald generated the files with a slightly older version of the
autotools)

You might want to try building the latest CVS using the configure script. It
seems to work fine for me. Also, try building out of the tree. If there
is any problems, please let me know.

Thanks,
Bob Rossi

Re: [Cgdb-devel] [ cgdb-Bugs-870701 ] Makefile paths

[Bob R. <bo...@br...>]

On Wed, Jan 07, 2004 at 12:47:43PM +0100, Ronald Landheer-Cieslak wrote:
> Can we close this item and mark it as fixed in CVS please? I've added a c=
omment
> to point the OP to the branch in CVS where these problems are solved.
>=20
> rlc
>=20
> On Sun, Jan 04, 2004 at 08:48:38PM -0800, SourceForge.net wrote:
> > Bugs item #870701, was opened at 2004-01-04 23:48
> > Message generated for change (Tracker Item Submitted) made by Item Subm=
itter
> > You can respond by visiting:=20
> > https://sourceforge.net/tracker/?func=3Ddetail&atid=3D534974&aid=3D8707=
01&group_id=3D72581
> >=20
> > Category: CGDB
> > Group: None
> > Status: Open
> > Resolution: None
> > Priority: 5
> > Submitted By: Yaakov Selkowitz (yselkowitz)
> > Assigned to: Nobody/Anonymous (nobody)
> > Summary: Makefile paths
> >=20

It is closed. I assigned it to you and gave you permission to modify
and work on the status of bugs.

BTW, I will try to test/merge the Cygwin branch tonight.

Bob Rossi

Re: [Cgdb-devel] [ cgdb-Bugs-870701 ] Makefile paths

[Ronald Landheer-C. <bly...@us...>]

Can we close this item and mark it as fixed in CVS please? I've added a comment
to point the OP to the branch in CVS where these problems are solved.

rlc

On Sun, Jan 04, 2004 at 08:48:38PM -0800, SourceForge.net wrote:
> Bugs item #870701, was opened at 2004-01-04 23:48
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=534974&aid=870701&group_id=72581
> 
> Category: CGDB
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Yaakov Selkowitz (yselkowitz)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Makefile paths
> 
> Initial Comment:
> I am attempting to build and package CGDB for Cygwin. 
> The program builds and runs seemingly fine (I haven't
> done extensive testing though).  However upon trying to
> package it I ran into a few problems.
> 
> Cygwin packaging is usually done through a build
> script, which makes a .build directory where everything
> that is created through the configure and make process
> is put, keeping the original source dir clean.  However
> the Makefiles expect that the program is being built in
> the source directories, and hence are not found.
> 
> The problem manifests itself when building the
> executables by linking to the libraries which were
> previously built.  These should be linked with relative
> paths, allowing for the external build dir (this is how
> I've seen many programs work).  For example,
> cgdb-0.4.0/cgdb/src/Makefile.in should be patched so:
> 
> cgdb_LDFLAGS = --L$(top_srcdir)/various/util/src +-L../../various/util/src --L$(top_srcdir)/various/adt/src +-L../../various/adt/src --L$(top_srcdir)/various/input/src +-L../../various/input/src --L$(top_srcdir)/various/rlctx/src +-L../../various/rlctx/src --L$(top_srcdir)/tgdb/tgdb-base/src +-L../../tgdb/tgdb-base/src --L$(top_srcdir)/tgdb/annotate-two/src +-L../../tgdb/annotate-two/src --L$(top_srcdir)/cgdb/tokenizer/src +-L../tokenizer/src --L$(top_srcdir)/tgdb/gdbmi/src
> +-L../../tgdb/gdbmi/src
> 
> And so on for similar cases in *that* file and every
> other Makefile.in that links to the libraries created
> earlier in the make process.
> 
> Also, the build script installs to a .inst directory
> from which the bin tarball is made, using 'make install
> DESTDIR=${instdir}' (instdir is defined in the script).
>  When doing so I got the following result:
> 
>  
> /home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/getch_driver.exe
>  
> /home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/input_driver.exe
>  
> /home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/rlctx_driver.exe
>  
> /home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/tgdb_driver.exe
>  
> /home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/tokenizer_driver.exe
>   /usr/bin/cgdb.exe
>   /usr/share/doc/cgdb-0.4.0/AUTHORS
>   /usr/share/doc/cgdb-0.4.0/ChangeLog
>   /usr/share/doc/cgdb-0.4.0/COPYING
>   /usr/share/doc/cgdb-0.4.0/INSTALL
>   /usr/share/doc/cgdb-0.4.0/NEWS
>   /usr/share/doc/cgdb-0.4.0/README
> 
> I don't understand why the progs/*_driver.exe files are
> supposed to go in the source directory.  Are these
> needed by CGDB to run?  Are they meant as examples?  In
> either case this is something that needs to be fixed in
> the Makefile.in's as well.
> 
> If there is anything I can do to help you fix these
> issues I will try to assist.  Thank you for your work
> on this project.
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=534974&aid=870701&group_id=72581
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

-- 
You can extend EXTRAVERSION infinitely, but after the first 10 or so
characters, it starts to get silly.

	- Russell King on linux-kernel

[Cgdb-devel] [ cgdb-Bugs-870701 ] Makefile paths

[SourceForge.net <no...@so...>]

Bugs item #870701, was opened at 2004-01-04 23:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=870701&group_id=72581

Category: CGDB
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Yaakov Selkowitz (yselkowitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Makefile paths

Initial Comment:
I am attempting to build and package CGDB for Cygwin. 
The program builds and runs seemingly fine (I haven't
done extensive testing though).  However upon trying to
package it I ran into a few problems.

Cygwin packaging is usually done through a build
script, which makes a .build directory where everything
that is created through the configure and make process
is put, keeping the original source dir clean.  However
the Makefiles expect that the program is being built in
the source directories, and hence are not found.

The problem manifests itself when building the
executables by linking to the libraries which were
previously built.  These should be linked with relative
paths, allowing for the external build dir (this is how
I've seen many programs work).  For example,
cgdb-0.4.0/cgdb/src/Makefile.in should be patched so:

cgdb_LDFLAGS = --L$(top_srcdir)/various/util/src +-L../../various/util/src --L$(top_srcdir)/various/adt/src +-L../../various/adt/src --L$(top_srcdir)/various/input/src +-L../../various/input/src --L$(top_srcdir)/various/rlctx/src +-L../../various/rlctx/src --L$(top_srcdir)/tgdb/tgdb-base/src +-L../../tgdb/tgdb-base/src --L$(top_srcdir)/tgdb/annotate-two/src +-L../../tgdb/annotate-two/src --L$(top_srcdir)/cgdb/tokenizer/src +-L../tokenizer/src --L$(top_srcdir)/tgdb/gdbmi/src
+-L../../tgdb/gdbmi/src

And so on for similar cases in *that* file and every
other Makefile.in that links to the libraries created
earlier in the make process.

Also, the build script installs to a .inst directory
from which the bin tarball is made, using 'make install
DESTDIR=${instdir}' (instdir is defined in the script).
 When doing so I got the following result:

 
/home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/getch_driver.exe
 
/home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/input_driver.exe
 
/home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/rlctx_driver.exe
 
/home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/tgdb_driver.exe
 
/home/Yaakov/devel/testing/cgdb/cgdb-0.4.0/progs/tokenizer_driver.exe
  /usr/bin/cgdb.exe
  /usr/share/doc/cgdb-0.4.0/AUTHORS
  /usr/share/doc/cgdb-0.4.0/ChangeLog
  /usr/share/doc/cgdb-0.4.0/COPYING
  /usr/share/doc/cgdb-0.4.0/INSTALL
  /usr/share/doc/cgdb-0.4.0/NEWS
  /usr/share/doc/cgdb-0.4.0/README

I don't understand why the progs/*_driver.exe files are
supposed to go in the source directory.  Are these
needed by CGDB to run?  Are they meant as examples?  In
either case this is something that needs to be fixed in
the Makefile.in's as well.

If there is anything I can do to help you fix these
issues I will try to assist.  Thank you for your work
on this project.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=870701&group_id=72581

Re: [Cgdb-devel] cgdb for Cygwin available

[Ronald Landheer-C. <bly...@us...>]

As far as the build scripts are concerned: I'm a bit hesitant about adding a
directory to a CVS repository that I'm not in charge of, so I'll leave the
directory-making up to you and put the script where you tell me to :)

As for the changes on the branch: they're done - you can merge them whenever
you want. Note that the only important changes are to the not-generated files
but everything's in the ChangeLogs so merge away :)

As for the different versions of the Autotools: I developed my changes on a 
Gentoo box with a relatively old set of Autotools, and used them on a Cygwin
box with the latest versions - I don't think there will be any problem. Note,
though, that there is a minor issue that the packaging script works around:
the files that shouldn't be installed (the executables) are, by default, 
into the builder's home directory. This is not a good idea, of course, but
is caused by the special handling of those programs in the Makefile.am files
(the noinst_bin_PROGRAMS parts). This wouldn't normally be a problem, but
it is when you use the DESTDIR variable to put the installation elsewhere,
which I do when packaging. IMHO, these lines should simply be removed from 
the Makefile.am files and be replaced by a cleaner way of handling things. 
If you want, I can see what I can do about this (but as for the Cygwin distro
this wasn't necessary, I didn't do anything about it ;)

Should you run into any problems with the patches, please let me know and I'll
try to fix the problem in the branch (or do a merge locally and fix it in the
merged version).

rlc

On Mon, Dec 15, 2003 at 10:42:37AM -0500, Bob Rossi wrote:
> > I've just put cgdb-0.4.0-1 on rlc.unsane.co.uk. You can point to it with 
> > Cygwin's Setup program to install it.
> 
> Thanks for the great work!
> I'm on vacation in Florida, but I'll try installing it when I get back.
> 
> > All necessary changes are in the Cygwin release branch in CVS.
> > One question, though: would you like to have the packaging script in CVS 
> > as well?
> 
> That is a great idea. You could make a new directory for package 
> maintainers. Possibly a directory in there for each distribution. That
> would be up to you, since you probably know how involved it is to make
> a package for a distro. We could store the Cygwin/debian and maybe 
> gentoo ( Mike :) ) packaging scripts.
> 
> Let me know when you are done so I can merge the branch back into the
> main trunk. I do have one concern for when I do the merge. I think it
> might be possible that when I merge the branch and rerun the
> autoconf/automake tools, that we are not guaranteed to know if your
> changes still work properly. (I am using a different version of the 
> auto tools ). What is a good way to make sure that your changes do 
> still work?
> 
> Thanks,
> Bobby



-- 
QOTD:
	"She's about as smart as bait."

Re: [Cgdb-devel] cgdb for Cygwin available

[Bob R. <bo...@br...>]

> I've just put cgdb-0.4.0-1 on rlc.unsane.co.uk. You can point to it with=
=20
> Cygwin's Setup program to install it.

Thanks for the great work!
I'm on vacation in Florida, but I'll try installing it when I get back.

> All necessary changes are in the Cygwin release branch in CVS.
> One question, though: would you like to have the packaging script in CVS=
=20
> as well?

That is a great idea. You could make a new directory for package=20
maintainers. Possibly a directory in there for each distribution. That
would be up to you, since you probably know how involved it is to make
a package for a distro. We could store the Cygwin/debian and maybe=20
gentoo ( Mike :) ) packaging scripts.

Let me know when you are done so I can merge the branch back into the
main trunk. I do have one concern for when I do the merge. I think it
might be possible that when I merge the branch and rerun the
autoconf/automake tools, that we are not guaranteed to know if your
changes still work properly. (I am using a different version of the=20
auto tools ). What is a good way to make sure that your changes do=20
still work?

Thanks,
Bobby

[Cgdb-devel] cgdb for Cygwin available

[Ronald Landheer-C. <bly...@us...>]

I've just put cgdb-0.4.0-1 on rlc.unsane.co.uk. You can point to it with 
Cygwin's Setup program to install it.
All necessary changes are in the Cygwin release branch in CVS.
One question, though: would you like to have the packaging script in CVS 
as well?

rlc

-- 
Confidant, confidante, n:
	One entrusted by A with the secrets of B, confided to himself by C.
		-- Ambrose Bierce, "The Devil's Dictionary"

Re: [Cgdb-devel] Cgdb port for Cygwin

[Ronald Landheer-C. <bly...@us...>]

On Wed, Nov 26, 2003 at 06:22:23PM -0500, Bob Rossi wrote:
> > > Are there any objections against me
> > > removing the generated files (Makefile.in, configure, etc.) from the branch?
> 
> > What does everyone think the best way to go is?
> 
> Sorry I have been so slow at replying. I have been fixing up the house I
> just bought. Trying to make it livable by Saturday :).
> 
> You just have to love diversity and computer science. We currently have
> 
> 2 for removing the files
>    cygwin packager (Ronald)
>    developer (Peter)
> 
> 2 for leaving the file
>    debian packager (Robert)
>    developer (Me)
> 
> 1 who doesn't care
>    developer (Mike)
> 
> I think it takes 2/3 of the developer's and 3/4 of the packagers to pass any 
> CVS legislation. Can someone correct me if I'm wrong? :)
> 
> Unless, there are some other reasons besides bloating CVS, I would
> prefer to keep the generated files. Currently, I don't mind having the
> CVS sandbox be larger as long as the user gets more functionality out
> of it. Which happens to be the case.
> 
> I have received several patches from people that fix bugs in CGDB. I
> don't really want to make them go through extra steps of learning how
> the build process works, or installing other packages, in order to make
> simple changes to CGDB.
> 
> If it turns out that keeping them in the tree is doing harm, we should
> defiantly remove them.
OK, I'll leave them in :|

rlc

Re: [Cgdb-devel] Cgdb port for Cygwin

[Bob R. <bo...@br...>]

> > Are there any objections against me
> > removing the generated files (Makefile.in, configure, etc.) from the br=
anch?

> What does everyone think the best way to go is?

Sorry I have been so slow at replying. I have been fixing up the house I
just bought. Trying to make it livable by Saturday :).

You just have to love diversity and computer science. We currently have

2 for removing the files
   cygwin packager (Ronald)
   developer (Peter)

2 for leaving the file
   debian packager (Robert)
   developer (Me)

1 who doesn't care
   developer (Mike)

I think it takes 2/3 of the developer's and 3/4 of the packagers to pass an=
y=20
CVS legislation. Can someone correct me if I'm wrong? :)

Unless, there are some other reasons besides bloating CVS, I would
prefer to keep the generated files. Currently, I don't mind having the
CVS sandbox be larger as long as the user gets more functionality out
of it. Which happens to be the case.

I have received several patches from people that fix bugs in CGDB. I
don't really want to make them go through extra steps of learning how
the build process works, or installing other packages, in order to make
simple changes to CGDB.

If it turns out that keeping them in the tree is doing harm, we should
defiantly remove them.

Bob Rossi

Re: [Cgdb-devel] Cgdb port for Cygwin

[Ronald Landheer-C. <bly...@us...>]

On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote:
> > I've made the first set of changes to my local sandbox to allow out-of-tree 
> > building and am about to commit them (or rather: will commit them tomorow 
> > morning) to the cygwin package's branch. 
> Great. I am glad to hear it!
> 
> > Are there any objections against me
> > removing the generated files (Makefile.in, configure, etc.) from the branch?
> > They tend to bloat the CVS contents and, for the moment, do not exactly 
> > reflect my changes because they're re-created with a different set of 
> > Autotools than I will use to make the final package.. (IMHO, no generated
> > files should exist in CVS anyway..).
> The original idea was that the user would not need to have autoconf/automake
> installed in order to get CGDB to build. They could just do ./configure
> && make. The good thing about that is the user does not have to go get
> the versions of the tools we are using in order to get CGDB to build.
> They only need that software in order to change the build system.
> 
> By removing those files, we would be complicating what the user has to
> do in order to use CGDB.
> 
> What does everyone think the best way to go is?
Personally (but I'm repeating myself), I think a user that wants to build from 
source should take the source tarball - either the one provided for his/her 
distribution (which should contain the generated files, of course) or the
one released by the project if one for his/her distribution doesn't exist.
The released source tarballs should, of course, contain the generated files.

A developer working on the project should be able to generate the files, and
may or may not do so with the same version of the tools as the person that
makes the distribution. I, for one, did most of the porting I did so far on
the Cygwin branch on a Gentoo box with a slightly outdated set of Autotools,
which doesn't change much functionally (as the configury files for cgdb are
more or less garden variety) but it does make a rather significant difference
in the generated files, which is transient as the files will finally be 
generated for Cygwin, on Cygwin, with the latest Autotools. The result is a 
rather bloated patch (as the one for the previous release) with only very few
man-made changes. For info: the diff with all files (generated and man-made)
is 253K (7908 lines) in size, w/o ChangeLog entries; the one without the
generated files (aclocal.m4, configure and Makefile.in) is 3.7 K (111 lines).
The difference of almost 7800 lines in a patch - all of which are generated - 
seems rather significant to me, especially if someone wants to review the 
changes I made on the branch to merge them into HEAD: 7800 lines of clutter
could easily hide a few lines of bugs.

The reason I don't like having generated files in CVS is not only that it
bloats the repository - which from an administrators perspective is reason
enough - but that it also bloats man-made changes and tends to obfuscate 
those changes. I don't know how you review changes, but I generally look
at the patch before applying it and 7800 lines of generated clutter certainly
makes that more difficult.

That said, I re-iterate that removing the files from the branch has no impact
on HEAD, and as the branch is intended for a Cygwin release which, itself,
will contain the necessary (generated) files, it will have no impact on 
Cygwin-cgdb users either.

rlc


-- 
Most people don't need a great deal of love nearly so much as they need
a steady supply.

Re: [Cgdb-devel] Cgdb port for Cygwin

[Robert L. <rob...@se...>]

On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote:
> The original idea was that the user would not need to have autoconf/autom=
ake
> installed in order to get CGDB to build. They could just do ./configure
> && make. The good thing about that is the user does not have to go get
> the versions of the tools we are using in order to get CGDB to build.
> They only need that software in order to change the build system.

the user should not be required to have autoconf/automake on her system.
ship the generated files. if you want to have an ultimately clean cvs
they should not be there either, but just get generated. inreality these
files change rarely and could as well be kept in cvs too (this is very
convenient for people who just want to hack on some code, but not change
the build process)

cu  robert

--=20
Robert Lemmen                                 http://www.semistable.com

Re: [Cgdb-devel] Cgdb port for Cygwin

[Mike M. <mmu...@cs...>]

I tend to agree with Peter.  Although it's convenient to have the
generated files present, if it poses a problem, they shouldn't be
there.  They should definitely be included in the release tarballs.

Mike

On Mon, 24 Nov 2003, Peter Kovacs wrote:

:On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote:
:> > I've made the first set of changes to my local sandbox to allow out-of-tree
:> > building and am about to commit them (or rather: will commit them tomorow
:> > morning) to the cygwin package's branch.
:>
:> Great. I am glad to hear it!
:>
:> > Are there any objections against me
:> > removing the generated files (Makefile.in, configure, etc.) from the branch?
:> > They tend to bloat the CVS contents and, for the moment, do not exactly
:> > reflect my changes because they're re-created with a different set of
:> > Autotools than I will use to make the final package.. (IMHO, no generated
:> > files should exist in CVS anyway..).
:>
:> The original idea was that the user would not need to have autoconf/automake
:> installed in order to get CGDB to build. They could just do ./configure
:> && make. The good thing about that is the user does not have to go get
:> the versions of the tools we are using in order to get CGDB to build.
:> They only need that software in order to change the build system.
:>
:> By removing those files, we would be complicating what the user has to
:> do in order to use CGDB.
:>
:> What does everyone think the best way to go is?
:
:I say keep generated files out of cvs, but put them into the source
:tarball when you do a release.  That's fairly standard practice.  Now
:that some distributions are packaging cgdb, hopefully it won't be an
:issue at all.
:
:Plus, I say its okay to require specific versions of autoconf/automake
:if you want to build from CVS.
:
:- Peter
:
:
:--
:Peter D. Kovacs <pe...@ko...>
:

Re: [Cgdb-devel] Cgdb port for Cygwin

[Peter K. <pe...@ko...>]

On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote:
> > I've made the first set of changes to my local sandbox to allow out-of-=
tree=20
> > building and am about to commit them (or rather: will commit them tomor=
ow=20
> > morning) to the cygwin package's branch.=20
>=20
> Great. I am glad to hear it!
>=20
> > Are there any objections against me
> > removing the generated files (Makefile.in, configure, etc.) from the br=
anch?
> > They tend to bloat the CVS contents and, for the moment, do not exactly=
=20
> > reflect my changes because they're re-created with a different set of=
=20
> > Autotools than I will use to make the final package.. (IMHO, no generat=
ed
> > files should exist in CVS anyway..).
>=20
> The original idea was that the user would not need to have autoconf/autom=
ake
> installed in order to get CGDB to build. They could just do ./configure
> && make. The good thing about that is the user does not have to go get
> the versions of the tools we are using in order to get CGDB to build.
> They only need that software in order to change the build system.
>=20
> By removing those files, we would be complicating what the user has to
> do in order to use CGDB.
>=20
> What does everyone think the best way to go is?

I say keep generated files out of cvs, but put them into the source
tarball when you do a release.  That's fairly standard practice.  Now
that some distributions are packaging cgdb, hopefully it won't be an
issue at all.

Plus, I say its okay to require specific versions of autoconf/automake
if you want to build from CVS.

- Peter


--=20
Peter D. Kovacs <pe...@ko...>

Re: [Cgdb-devel] Cgdb port for Cygwin

[Bob R. <bo...@br...>]

> I've made the first set of changes to my local sandbox to allow out-of-tr=
ee=20
> building and am about to commit them (or rather: will commit them tomorow=
=20
> morning) to the cygwin package's branch.=20

Great. I am glad to hear it!

> Are there any objections against me
> removing the generated files (Makefile.in, configure, etc.) from the bran=
ch?
> They tend to bloat the CVS contents and, for the moment, do not exactly=
=20
> reflect my changes because they're re-created with a different set of=20
> Autotools than I will use to make the final package.. (IMHO, no generated
> files should exist in CVS anyway..).

The original idea was that the user would not need to have autoconf/automake
installed in order to get CGDB to build. They could just do ./configure
&& make. The good thing about that is the user does not have to go get
the versions of the tools we are using in order to get CGDB to build.
They only need that software in order to change the build system.

By removing those files, we would be complicating what the user has to
do in order to use CGDB.

What does everyone think the best way to go is?

Bob Rossi