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: Tue, 2 Jul 2013 10:49:17 +0200
- Subject: Re: x86/ -> ./ symlink
- References: <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> <20130701151815 dot GA4763 at calimero dot vinschen dot de> <20130701164017 dot GB4763 at calimero dot vinschen dot de> <20130701184551 dot GC2080 at ednor dot casa dot cgf dot cx>
- Reply-to: cygwin-apps at cygwin dot com
On Jul 1 14:45, Christopher Faylor wrote:
> On Mon, Jul 01, 2013 at 06:40:17PM +0200, Corinna Vinschen wrote:
> >On Jul 1 17:18, Corinna Vinschen wrote:
> >> On Jul 1 14:50, Corinna Vinschen wrote:
> >> > 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.
> >(Hopefully last) followup to my monologue:
> >I think I have a solution now. I detached the "x86" and "x86_64" target
> >subdirs from SETUP_INI_FILENAME and introduced a SETUP_INI_DIR instead.
> >Changing the Find class to allow a maximum tracking depth, plus an
> >additional check to make sure the found file is the one from the target
> >subdir, this should work now in all circumstances.
> >See below. Again, not applied to not collide with what you have.
> I don't have anything like this in the pipeline but this is pretty much
> what I concluded that I needed to do while laying in bed last night and
> in the special thinking room.
> I didn't look at the patch. Does it just put setup.ini right under the
> mangled download url directory*? That's what I was going to do.
No, to the contrary. The patch will make setup only use setup.ini files
which are in a $target subdir and it will write the file to a $target
subdir locally. If you put the setup.ini file right under the url dir,
you won't be able to use the same download directory for 32 and 64 bit.
Having said that, given how setup works, mainly the way how the
subdirectories of the install dir are scanned for ini files, I'm
wondering if we shouldn't better introduce a clear naming distinction
between the target-specific ini files. Rather than adding x86
and x86_64 subdirs, we may be better off to rename the ini files to
This way, there's no chance that a x86 installation picks up a x86_64
ini file and vice versa, and the directory layout of the local
installation dir doesn't matter at all.
> But, anyway, if you have something that works please check it in.
Will do. Changing the subdir requirement back to a .ini name change
is easy enough, should you agree.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com