Re: [PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
Igor Pechtchanski wrote: Same as above, but regenerated against cvs HEAD. Thanks, Igor == ChangeLog: 2003-03-18 Igor Pechtchanski [EMAIL PROTECTED] * script.cc (run): Add file_out parameter. Redirect output of subprocess to file, creating the path if necessary. Minimize the script window. (run_script): Add optional to_log boolean parameter. If to_log, redirect output to temporary file and then import it into LOG_BABBLE. (OutputLog): New helper class. (operator): New operation on OutputLog. * script.h (run_script): Add optional to_log parameter. * postinstall.cc (RunFindVisitor::visitFile): Instruct run_script() to log script output. (do_postinstall): Ditto. Applied. Max.
Re: [PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
Christopher Faylor wrote: I don't remember. Are you using the -P option when you update? Nope - you know I saw that though but it says prune empty directories from your local files - nothing about removing files that no longer exist in the repository. Wouldn't that get risky anyways if I add a program to say setup and then update with the -P to get current and it removed the file I just added to my local copy because it didn't exist in the Repository? I'll give it a shot though and see if it helps in the future. bk
Re: [PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
Igor et al, Any one see any reason here why I am having trouble building Setup from HEAD. I have made sure I was updated current and used the -A so I shouldn't have any sticky flags and I even tried checking it out again to get rid of Igor's previously applied patch and I am still getting the following on my W2k laptop and my W95 laptop: then mv .deps/ScanFindVisitor.Tpo .deps/ScanFindVisitor.Po; \ else rm -f .deps/ScanFindVisitor.Tpo; exit 1; \ fi if g++ -mno-cygwin -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION= \\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\setup\ -DVERSIO N=\0\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_ H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 - DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBMINGW32=1 -DHAVE_ERRNO_H=1 -DHAVE_S TRING=1 -DHAVE_STRING_H=1 -I. -I/usr/develop/src/cygwin-apps/setup -I/usr/devel op/src/cygwin-apps/setup/bz2lib -I/usr/develop/src/cygwin-apps/setup/libgetopt++ /include -Werror -Wall -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-p rototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments -g -O2 -MT scr ipt.o -MD -MP -MF .deps/script.Tpo \ -c -o script.o `test -f '/usr/develop/src/cygwin-apps/setup/script.cc' || echo '/usr/develop/src/cygwin-apps/setup/'`/usr/develop/src/cygwin-apps/setup/script cc; \ then mv .deps/script.Tpo .deps/script.Po; \ else rm -f .deps/script.Tpo; exit 1; \ fi /usr/develop/src/cygwin-apps/setup/script.cc: In function `BOOL prepareOutputLog(void*, const String, const char*)': /usr/develop/src/cygwin-apps/setup/script.cc:103: `mkdir_p' undeclared (first use this function) /usr/develop/src/cygwin-apps/setup/script.cc:103: (Each undeclared identifier is reported only once for each function it appears in.) cc1plus: warnings being treated as errors /usr/develop/src/cygwin-apps/setup/script.cc: In function `void run(const char*, const char*, const char*, const String)': /usr/develop/src/cygwin-apps/setup/script.cc:146: warning: unused variable ` void*file_out' /usr/develop/src/cygwin-apps/setup/script.cc:147: warning: unused variable ` DWORD dwCPFlags' /usr/develop/src/cygwin-apps/setup/script.cc:148: warning: unused variable ` BOOL bInheritHandles' /usr/include/c++/3.2/streambuf: At top level: /usr/develop/src/cygwin-apps/setup/script.cc:95: warning: `BOOL prepareOutputLog(void*, const String, const char*)' defined but not used /usr/develop/src/cygwin-apps/setup/script.cc:128: warning: `void closeOutputLog(void*, const char*)' defined but not used /usr/develop/src/cygwin-apps/setup/script.cc:138: warning: `BOOL log_failure_notified' defined but not used make[2]: *** [script.o] Error 1 make[2]: Leaving directory `/usr/develop/obj/i686-pc-cygwin/cygwin-apps/setup' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/develop/obj/i686-pc-cygwin/cygwin-apps/setup' make: *** [all] Error 2 ~ $ Any ideas - anyone? Is HEAD broken and this is a known problem? Bk
Re: [PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
On Wed, Mar 19, 2003 at 03:55:00PM -0500, Igor Pechtchanski wrote: Oh, and Brian, you do know that the regular CVS checkout will not remove locally applied changes, right? You have to move the files out of the way before the checkout for that to happen (or use CVS's edit/unedit feature). Hope I'm not getting too patronizing here, none is implied. Maybe everyone knows this but I use 'cvs update -C' a lot when I want to just get a clean copy of a file. cgf
Re: [PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
Igor Pechtchanski wrote: Oh, and Brian, you do know that the regular CVS checkout will not remove locally applied changes, right? You have to move the files out of the way before the checkout for that to happen (or use CVS's edit/unedit feature). Or cvs co -C. Max.
Re: [PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
Thanks Igor, Max, and CGF. All the suggestions were greatly appreciated and while they did not solve the problem I learned a new option - I thought I had all the good ones for reverting back to head and getting back to current but missed the -C. :-) Got it now though. I also learned from trying to see why the -C didn't help either: that when I revert back to what is in CVS apparently CVS does not remove files that no longer exist in the repository from my current working directory if they still exist there Is this normal or is something flaky on my install? I finally saw the warning that there was a conflict and that Makefile.in ,aclocal.m4 and configure and bz2lib/configure no longer existed in the repository. Once I removed them from my working directory and a couple others that had been in the postinstall patch I tested for Igor and then updated again from CVS I finally got back to what looks like current and setup did compile. Thanks all for the lessons. bk
Re: [PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
On Wed, Mar 19, 2003 at 06:41:12PM -0500, Brian Keener wrote: Thanks Igor, Max, and CGF. All the suggestions were greatly appreciated and while they did not solve the problem I learned a new option - I thought I had all the good ones for reverting back to head and getting back to current but missed the -C. :-) Got it now though. I also learned from trying to see why the -C didn't help either: that when I revert back to what is in CVS apparently CVS does not remove files that no longer exist in the repository from my current working directory if they still exist there I don't remember. Are you using the -P option when you update? cgf
[PATCH] Setup postinstall logging - take X+1
On Sun, 16 Mar 2003, Robert Collins wrote: Igor Pechtchanski wrote: Sorry for the '?' in the subject - I think I lost track... Starting a new count here... :-) On 15 Mar 2003, Robert Collins wrote: Don't worry. What would be good would be to make it start minimized. ... Ok, I've figured out how to hide the console altogether (see attached patch, though the CREATE_NO_WINDOW is probably overkill). Could someone familiar with the Windows CreateProcess mechanism make sure this is ok? Also, this needs testing on Win95 again. Brian? On another note, now that the window is not shown at all, setup simply seems to hang while long-running postinstall scripts (e.g., post-texmf.sh, with run-time of ~2 minutes!) are executed. Perhaps we should a) run postinstall scripts from a separate thread, so that setup at least reacts to Windows events, such as REPAINT, and b) have another dialog saying Running postinstall scripts, perhaps even with a progress bar (even if the bar only reflects progress by scripts executed rather than time -- I'm not sure if it's even possible to correctly reflect temporal progress). That would be nice. A trivial step to take is to minimize, not hide, the window. Then the user will see flicky things happening in their tool bar, which may reduce the panic. Ok, done. The windows won't be flicky, though (a long-running script window will still look hung), and they won't show anything. Good enough for now, I guess. The new one conflicts both with the above and with the cleanup patch I posted today... Unless some of them are committed, it's going to get hairy fast, eh, Rob? ;-) Nay. You'll want to merge in the HEAD script.cc changes though. Yep. If to_log, redirect output to temporary file. (openOutputLog): New helper function. This should return void and throw an exception on failure... OR use a class and set a status member. Ok. I've created an OutputLog class that encapsulates this behavior. I've put the Close() into the destructor. Hopefully this is what you meant. Yep, looking good. The define BUFLEN should be a static const member of the class. Umm, which class? It's only used in static functions. I left it as a #define for now. Err just realised. log.h and log.cc are deprecated. Thats why they have the foo_bar naming style and no classes. It's probably best as an operator for OutputLog (given that it's a layer on top of the log infrastructure) - i.e. LogSingleton::GetInstance()(LOG_PLAIN) file_out; And removing the logfile then becomes part of OutputLog::~OutputLog. Hey this is starting to be too easy :}. Done. Also upgraded to call the current interface instead of the deprecated one. Thanks, but I think this needs testing on Win95 again (for the CreateProcess magic). Ok. Can you make the window minimized, not hidden? Otherwise we should put the requisite UI changes in place first. Rob Did that. However, I've #if 0'd the correct code, and left a TODO there -- I'd like to keep that in place until the UI changes are in. An orthogonal change would be to run the scripts from another thread. I'll look into that (separately). This patch is ready to go in as-is, though (the non-#if 0'd portion *should* work on Win95, according to MSDN). Igor == ChangeLog: 2003-03-18 Igor Pechtchanski [EMAIL PROTECTED] * script.cc (run): Add file_out parameter. Redirect output of subprocess to file, creating the path if necessary. Minimize the script window. (run_script): Add optional to_log boolean parameter. If to_log, redirect output to temporary file and then import it into LOG_BABBLE. (OutputLog): New helper class. (operator): New operation on OutputLog. * script.h (run_script): Add optional to_log parameter. * postinstall.cc (RunFindVisitor::visitFile): Instruct run_script() to log script output. (do_postinstall): Ditto. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune Index: script.cc === RCS file: /cvs/cygwin-apps/setup/script.cc,v retrieving revision 2.6 diff -u -p -r2.6 script.cc --- script.cc 17 Mar 2003 22:23:33 - 2.6 +++ script.cc 18 Mar 2003 15:50:02 - @@ -26,11 +26,12 @@ static const char *cvsid = #include stdlib.h #include unistd.h #include stdio.h -#include log.h +#include LogSingleton.h #include filemanip.h #include mount.h #include io_stream.h #include
[PATCH] Setup postinstall logging - take X+1 (regen against HEAD)
On Tue, 18 Mar 2003, Igor Pechtchanski wrote: On Sun, 16 Mar 2003, Robert Collins wrote: Igor Pechtchanski wrote: Sorry for the '?' in the subject - I think I lost track... Starting a new count here... :-) On 15 Mar 2003, Robert Collins wrote: Don't worry. What would be good would be to make it start minimized. ... Ok, I've figured out how to hide the console altogether (see attached patch, though the CREATE_NO_WINDOW is probably overkill). Could someone familiar with the Windows CreateProcess mechanism make sure this is ok? Also, this needs testing on Win95 again. Brian? On another note, now that the window is not [EMAIL PROTECTED], setup simply seems to hang while long-running postinstall scripts (e.g., post-texmf.sh, with run-time of ~2 minutes!) are executed. Perhaps we should a) run postinstall scripts from a separate thread, so that [EMAIL PROTECTED] reacts to Windows events, such as REPAINT, and b) have another dialog saying Running postinstall scripts, perhaps even with a progress bar (even if the bar only reflects progress by scripts executed rather than time -- I'm not sure if it's even possible to correctly reflect temporal progress). That would be nice. A trivial step to take is to minimize, not hide, the window. Then the user will see flicky things happening in their tool bar, which may reduce the panic. Ok, done. The windows won't be flicky, though (a long-running script window will still look hung), and they won't show anything. Good enough for now, I guess. The new one conflicts both with the above and with the cleanup patch I posted today... Unless some of them are committed, it's going to get hairy fast, eh, Rob? ;-) Nay. You'll want to merge in the HEAD script.cc changes though. Yep. If to_log, redirect output to temporary file. (openOutputLog): New helper function. This should return void and throw an exception on failure... OR use a class and set a status member. Ok. I've created an OutputLog class that encapsulates this behavior. I've put the Close() into the destructor. Hopefully this is what you meant. Yep, looking good. The define BUFLEN should be a static const member of the class. Umm, which class? It's only used in static functions. I left it as a #define for now. Err just realised. log.h and log.cc are deprecated. Thats why they have the foo_bar naming style and no classes. It's probably best as an operator for OutputLog (given that it's a layer on top of the log infrastructure) - i.e. LogSingleton::GetInstance()(LOG_PLAIN) file_out; And removing the logfile then becomes part of OutputLog::~OutputLog. Hey this is starting to be too easy :}. Done. Also upgraded to call the current interface instead of the deprecated one. Thanks, but I think this needs testing on Win95 again (for the CreateProcess magic). Ok. Can you make the window minimized, not hidden? Otherwise we should put the requisite UI changes in place first. Rob Did that. However, I've #if 0'd the correct code, and left a TODO there -- I'd like to keep that in place until the UI changes are in. An orthogonal change would be to run the scripts from another thread. I'll look into that (separately). This patch is ready to go in as-is, though (the non-#if 0'd portion *should* work on Win95, according to MSDN). Igor Same as above, but regenerated against cvs HEAD. Thanks, Igor == ChangeLog: 2003-03-18 Igor Pechtchanski [EMAIL PROTECTED] * script.cc (run): Add file_out parameter. Redirect output of subprocess to file, creating the path if necessary. Minimize the script window. (run_script): Add optional to_log boolean parameter. If to_log, redirect output to temporary file and then import it into LOG_BABBLE. (OutputLog): New helper class. (operator): New operation on OutputLog. * script.h (run_script): Add optional to_log parameter. * postinstall.cc (RunFindVisitor::visitFile): Instruct run_script() to log script output. (do_postinstall): Ditto. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune Index: script.cc === RCS file: /cvs/cygwin-apps/setup/script.cc,v retrieving revision 2.6 diff -u -p -r2.6 script.cc --- script.cc 17 Mar 2003 22:23:33 - 2.6 +++ script.cc 18 Mar 2003 15:50:02 - @@ -26,11 +26,12
