This is the mail archive of the
mailing list for the Cygwin project.
Re: x86/ -> ./ symlink
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 1 Jul 2013 17:18:15 +0200
- Subject: Re: x86/ -> ./ symlink
- References: <878v1zo0q6 dot fsf at Rainer dot invalid> <20130629080152 dot GU2378 at calimero dot vinschen dot de> <20130629164600 dot GA1479 at ednor dot casa dot cgf dot cx> <20130629175908 dot GA5778 at ednor dot casa dot cgf dot cx> <20130630093846 dot GA2000 at calimero dot vinschen dot de> <20130630223132 dot GA5077 at ednor dot casa dot cgf dot cx> <20130701092301 dot GD2000 at calimero dot vinschen dot de> <20130701111532 dot GA20414 at calimero dot vinschen dot de> <20130701114624 dot GE2000 at calimero dot vinschen dot de> <20130701125056 dot GF2000 at calimero dot vinschen dot de>
- Reply-to: cygwin-apps at cygwin dot com
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
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