This is the mail archive of the
mailing list for the Cygwin project.
Re: x86/ -> ./ symlink
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 1 Jul 2013 14:45:51 -0400
- Subject: Re: x86/ -> ./ symlink
- References: <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> <20130701151815 dot GA4763 at calimero dot vinschen dot de> <20130701164017 dot GB4763 at calimero dot vinschen dot de>
- Reply-to: cygwin-apps at cygwin dot com
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.
But, anyway, if you have something that works please check it in.
*I dislike the mangled download directory almost as much as I dislike
the maze of twisty little packages in the setup source code.