This is the mail archive of the
cygwin-apps
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
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