bashdb-devel

[Bashdb-devel] Status update: Auto... related changes.

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

A short status update on auto... changes:

I'll post a patch as soon as possible, planned to do it today but stumbled 
upon a few more bugs. And it'll probably take me at least a few day to work 
it out.

Currently working on:
* Remove deprecated autoconf and automake constructs.

Pending:
* Trying to install empty file (or directory). Creates an install.gz file

Won't adress in this fix:
* manpage names same as executables ( if executable names are transformed )
* builtins and rbash plain text files is not generated correctly

Done but not commited yet:
* configurable package name. (Environment variable)
* configurable executable names. (Standard automake/autoconf way with sed 
scripts)
* bootstrap.sh executed auto... commands in odd order ( Always gave me an 
error on first run )
* script files now installs in pkgdatadir. Note: Not everybody agrees on this 
interpretation of FHS although i belive it make sense ( and obviously also 
those who make emacs and perl )
* No more hardcoded paths in script-files. As a consequence dbg-main.inc is to 
be replaced with dbg-main.inc.in
* A location for bashdb specific macros (acinclude.m4)

/Mikael

[Bashdb-devel] Status update: Auto... related changes.

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

Mikael Andersson reports: 
 > A short status update on auto... changes:

Thanks for the update.

 > 
 > I'll post a patch as soon as possible, planned to do it today but stumbled 
 > upon a few more bugs. And it'll probably take me at least a few day to work 
 > it out.

No hurry. The next release is basically yours. :-) My own opinion is it's
preferable to have it done correctly or thoroughly than done soon. 

 > 
 > Currently working on:
 > * Remove deprecated autoconf and automake constructs.

Always good. At least until the next release of autoconf and automake
which no doubt will change everything around again. That's what makes
working with these so much fun and a such a devoted effort. ;-) If you
mean renaming bash's configure.in to configure.ac, I hesitated there
because things in the top-level directory should be merged into bash
2.05b and it is not clear at present no one really knows what will
really happen. You'll find in the *debugger* directory that there is a
configure.ac and not configure.in. The debugger directory could be
split off as a separate package if/when bash changes are merged into
bash.

 > 
 > Pending:
 > * Trying to install empty file (or directory). Creates an install.gz file

I don't understand this is about. Why is it desired to install a empty
file or directory?

 > Won't adress in this fix:
 > * manpage names same as executables ( if executable names are transformed )

It doesn't seem that hard to address if there other packages can deal
with. I wonder how other packages address this?

 > * builtins and rbash plain text files is not generated correctly

Do you mean plain text help files the builtins are generated (correctly)
now and in the future they won't be?

 > 
 > Done but not commited yet:
 > * configurable package name. (Environment variable)
 > * configurable executable names. (Standard automake/autoconf way with sed 
 > scripts)

Great. 

 > * bootstrap.sh executed auto... commands in odd order ( Always gave me an 
 > error on first run )

I think this script I had to write when I put this in CVS. There is also autogen.sh which
runs bootstrap.sh + configure. I've never understood the auto system well enough, so I would
not be surprised if it has problems/bugs. Anything you can do to improve it is welcome.

 > * script files now installs in pkgdatadir. Note: Not everybody agrees on this 
 > interpretation of FHS although i belive it make sense ( and obviously also 
 > those who make emacs and perl )

I don't understand what FHS stands for. As long as things are self
consistent and those folks who have strong opinions on such matters
can configure this (and I don't think I'm in that category), then I
don't think there should be a problem. 

 > * No more hardcoded paths in script-files. As a consequence dbg-main.inc is to 
 > be replaced with dbg-main.inc.in
 > * A location for bashdb specific macros (acinclude.m4)

Again all good. 

Thanks for taking this mess on. 

Re: [Bashdb-devel] Status update: Auto... related changes.

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

On Tuesday 19 August 2003 10.25, R. Bernstein wrote:
> Mikael Andersson reports:
>  > A short status update on auto... changes:
>
> Thanks for the update.
>
>  > I'll post a patch as soon as possible, planned to do it today but
>  > stumbled upon a few more bugs. And it'll probably take me at least a few
>  > day to work it out.
>
> No hurry. The next release is basically yours. :-) My own opinion is it's
> preferable to have it done correctly or thoroughly than done soon.
>
>  > Currently working on:
>  > * Remove deprecated autoconf and automake constructs.
>
> Always good. At least until the next release of autoconf and automake
> which no doubt will change everything around again. That's what makes
> working with these so much fun and a such a devoted effort. ;-) If you
> mean renaming bash's configure.in to configure.ac, I hesitated there
> because things in the top-level directory should be merged into bash
> 2.05b and it is not clear at present no one really knows what will
> really happen. You'll find in the *debugger* directory that there is a
> configure.ac and not configure.in. The debugger directory could be
> split off as a separate package if/when bash changes are merged into
> bash.
>
>  > Pending:
>  > * Trying to install empty file (or directory). Creates an install.gz
>  > file
>
> I don't understand this is about. Why is it desired to install a empty
> file or directory?
It's not desirable but in the Makefile.in in the doc directory a lot of 
strange things happen. Check the diff attached for my changes of this file.

