On Jul 1 14:50, Corinna Vinschen wrote: > On Jul 1 13:46, Corinna Vinschen wrote: > > On Jul 1 13:15, Corinna Vinschen wrote: > > > On Jul 1 11:23, Corinna Vinschen wrote: > > > > I'll have a look, too. The 64 bit version now also misbehaves like the > > > > 32 bit version in terms of showing a broken package list. A first > > > > debugging attempt shows that it now neglects to parse the .ini file at > > > > all for some reason. > > > > > > I found the reason for not finding the local setup.ini file anymore. > > > The much too complex algorithm scans the *entire* tree below the local > > > package dir for a file called SETUP_INI_FILENAME. The problem now is > > > that it compares SETUP_INI_FILENAME against the filename returned by > > > FindFileNext. Since SETUP_INI_FILENAME now includes a path component > > > (x86/x86_64), the search doesn't work anymore. And after that, when it > > > didn't find the file, it scans the entire tree another time to collect > > > file information for all files in the tree to be able to go ahead > > > without setup.ini file. > > > > > > I'm just struggling with the idiotically complex C++ class system. > > > I thought I just simplify the do_fromcwd function to just check for the > > > file, but now I have another weird effect. After setup spends some time > > > in the progress dialog, it suddenly is back to dialog #2, "Choose A > > > Download Source". Incredible how that's possible at all. How I wish > > > setup would have been written in plain C. > > > > There's also IniParseFindVisitor::visitFile called from do_local_ini, > > which *again* scans the entire directory tree. Why on earth does > > setup scan for the ini file instead of just using the given path? > > > > Still digging... > > Here's a patch which should do the trick. I'm deliberately not applying > it so that I don't colide with anything you already have in the loop.
Scratch it. The general idea might be ok, but it just doesn't work if the local dir is not a mirror, but rather the installation directory as fetched via setup itself. In this case, the setup.ini files are not in top-level, but rather one level below top-level. This has to be taken into account. On the other hand, if the local dir is a mirror, there are now four setup.ini files, the 32 bit setup.ini in top-level and the x86 dir, and the 64 bit setup.ini in x86_64 and the 64bit subdirs, and setup will read all four of them. The long loading time was always a bit annoying, but other than that it was no problem, as long as there were only two ini files and the 64 bit file was called setup64.ini. Oh well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
