bashdb-devel

[Bashdb-devel] Re Autostuff patches.

[R. B. <ro...@pa...>]

 > Here they are for everyones amusement ... have a look if you dare .)
 > Haven't got around to fixing manpages yet, but i thought i'd solicit some 
 > comment and commit these fixes first.

Over all things I think this is a big big improvement. Many thanks! 

I would like to suggest one change to a comment to configure.ac which
I'll send privately. And when I cd into the debugger directory and try
"make distcheck",  I get this error which I don't believe was there before:

./config.status: line 1: cd: ../../emacs: No such file or directory
config.status: creating emacs/Makefile
config.status: error: cannot find input file: emacs/Makefile.in

I have a feeling $srcdir is inherited when it shouldn't be. Otherwise
things look very good.

 > As for autoconf/automake versions I have a AC_PREREQ(2.57) , but it probably 
 > needs to be relaxed a bit (2.53 was previous value). 

Yes, please. And the value in debugger was 2.50. 

 > It was set by autoupdate which i used to do a first pass of getting
 > the autoconf files somewhat up to date.

It's very generous of the autoupdate folks to coerce everyone to into
getting new (and sometimes incompatible) versions of
autoconf/automake.  But let's not take advantage of this fabulous
offer when it is not needed as is the case here.

Please go ahead and check this all back into CVS taking into account
the above changes as you see fit.

Re: [Bashdb-devel] Re Autostuff patches.

[Mikael A. <sn...@te...>]

On Friday 22 August 2003 22.39, R. Bernstein wrote:
>  > Here they are for everyones amusement ... have a look if you dare .)
>  > Haven't got around to fixing manpages yet, but i thought i'd solicit
>  > some comment and commit these fixes first.
>
> Over all things I think this is a big big improvement. Many thanks!
>
> I would like to suggest one change to a comment to configure.ac which
> I'll send privately. And when I cd into the debugger directory and try
> "make distcheck",  I get this error which I don't believe was there before:
>
> ./config.status: line 1: cd: ../../emacs: No such file or directory
> config.status: creating emacs/Makefile
> config.status: error: cannot find input file: emacs/Makefile.in
>

It was emacs missing in subdirs list in debugger/Makefile.am

> I have a feeling $srcdir is inherited when it shouldn't be. Otherwise
> things look very good.
>
>  > As for autoconf/automake versions I have a AC_PREREQ(2.57) , but it
>  > probably needs to be relaxed a bit (2.53 was previous value).
>
> Yes, please. And the value in debugger was 2.50.
>

I set it to 2.53 in both places as it seemed as the most sensible thing to do.

>  > It was set by autoupdate which i used to do a first pass of getting
>  > the autoconf files somewhat up to date.
>
> It's very generous of the autoupdate folks to coerce everyone to into
> getting new (and sometimes incompatible) versions of
> autoconf/automake.  But let's not take advantage of this fabulous
> offer when it is not needed as is the case here.
>
> Please go ahead and check this all back into CVS taking into account
> the above changes as you see fit.
>
>

It's now commited, with a log comment which (unfortunately) lacks all kind of 
formatting since i managed to loose the linefeeds in it. So here it is in all 
it's glory, or at least - with - linefeeds: 

Mikael fixed: 
	* removed deprecated Autoconf constructs 
	* bootstrap.sh execution order and include location 
	* install into pkgdatadir instead of libdir 
	* use AC_SUBST to configure all paths instead of hardcoding 
And added: 
	* configurable package name using env. var. ALT_PACKAGE_NAME 
	* configurable executable names 
	* dbg-main.inc is genereated from dbg-main.inc.in now 
	* local m4 macros now reside in acinclude.m4

/Mikael

Re: [Bashdb-devel] Re Autostuff patches.

[R. B. <ro...@pa...>]

I hvave made some small additions to the recent good autostuff work.

A little background. The debugger directory I view as an independent
unit. Right now it needs the bash program from the parent directory
but hopefully it might not in the future. So I've been trying to keep
things under debugger self-contained.

When I did a "make distcheck" in the debugger directory, the tarball
crated was bash-2.05b.tar.gz. This would be the name for an unmodified
bash rather than the debugger portion of an enhanced bash. I've
changed the distribution tarball to bash-2.05b-bashdb-xxx.tar.gz. I
realize this is a little confusing given the parent directory tarball
which includes this is bash-2.05b-debugger-xxx.tar.gz. Perhaps that
tarball name should change to rebash-2.05b-xxx-tar.gz.

