Mail Archives: cygwin/2012/03/27/11:19:11
On 27/03/2012 4:36 AM, Corinna Vinschen wrote:
> On Mar 26 22:59, Ryan Johnson wrote:
>> On 26/03/2012 9:40 PM, Jason Tishler wrote:
>>> New News:
>>> === ====
>>> I have updated the version of rebase to 4.1.0-1. The tarballs should be
>>> available on a Cygwin mirror near you shortly.
>>>
>>> The following are the changes since the previous release:
>>>
>>> * Add rebase/rebaseall touch file (i.e., -t option) support.
>>>
>>> * Add rebaseall setup (i.e., -p option) support.
>>>
>>> * Add .oct to the default rebaseall suffix list.
>> I've been meaning to ask... but maybe the above-mentioned -p flag
>> obsoletes it now: What's the most efficient way to rebase after
>> running setup? We've had the rebase db for a while now, so running
>> rebaseall seems like overkill. Only the newly downloaded dlls need
> Now that the new rebase is out, I'm going to create an _autorebase
> package which will automatically call rebaseall at the end of a
> successful run of setup, if that run also updated existing DLLs or
> came with new DLLs.
>
> In some cases this might take two minutes or so at the end of a setup
> run, but at least we should see less rebase problems in future.
That will be awesome.
> The most efficient way would be to change rebaseall so that only
> DLLs are given to rebase which are updated or new. But rebaseall
> would still have to search the files in /etc/setup. And rebase
> still opens every DLL in the DB and from the command line to see
> if the DB and reality are still in sync, and to decide which DLLs
> have to be rebased and which are not. So I'm not sure you can
> make it much faster, unless you make the algorithm in rebase itself
> faster.
Honestly, I don't care if it's slow, just so it works. The problem right
now -- at least in my naive invocations -- is that rebaseall attempts to
rebase things which are in-use. Perhaps the initial in-sync-ness check
opens the file in exclusive mode and fails? I know the in-use files were
still in sync because they were when setup started. Setup didn't
complain about anything and I didn't start any new processes after it
completed.
Another idea: right now rebase[all] seems to give up if it encounters an
in-use file. Can it just skip the file and keep going?
> Needless to say that the ultimately most efficient way would be
> to find a method to avoid rebase problems after fork at all. The
> last attempt at it looked promising at first, but then again...
> http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073
That did look promising... I only run in a console under duress, but
losing LoadLibrary is a deal-breaker.
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -