This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86/ -> ./ symlink

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]