Another problem in the debugger directory was the fact that if
autoconf chose to run again it couldn't find acinclude.m4 since that's
only in the top-level directory, not the debugger directory. What I've
done here is have the top-level configure.in copy this file to
debugger; acinclude.m4 is also added to the bashdb tarball:
bash-2.05b-bashdb-xxx.tar.gz. I considered adding it to bootstrap.sh,
but then changes in the top-level acinclude.m4 wouldn't get reflected
below. Another possibility would be to set the ac macro directory with
-I to include the top-level directoyr. But again this makes the debugger
less independent.

Finally, I've removed debugger/dbg-main.inc from CVS (although it's
still in the Attic for CVS) since this is now derived from
dbg-main.inc.in.

As always if you have improvments, problems with this, comments, or
suggestions, let me know.

Re: [Bashdb-devel] Re Autostuff patches.

[Mikael A. <sn...@te...>]

On Tuesday 26 August 2003 05.29, R. Bernstein wrote:
> I hvave made some small additions to the recent good autostuff work.
>
> A little background. The debugger directory I view as an independent
> unit. Right now it needs the bash program from the parent directory
> but hopefully it might not in the future. So I've been trying to keep
> things under debugger self-contained.
>

My we should remove the files build in debugger by the bash configure also ?
More specifically: debugger/dbg-pre.inc and debugger/doc/version.texi.
I understand that those are there to use the version in bash for the version 
in debugger. But if we accept updating version number in both directories we 
can move building those files into debugger also. We could also remove most 
of the debugger specific configure things from the bash directory if we note 
in the README/INSTALL that running ./configure --help=recursive is a good 
idea if you want to know the options available.

> When I did a "make distcheck" in the debugger directory, the tarball
> crated was bash-2.05b.tar.gz. This would be the name for an unmodified
> bash rather than the debugger portion of an enhanced bash. I've
> changed the distribution tarball to bash-2.05b-bashdb-xxx.tar.gz. I
> realize this is a little confusing given the parent directory tarball
> which includes this is bash-2.05b-debugger-xxx.tar.gz. Perhaps that
> tarball name should change to rebash-2.05b-xxx-tar.gz.

The naming conventions are a bit confusing and if anything can be done to make 
clearer what the different packages is, so much better. 

> Another problem in the debugger directory was the fact that if
> autoconf chose to run again it couldn't find acinclude.m4 since that's
> only in the top-level directory, not the debugger directory. 
> What I've
> done here is have the top-level configure.in copy this file to
> debugger; acinclude.m4 is also added to the bashdb tarball:
> bash-2.05b-bashdb-xxx.tar.gz. I considered adding it to bootstrap.sh,
> but then changes in the top-level acinclude.m4 wouldn't get reflected
> below. Another possibility would be to set the ac macro directory with
> -I to include the top-level directoyr. But again this makes the debugger
> less independent.
>

Why not have acinclude.m4 only in debugger and copy it to the
top-level dir ? In this way debugger is almost completely self-contained with 
the above mentioned fixes regarding files built by top-level but used by the 
debugger build.

> Finally, I've removed debugger/dbg-main.inc from CVS (although it's
> still in the Attic for CVS) since this is now derived from
> dbg-main.inc.in.
>

Naturally

> As always if you have improvments, problems with this, comments, or
> suggestions, let me know.
>

/Mikael

Re: [Bashdb-devel] Re Autostuff patches.

[R. B. <ro...@pa...>]

Mikael Andersson writes:
 > 
 > Maybe we should remove the files build in debugger by the bash configure also ?
 > More specifically: debugger/dbg-pre.inc and debugger/doc/version.texi.

Yes, that would be a good thing to do. 

 > I understand that those are there to use the version in bash for the version 
 > in debugger. But if we accept updating version number in both directories we 
 > can move building those files into debugger also. 

I accept this. The bash version change on the order of once every
couple of years. 2.05b hasn't changed all that often. In fact, it
hasn't so far :-).

 > We could also remove most 
 > of the debugger specific configure things from the bash directory if we note 
 > in the README/INSTALL that running ./configure --help=recursive is a good 
 > idea if you want to know the options available.

Fine by me. By not changing things in (re)bash that aren't needed, we
limit the changes that will be needed when the next release comes out
and that would be a good thing.

 > The naming conventions are a bit confusing and if anything can be done to make 
 > clearer what the different packages is, so much better. 

Is rebash-2.05b-xxx and bash-2.05b-bashdb-xxx (or
rebash-2.05b-bashdb-xxx) clearer?

 > Why not have acinclude.m4 only in debugger and copy it to the
 > top-level dir ? In this way debugger is almost completely self-contained with 
 > the above mentioned fixes regarding files built by top-level but used by the 
 > debugger build.

Another great idea. The top-level directory could include via "aclocal
-I debugger" Although debugger can't always assume rebash will be
there, rebash can probably assume that debugger will be around. 

If you can, I'd appreciate it if you make these great
suggestions. Many thanks.