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

-- 
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]