bashdb-devel

[Bashdb-devel] ugly code in install-data-hook

[Eric B. <eb...@by...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The following code in Makefile.am's install-data-hook has a severe bug,
and I'm not sure how to work around it.  Furthermore, the code is tied to
GNU make, and is not portable to other make programs:

#
# This is ugly. Bash 3.0 requires things to be different than where
# many OS's would want to put bash debugger scripts or where a user
# may have asked for this to be put. It's wrong in the directory
# names it uses and for the name of the main include.
# So... using the place that configure determined bash
# wants this to be put, (BASHDB_MAIN), we try to remove any existing files
# before making a symbolic link to it. Also if was in a directory
# (containing perhaps old code), that gets removed and a symbolic link
# is added or relocated if there was another symbolic link. Finally
# the basename that bash wants to use is symlinked to the main name
# that this distribution uses dbg-main.inc, unless those are the same.
#
OLD_DIR :=$(dir @BASHDB_MAIN@)
OLD_MAIN:=$(notdir @BASHDB_MAIN@)
PARENT_DIR:=$(dir $(OLD_DIR))
install-data-hook:
	@if test -e @BASHDB_MAIN@ ; then \
	  if test $(OLD_MAIN) != dbg-main.inc ; then \
	    $(RM) @BASHDB_MAIN@ || true; \
          fi; fi
	@if test -d $(DESTDIR)$(OLD_DIR) ; then \
	     $(RM) -fr $(DESTDIR)$(OLD_DIR:/=) || true; \
	else if test -L $(DESTDIR)$(OLD_DIR:/=) ; then \
	     $(RM) -f $(DESTDIR)$(OLD_DIR:/=) || true; \
	fi; fi
	test -d $(DESTDIR)$(PKGDATADIR) || $(mkdir_p) $(DESTDIR)$(PKGDATADIR)
	$(LN_S) $(DESTDIR)$(PKGDATADIR) $(DESTDIR)$(PARENT_DIR:/=) || true
	@if test dbg-main.inc != $(OLD_MAIN) ; then \
	  ( if cd $(DESTDIR)$(pkgdatadir) ; then \
	     test -e $(OLD_MAIN) && $(RM) $(OLD_MAIN); \
	     $(LN_S) dbg-main.inc $(OLD_MAIN) || \
	     echo "WARNING: I'm having trouble letting bash know where the
debugger is. Use the bashdb script only." ; \
	  fi ) \
	fi


In the case where bash was configured with DEBUGGER_START_FILE set in the
environment to the same location as where I configured bashdb
- --with-bashdb-main, then OLDDIR and PKGDATADIR are the same directory, and
'make install' proceeds to install all the dbg-*.inc files, then calls the
hook which removes the directory containing all the newly installed
dbg-*.inc files, leaving a crippled installation.

This is the case on cygwin because I maintain both the bash and bashdb
packages, so I can coordinate the two configure runs to use the same
location for the debugger main entry point.

An informative trace from 'make install', where I manually replaced all
the instructions in install-data-local with echos of what would otherwise
run, shows:

...
 /usr/bin/install -c -m 644 '/tmp/bashdb-3.1-0.04/dbg-set-d-vars.inc'
'/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb/dbg-set-d-vars.inc'
make  install-data-hook
make[3]: Entering directory `/tmp/bashdb-3.1-0.04/.build'
if test -e /usr/share/bashdb/bashdb-main.inc ; then  if test
bashdb-main.inc != dbg-main.inc ; then  /usr/bin/rm
/usr/share/bashdb/bashdb-main.inc || true;  fi; fi
if test -d /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb/ ; then
/usr/bin/rm -fr /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true;  else
if test -L /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb ; then  /usr/bin/rm
- -f /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true;  fi; fi
echo 'test -d /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || mkdir -p --
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb'
test -d /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || mkdir -p --
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb
echo 'ln -s /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true'
ln -s /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true
if test dbg-main.inc != bashdb-main.inc ; then  ( if cd
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb ; then  test -e
bashdb-main.inc && /usr/bin/rm bashdb-main.inc;  ln -s dbg-main.inc
bashdb-main.inc ||  echo "WARNING: Im having trouble letting bash know
where the debugger is. Use the bashdb script only." ;  fi )  fi

- --
Life is short - so eat dessert first!

Eric Blake             eb...@by...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD9V9H84KuGfSFAYARAvcmAKC8r4CR4I0qu3XgBOTUKJCtTc6mRQCgvNYy
BxR1Np+tfJsu5UUFKaRqifE=
=CYLz
-----END PGP SIGNATURE-----

[Bashdb-devel] Re: ugly code in install-data-hook

[Eric B. <eb...@by...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eric Blake on 2/16/2006 10:29 PM:
> The following code in Makefile.am's install-data-hook has a severe bug,
> and I'm not sure how to work around it.  Furthermore, the code is tied to
> GNU make, and is not portable to other make programs:

But, as long as we are requiring GNU make, the attached hack seemed to do
the trick (it depends on the -ef operator in GNU coreutils' test, and I
don't know of any other easy way to prove that /foo and /foo/ are (not)
the same directory in makefile syntax).  Please don't install this hack as
an official patch; rather, use it as a starting point for what needs to be
improved in this hook to overcome its current bug.

- --
Life is short - so eat dessert first!

Eric Blake             eb...@by...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD9WJ/84KuGfSFAYARAj1QAKDCIEs5MHI190v+HctXaPWhjvd8eACg1Kq4
bk4jPjc9hkUwImixfjI41Hs=
=PBlz
-----END PGP SIGNATURE-----

[Bashdb-devel] Re: ugly code in install-data-hook

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

Eric Blake writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > According to Eric Blake on 2/16/2006 10:29 PM:
 > > The following code in Makefile.am's install-data-hook has a severe bug,
 > > and I'm not sure how to work around it.  

Maybe a start is to describe what the bug is and what's severe about
it. While we are being severe, I'd say the fact that bash has a
hardcoded (and usually wrong) location of where the debugger init file
is pretty lame. ;-) 

It doesn't take much imagination to say change --debugger to add an
optional argument for where the init script is. The idea was that
perhaps there could be more than this debugger (or different versions
of this debugger) around. It would also allow users to install bashdb
without (generally) needing system-level access or installing their
own bash. If someone want's to make a suggestion using bashbug please
do. I've had my fill of bashbug reporting.

 > > Furthermore, the code is tied to
 > > GNU make, and is not portable to other make programs:

You are correct, it is a deficiency. But given the situtation there
aren't that many choices. I suppose one could write some sort of
standalone script that does the install hook thing. I suppose that would
be better in that it would be Makefile independent.

 > But, as long as we are requiring GNU make, the attached hack seemed to do
 > the trick (it depends on the -ef operator in GNU coreutils' test, and I
 > don't know of any other easy way to prove that /foo and /foo/ are (not)
 > the same directory in makefile syntax).  

Actually "test -ef" is probably more reliable than whatever could be
done in some sort of Makefile mechanism which as you say probably
wouldn't translate to make's other than this or that one.

 > Please don't install this hack as
 > an official patch; rather, use it as a starting point for what needs to be
 > improved in this hook to overcome its current bug.

If you don't want this installed, it won't be installed. That's your
call.  As for improving, do we have any volunteers out there?