Menu
▾
▴
bashdb-remake — Development mailing list for GNU make + debugger
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(1) |
Mar
(13) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Masatake Y. <je...@gy...> - 2007-03-22 08:46:25
|
> I have a feeling http://directory.fsf.org is not very well > maintained. It lists the latest version of libcdio as 0.74 from March > '05 while 0.78.2 of late last year is the current release. > > I'm out of town for a week or so. I'll send email to the contact > person listed on that page. However if someone else would mention I'd > apprecitate it. (I have a feeling the bashdb version is also a bit > behind too) I guess fsf people may be busy about trouble at savannah these days. |
|
From: R. B. <ro...@pa...> - 2007-03-22 06:40:09
|
I have a feeling http://directory.fsf.org is not very well maintained. It lists the latest version of libcdio as 0.74 from March '05 while 0.78.2 of late last year is the current release. I'm out of town for a week or so. I'll send email to the contact person listed on that page. However if someone else would mention I'd apprecitate it. (I have a feeling the bashdb version is also a bit behind too) Dave Korn writes: > > > Morning! > > http://directory.fsf.org/remake.html is a bit out of date. It doesn't > mention the 0.62 release yet. Just a heads-up! > > > > cheers, > DaveK > -- > Can't think of a witty .sigline today.... > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bashdb-remake mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-remake > |
|
From: Dave K. <dav...@ar...> - 2007-03-21 10:48:56
|
Morning!
http://directory.fsf.org/remake.html is a bit out of date. It doesn't
mention the 0.62 release yet. Just a heads-up!
cheers,
DaveK
--
Can't think of a witty .sigline today....
|
|
From: R. B. <ro...@pa...> - 2007-03-09 02:32:27
|
Of late I've been getting "shell substitution errors" when running "remake -x". Alas at the time I was getting these, I couldn't investigate. I've just change the '--trace=noshell' option to be like --trace=command but without the shell "set -x" tracing added. The short option for this is '-y'. Having just complained about automake incompatibility, I confess that this is incompatible behavior with the previous --trace=noshell meaning. However as I use remake more, I realize more of that is useful and what isn't and I doubt if anyone ever used --trace=noshell in its former incarnation while at least one person (me) will use it in its current form. |
|
From: R. B. <ro...@pa...> - 2007-03-09 02:05:31
|
> Switching to automake-1.9.6 fixed all the problems and allowed > autogen.sh to > complete successfully. After updating from CVS, 1.10 still doesn't > succeed, > but it's less noisy with the changes you've added. If I get some spare > time > to go into it in detail, I'll send patches for any problems I can fix, but > auto* is not entirely my forte. The fact that on FreeBSD (and other OS's) I see 4 versions of automake and 4 versions autoconf suggest these folks have a real tough time with auto* compatibility. I looked at some of the other warning and error messages from automake. automake kibbutzes that I should use things, like AM_PATH_LISPDIR which I do use. Or maybe I use those differently. Yet, when I go to the automake manual (and here I've always found it easier and more thorough to edit the texinfo source than try to navigate inside info), I don't see a single example of how one is supposed to use AM_PATH_LISPDIR. The only book I know of on this topic "GNU Autoconf, automake and libtool" published by New Riders also is silent on this, and given what was written above and that was published in 2000, it's probably totally out of date. > >> I'm always amazed at how much time I spend feeding and attending to >> the automake system. In fact that's why remake was undertaken. > > It's also just the /only/ way to debug really complex makefiles where > you've > got loads of rules and dependencies being calculated and eval'd at > runtime. > > It's also a very useful learning tool. Stepping through makefiles makes > it > sooo much easier to understand what's going on and what's happening with > complex function calls and multi-line definitions. Using it has allowed > me to > greatly extend my understanding of advanced makefile techniques. Thank > you > very much. > >> Yes, that Dave Korn reports: > ^^^^^^^^^^^^^^^^^^^ > > ;-) I refer you to my current 'From:' line... > > cheers, > DaveK > -- > I have discovered a truly magnificently witty .sigline -- This is not a .sigline |
|
From: Dave 'N. n. t. one!' K. <dav...@ar...> - 2007-03-07 14:47:26
|
On 07 March 2007 13:01, R. Bernstein wrote:
> My mistake - you are correct, there was a log attached. And yes those
> *are* interesting new messages. I've committed a change to reduce some
> of these. I will probably do more later and when I get a computer that
> can have automake 1.10 installed.
Switching to automake-1.9.6 fixed all the problems and allowed autogen.sh to
complete successfully. After updating from CVS, 1.10 still doesn't succeed,
but it's less noisy with the changes you've added. If I get some spare time
to go into it in detail, I'll send patches for any problems I can fix, but
auto* is not entirely my forte.
> I'm always amazed at how much time I spend feeding and attending to
> the automake system. In fact that's why remake was undertaken.
It's also just the /only/ way to debug really complex makefiles where you've
got loads of rules and dependencies being calculated and eval'd at runtime.
It's also a very useful learning tool. Stepping through makefiles makes it
sooo much easier to understand what's going on and what's happening with
complex function calls and multi-line definitions. Using it has allowed me to
greatly extend my understanding of advanced makefile techniques. Thank you
very much.
> Yes, that Dave Korn reports:
^^^^^^^^^^^^^^^^^^^
;-) I refer you to my current 'From:' line...
cheers,
DaveK
--
I have discovered a truly magnificently witty .sigline
|
|
From: R. B. <ro...@pa...> - 2007-03-07 13:00:33
|
My mistake - you are correct, there was a log attached. And yes those *are* interesting new messages. I've committed a change to reduce some of these. I will probably do more later and when I get a computer that can have automake 1.10 installed. So it's now an error to call AC_PROC_CC after AM_INIT_AUTOMAKE (or is it AM_CONFIG_HEADER)? Fine, I'll remove it. And the warning about "immediate" assigments (:=) are a lame attempt to get the make process to speed up. But they've caused programs in BSD's make and even a bug. So out they go. I'm always amazed at how much time I spend feeding and attending to the automake system. In fact that's why remake was undertaken. Yes, that Dave Korn reports: ... > > There was an attachment on that last post, did you receive it correctly? > Can't think of a witty .sigline today.... Not much of a fan of "fortune" either. |
|
From: Dave K. <dav...@ar...> - 2007-03-07 10:23:43
|
On 07 March 2007 03:47, R. Bernstein wrote:
> Dave Korn writes:
> > On 27 February 2007 04:58, R. Bernstein wrote:
> >
> >
> > > If you can try out what's in CVS, I'd appreciate. If you want me to
> > > put out a candidate tarball, let me know. Thanks
> >
> >
> > I checked out CVS HEAD, and autogen.sh fails in multiple interesting
> ways. > Could be an auto* version mismatch? I'm using am 1.10 and ac 2.60.
>
> I've been using automake 1.9.6 and autoconf 2.59, 2.60 and 2.61. Alas
> going to take be a while before I can get that combination of 1.10 and
> 2.60.
Right, fair enough; Cygwin supports switchable auto* versions, so I'll have
another go with 1.9 and let you know.
>
> What are the error messages?
There was an attachment on that last post, did you receive it correctly?
cheers,
DaveK
--
Can't think of a witty .sigline today....
|
|
From: R. B. <ro...@pa...> - 2007-03-07 03:47:32
|
Dave Korn writes: > On 27 February 2007 04:58, R. Bernstein wrote: > > > > If you can try out what's in CVS, I'd appreciate. If you want me to > > put out a candidate tarball, let me know. Thanks > > > I checked out CVS HEAD, and autogen.sh fails in multiple interesting ways. > Could be an auto* version mismatch? I'm using am 1.10 and ac 2.60. I've been using automake 1.9.6 and autoconf 2.59, 2.60 and 2.61. Alas going to take be a while before I can get that combination of 1.10 and 2.60. What are the error messages? Thanks. > -- > Can't think of a witty .sigline today.... I never can. |
|
From: Dave K. <dav...@ar...> - 2007-03-06 16:25:03
|
On 27 February 2007 04:58, R. Bernstein wrote:
> If you can try out what's in CVS, I'd appreciate. If you want me to
> put out a candidate tarball, let me know. Thanks
I checked out CVS HEAD, and autogen.sh fails in multiple interesting ways.
Could be an auto* version mismatch? I'm using am 1.10 and ac 2.60.
cheers,
DaveK
--
Can't think of a witty .sigline today....
|
|
From: R. B. <ro...@pa...> - 2007-03-02 18:46:26
|
I was alerted to a nicer gdb interface that is available in Emacs 23 (and possibly Emacs 22). The Emacs Lisp routines are in file gdb-ui.el and the name of the top-level Emacs command is "gdba" -- however if everything is set right, running "gdb" will run "gdba". I mention in case someone is interested in working on extending either bashdb.el, pydb.el, or mdb.el to make use of the better UI. But beware -- it looks like the underlying mechanism, a gdb "annotation level" setting is going to be changed and phased out with something else. Lament: there are about 6 different and incompatible GUI-to-debugger interfaces. |
|
From: R. B. <ro...@pa...> - 2007-03-01 16:41:30
|
Recently, Yaroslav Halchenko noticed that internationalization in remake is broken because of some erroneous Makefile variable settings. He provided a patch for that and it's been applied. One thought is that if we can get folks to go over translations, perhaps there will be another release. Volunteers? Some other recent changes: * Add a "list" command. Basically same as "target x depends commands" for now. "list -" shows the parent. * Help commands now show short usage. * Ctrl-d leaves debugger * Add Emacs regression test and allow space in filename for MS Windows (Patch adapted from one submitted for pydb) |
|
From: R. B. <ro...@pa...> - 2007-02-27 04:57:35
|
In preparation for the first Debian packaging, I'd like to put out another release of remake soon. The changes are mostly small: * Changes to make more Debian compatibile. * Track some GNU Make 3.81 changes, which include a bugfix and making more strings "const". * Misc bugfixes If you can try out what's in CVS, I'd appreciate. If you want me to put out a candidate tarball, let me know. Thanks |
|
From: R. B. <ro...@pa...> - 2005-12-23 04:26:58
|
Lots of important changes have been made. So a new release is due. One incompatible difference is that the prompt and Emacs command is now called mdb rather than makedb so as not to get confused with the Unix program to create a DBM file. See NEWS for more information. |
|
From: R. B. <ro...@pa...> - 2005-12-17 23:45:11
|
I just came across this situation and the I found the GNU Make debugger helpful in fathoming what was going on. Recently there was the infamous palindromic-version number a release of bashdb. (Well, okay it's close enough: 3.00-0.03). Manfred Tremmel had some problems in packaging it and noticed the documentation hard-coded locations of where bash is. What he did to make this location customized for the particular installation was to have configure replace these strings in bashdb.texi. So he created bashdb.texi.in. It struck me as odd but he also created bashdb.info.in since bashdb.info is derived from bashdb.texi. However I learned later that this was added to get "make distcheck" to work for him. Although I don't doubt that Manfred managed to get this to work, no matter how I tried to merge the patch I was getting an error one way or another. After spending too much time trying to try just another test, I took this as an opportunity to use the GNU Make debugger to help me figure out what's going on. Of course, I have and advantage that when the GNU Make debugger wasn't all as helpful as I would like, I can just add another feature to it. The two things I've just changed in GNU Make are giving a target trace by default and also listing the command arguments passed when there is an error. This is helpful in a "make distcheck" because it was dying in some weird directory several shell levels deep invoked with target names that are not all that obvious. For example, here were the arguments neeeded to debug the target where GNU Make was dying: top_distdir=/home/rocky/src/external-cvs/bashdb-3.00/bashdb-3.00-0.04cvs/_build/bashdb-3.00-0.04cvs distdir=/home/rocky/src/external-cvs/bashdb-3.00/bashdb-3.00-0.04cvs/_build/bashdb-3.00-0.04cvs/doc distdir Right! Like someone in their right mind would be able to figure this out without some help? Okay now going *into* the debug session. Well I learned that one problem could be fixed by setting INFO_DEPS no to refer to $(srcdir) but to the current build directory. There is no such variable for the current build directory, but there is a $(top_builddir), which one can slap a "/doc" to the end of. That got me farther, but then there seems to be the problem that to build bashdb.info, GNU Make wanted to build stamp-vti -- the month and edition number -- in $(srcdir) which of course is not writable. All of this INFO_DEPS and stamp-vti stuff is put in by automake. And it seems to hard-code $(srcdir). Looks like a bug to me in automake, but the whole thing is just so screwy that I wouldn't have a clue if it is or just another case were the user should have known better the quirks of automake. I then realized that is better not to have copies of bashdb.texi and bashdb.info but just write some texinfo variables in a file external to bashdb.texi (same as version.texi does) and have bashdb.texi use them. And that seemed to work. |
|
From: R. B. <ro...@pa...> - 2005-12-17 23:30:51
|
In my last post, I mentioned changing makedb to mdb. Here's one other change that I'm contemplating. I'm thinking about making removing the option -E or --extended-errors and having that output be there by default. There will be a --no-extended-errors option (with no short letter for this). The idea is just that when there is an error we should be giving more useful information and I just don't to always have to enter -E. When I use remake it's for a reason - to track down problem. |
|
From: R. B. <ro...@pa...> - 2005-12-17 23:25:39
|
So far, the test release of ddd with GNU make debugging seems okay. (Okay - there just the vast silence. But I'll take no news as good news.) One of the things though I'm thinking of changing is the debugger name from makedb to mdb. I'm afraid makedb will get confused with the Unix command to make a DBM file. I did a google search on mdb and that seems is free. mdb seems to fit better into the scheme of debuggers such as gdb, adb, jdb, pdb, xdb debuggers. I'll probably have to be a little bit careful here to time a ddd (test) release along with the next remake release. As always, if folks have thoughts and comments, send them along. |
|
From: R. B. <ro...@pa...> - 2005-12-12 14:49:06
|
This is just post some thoughts about the make debugger development. As I've indicated elsewhere, one interesting but tough thing about writing this debugger is understanding the user interface. I am not aware of any other debuggers for Makefiles. What should be shown, , what is helpful and what isn't? (Well for one answer to the last question, I offer GNU's "make -d".) Lacking input from others, I've pretty much had to rely on my own experience, which is I guess good since it means that at least the most annoying things I encounter are fixed (by me) or I just live with it. Rather than try to invent a new world, where possible I've been trying to use familiar debugging and/or language and/or Make concepts. As a result, there's a target stack and file include stack akin to a stack trace of a programming language and "where", "backtrace" or "bt", "T" (the gdb and perldb commands) show this. Recently "step" and "next" were separated as they are in other debuggers. For lack of a better idea, "step" is more fined grained as it is in other debuggers. Here though is an area where things could change based on experience. gdb has "finish" and "return" commands and this is not uncommon among other debuggers. My current thought is to make "finish" turn off tracing, stepping/nexting and run until the end of a Makefile. It seems a little the already existing "continue" (which doesn't turn off tracing). Another possibility I've toyed with for "finish" are finish the list of commands in a target, but there generally aren't more than one command in a target (if that). If one continues the analogy between running a makefile with running a subroutine in a programming language, "return" seems like it would do the same thing as "quit" currently does - terminate immediately. I could change "quit" so that it terminates *all* nested invocations and make "finish" just the last one. In the case that there is only one Makefile these would do the same thing. On a different topic, there's always the annoying an pestering problem of a name. As with bash we need a name for the patched GNU Make -- for bash before 3.0, it was "rebash", and so for GNU Make it is "remake". And there's the prompt name used in the debugger which is generally also the name one would use in GNU Emacs to cause the debugger to get executed. Following bashdb and perldb and pydb (which later seems to have become pdb), I chose makedb. However there is another command called makedb out there to make a DBM file. My current thought is to rename this mdb to follow, gdb, pdb, jdb, xdb, and wdb. A google search for mdb doesn't show anything else that's likely to get confused with this. And lastly there's the compatibility issue. If this were *completely* compatible with GNU Make, there wouldn't be any debugger at all ;-) So there have to be some changes. Largely I've been trying to keep compatible and add options for more function. So in order to get a stack trace on error you have to add an option for this -E or --extended-errors. My current thinking is to make this the default and possibly have an option to *disable* that behavior. Here's another area of incompatibility. In order to make "quit" of nested makefiles *really* mean quit, the easiest thing to do is to have this set a special return code, say 77, which is used in regression tests to indicate a test is to be skipped. Currently GNU Make never gives this exit code back, but I could be wrong and it is possible someone out there relies on a 77 return code from a nested make. In remake what would happen is that remake will see the return code and terminate with that without as much complaint as it normally does. |
1 message has been excluded from this view by a project administrator.