>
>  > Won't adress in this fix:
>  > * manpage names same as executables ( if executable names are
>  > transformed )
>
> It doesn't seem that hard to address if there other packages can deal
> with. I wonder how other packages address this?
>
I'll try to dig up some example here and see what i can find.

>  > * builtins and rbash plain text files is not generated correctly
>
> Do you mean plain text help files the builtins are generated (correctly)
> now and in the future they won't be?
>
They are not generated correctly on my system because of the ".so man1/bash.1" 
include in the groff source. For it to succed it needs ".so bash.1". But if 
the file (eg buildins.1 is installed i belive it needs ".so man1/bash.1"

>  > Done but not commited yet:
>  > * configurable package name. (Environment variable)
>  > * configurable executable names. (Standard automake/autoconf way with
>  > sed scripts)
>
> Great.
>
>  > * bootstrap.sh executed auto... commands in odd order ( Always gave me
>  > an error on first run )
>
> I think this script I had to write when I put this in CVS. There is also
> autogen.sh which runs bootstrap.sh + configure. I've never understood the
> auto system well enough, so I would not be surprised if it has
> problems/bugs. Anything you can do to improve it is welcome.
>
>  > * script files now installs in pkgdatadir. Note: Not everybody agrees on
>  > this interpretation of FHS although i belive it make sense ( and
>  > obviously also those who make emacs and perl )
>
> I don't understand what FHS stands for. As long as things are self
> consistent and those folks who have strong opinions on such matters
> can configure this (and I don't think I'm in that category), then I
> don't think there should be a problem.

It's simply a filesystem hiearchy standard which is atleast somewhat sane  :)
http://www.pathname.com/fhs/2.2/

>
>  > * No more hardcoded paths in script-files. As a consequence dbg-main.inc
>  > is to be replaced with dbg-main.inc.in
>  > * A location for bashdb specific macros (acinclude.m4)
>
> Again all good.
>
> Thanks for taking this mess on.
>
>
Diff of Makefile.in. If you generate a Makefile from the current Makefile.in, 
note the defintions of INSTALL and INSTALL_DATA. On my machine they both
contained install -c ... so it ran install -c install -c. The other fix below 
is install-info trying to install a directory instead of bashdb.info


cvs -z3 diff  "Makefile.in"
Index: Makefile.in
===================================================================
RCS file: /cvsroot/bashdb/bashdb/doc/Makefile.in,v
retrieving revision 1.13
diff -u -3 -p -r1.13 Makefile.in
--- Makefile.in	1 Jun 2003 14:36:56 -0000	1.13
+++ Makefile.in	19 Aug 2003 15:27:00 -0000
@@ -235,23 +235,23 @@ installdirs:
 
 install: info installdirs
 	@list='$(MAN1FILES)'; for p in $$list; do \
-	  $(INSTALL) $(INSTALL_DATA) $(srcdir)/$$p.1 $(DESTDIR)$(man1dir) ; \
+	  $(INSTALL_DATA) $(srcdir)/$$p.1 $(DESTDIR)$(man1dir) ; \
 	done
 # uncomment the next line to install the builtins man page
 #	-$(INSTALL_DATA) $(srcdir)/builtins.1 
$(DESTDIR)$(man1dir)/bash_builtins${man1ext}
 	@list='$(INFOFILES)'; for p in $$list; do \
-	  $(INSTALL) $(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(infodir) ; \
+	  $(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(infodir) ; \
 	done 
 # run install-info if it is present to update the info directory
 	if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \
 	  for p in $(INFOFILES); do \
-		install-info --dir-file=$(DESTDIR)$(infodir)/dir $(DESTDIR)$(infodir); \
+		install-info --dir-file=$(DESTDIR)$(infodir)/dir $(DESTDIR)$(infodir)/$$p; 
\
 	  done ; \
 	else true; fi
 # if htmldir is set, install the html files into that directory
 	-if test -n "${htmldir}" ; then \
 	   @list='$(HTMLFILES)'; for p in $$list; do \
-f		$(INSTALL) $(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(htmldir) ; \
+f		$(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(htmldir) ; \
 	   done; \
 	fi
 

Re: [Bashdb-devel] Status update: Auto... related changes.

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

I just took a look at the doc/Makefile.in patches and all of these
mistakes look like they are mine which were made early in CVS which
are not in the official bash 2.05b (between version 1.1 and 1.2). 

One difference I note is that I have the Info generated as bash.info
while bash 2.05b has it going in as bashref.into. I'm not sure why I
made that change and perhaps that should go back.

At any rate I think you should check that in (since after all these
are really fixes you've found) and at the same time you can test that
CVS commit works.