messy bash.git history
Chet, I've noticed that your 'devel' branch in bash.git is rather messy; basically lots of commits that snapshot the state of a directory, then a followup commit that removes leftovers and stray files. If you were to set your .gitignore file (to make your exclusion list public) or your .git/info/exclude file (to keep your exclusion list local to your repository) to the file names that you normally clean up (such as *~, *.old, *.save, *.orig; one per line), then your imports wouldn't create those files in the first place, you wouldn't have to do cleanup commits, and it would be easier to follow the history to see what really changed without being inundated by all the noise on the side file creation-deletion loops. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: readline 6.3 violates POSIX by doing #undef setjmp
On 01/23/2015 04:31 PM, Eric Blake wrote: > Thus, the following is the minimal patch for Cygwin to have correct > compilation (both setjmp and setjmp_nosigs usage points in bash will > have identical behavior). Although I still think that you ought to fix > more than just Cygwin by auditing and eradicating all uses of setjmp in > favor of sigsetjmp to begin with, that's a bigger patch to bash, so I'm > not going to bother with doing it myself now that I have a correct > environment on cygwin. > > diff --git i/lib/readline/posixjmp.h w/lib/readline/posixjmp.h > index 98cf718..1af5de7 100644 > --- i/lib/readline/posixjmp.h > +++ w/lib/readline/posixjmp.h > @@ -1,6 +1,6 @@ > /* posixjmp.h -- wrapper for setjmp.h with changes for POSIX systems. */ > > -/* Copyright (C) 1987,1991 Free Software Foundation, Inc. > +/* Copyright (C) 1987,1991,2015 Free Software Foundation, Inc. > > This file is part of GNU Bash, the Bourne Again SHell. > > @@ -27,7 +27,7 @@ > > #if defined (HAVE_POSIX_SIGSETJMP) > # define procenv_t sigjmp_buf > -# if !defined (__OPENNT) > +# if !defined (__OPENNT) && !defined (__CYGWIN__) > #undef setjmp > #define setjmp(x)sigsetjmp((x), 1) > #define setjmp_nosigs(x) sigsetjmp((x), 0) I see you applied something slightly different in the 'devel' branch of bash.git (might have been nice to reply to this thread, instead of making me research for myself if the patch was accepted), but alas, the build is still broken on cygwin: ./lib/readline/libreadline.a(util.o): In function `rl_abort_internal': /home/eblake/bash/lib/readline/util.c:115: undefined reference to `siglongjmp' collect2: error: ld returned 1 exit status You need to do the same thing for longjmp as you did for setjmp (that's another situation where #undef longjmp puts you in portability hot water). Would you like me to prepare a patch? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: messy bash.git history
On 06/02/15 21:13, Eric Blake wrote: > Chet, > > I've noticed that your 'devel' branch in bash.git is rather messy; > basically lots of commits that snapshot the state of a directory, then a > followup commit that removes leftovers and stray files. If you were to > set your .gitignore file (to make your exclusion list public) or your > .git/info/exclude file (to keep your exclusion list local to your > repository) to the file names that you normally clean up (such as *~, > *.old, *.save, *.orig; one per line), then your imports wouldn't create > those files in the first place, you wouldn't have to do cleanup commits, > and it would be easier to follow the history to see what really changed > without being inundated by all the noise on the side file > creation-deletion loops. > That would help, but it would be better to have a standard git repo with a commit per change. I understand that existing history can't be converted to a git repo, but that shouldn't preclude pushing standard commits to that git repo from now on. It would really help in verification of bugs/fixes, and would also ease contributions to bash using standard tooling. thanks, Pádraig.
