Hi Charles,
Charles Wilson wrote:
Roumen Petrov wrote:
[SNIP]
If you can come up with a mechanism to use absolute paths in dlname,
which does not break any of the known installation modes, works whether
the installation tree(s) are pre-created or NOT, and whether the final
installation tree
Dave Korn wrote:
Roumen Petrov wrote:
The calculation or relative path to dll is based on function XXX_abspath
that may produce wrong results.
No it doesn't. Like any function, it produces the correct results when
given valid inputs, but if you give it bad input, you get GIGO.
:) :)
Roumen Petrov wrote:
Dave Korn wrote:
*Your suggestion to use realpath instead of abspath
requires magic or time-travel before it is even possible, which is why
I will
waste no time on it.*
Reading all above seems to my you mix mail threads and/or lists.
Nonsense, I'm not engaged in
Roumen Petrov wrote:
I'm concerned that we can't implement a working portable(cross-platform)
relative path calculation.
In the general case, Roumen, you are correct: there IS no portable
mechanism to compute relative paths when non-portable constructs such as
symbolic links are/may-be
Charles Wilson wrote:
Roumen Petrov wrote:
Dave Korn wrote:
Roumen Petrov wrote:
[SNIP]
Why? abspath != realpath. That's the point. If you're arguing that
all GNU installation tools should use realpath to canonicalize all paths
before use, well...maybe that discussion should be held, in
Roumen Petrov wrote:
The calculation or relative path to dll is based on function XXX_abspath
that may produce wrong results.
No it doesn't. Like any function, it produces the correct results when
given valid inputs, but if you give it bad input, you get GIGO. I suggest you
go read the
Hi Dave,
sorry for making you go through another round.
Except for the sed issues the following nits are all mechanical, and it
would suffice if you re-checked only your new tests and only on one of
the affected systems.
I consider the patch ready after this round, but I will probably leave a
Ralf Wildenhues wrote:
Hi Dave,
sorry for making you go through another round.
:-/ That'll teach me to say unless there's anything else?
+pathcar=s,^/\([^/]*\).*$,\1,
+pathcdr=s,^/[^/]*,,
+removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
+collapseslashes=s,/\+,/,g
\+ is a GNU sed
* Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST:
Ralf Wildenhues wrote:
sorry for making you go through another round.
:-/ That'll teach me to say unless there's anything else?
Hehe.
\+ is a GNU sed extension, \{1,\} is Posix (two instances).
Nested \( \) are not
Dave Korn wrote:
So, here I hope is the final respin. Built and tested on i686-pc-cygwin and
i686-pc-linux-gnu with no regressions and all new tests passing (see below sig
separator for details).
libtool/ChangeLog:
* Makefile.am (TESTSUITE_AT): Add bindir.at.
*
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
As I explained to Eric, this function implements 'abspath', not 'realpath',
and given that we can't assume any of the directories even exist when
Ralf Wildenhues wrote:
* Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST:
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT
$curdir/bin/main$EXEEXT], [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
This one should work
Dave Korn wrote:
Guess I'll have to `ls *foo*0*` them and test -z the output, that
should work.
Nope, may have whitespace. Is checking the return status of ls portable?
cheers,
DaveK
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
As I explained to Eric, this function implements 'abspath', not 'realpath',
and given that we can't assume any of the directories
Roumen Petrov wrote:
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
As I explained to Eric, this function implements 'abspath', not
'realpath',
and given that we can't assume
Roumen Petrov wrote:
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
this function implements 'abspath', not 'realpath',
^^^
16 matches
Mail list logo
