From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: mingw configure failure workaround |
Date: | 2004-05-03 15:38:00 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE34B900@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> tested with autoconf 2.59.
>
> Unfortunately, it does not. It does try to copy if a link
> fails, unlike what we have now:
>
> ln -s $ac_rel_source $ac_dest 2>/dev/null ||
> ln $srcdir/$ac_source $ac_dest 2>/dev/null ||
> cp -p $srcdir/$ac_source $ac_dest ||
>
> We don't have the last line, which must have been added since
> autoconf 2.53.
>
> However, the problem is that the first line will actually
> appear to have succeeded, i.e. MSys's ln is lying to us ;-(
Ok, how's this for a really ugly solution:
* Provide our own ln (in the form of a shellscript, even)
* Make sure this one gets in ahead of the system supplied one in the
path (from the code above it looks like it's not calling it with a
specific path, so just force-adding somethign to the path of configure
should work?)
This ln can then do a cp directly, and not even bother trying the mingw
ln function which we know will only do cp anyway if it succeeds.
If there is a less ugly solution to be had, by all means stay away from
thsi oen :-)
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2004-05-03 15:40:45 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long |
Previous Message | Paul Ramsey | 2004-05-03 15:33:19 | Re: PostgreSQL pre-fork speedup |