Le 10 janv. 09 à 22:25, Ralf Wildenhues a écrit :
BTW, your editor seems to both reformat existing code, and use
different indenting strategy for new code. Hmm.
Yeah, I know. But fixing the indentation issues progressively does
not
seem bad to me. I certainly don't want these useless
Le 14 janv. 09 à 11:16, Akim Demaille a écrit :
Le 10 janv. 09 à 22:25, Ralf Wildenhues a écrit :
So what do you recommend to store persistent information? A
function
that returns some static variable (sort of a singleton)? Or an
additional argument everywhere (gee...). Maybe I can do
Hi,
kopensolaris-gnu was accepted in GNU config. I adjusted my patch to use
that, see attachment.
Can it be included now?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
On Mon, 19 Jan 2009, Akim Demaille wrote:
I have worked for years with the same set up as you, using an much TAB as is
possible. But I read someday something that Jim wrote about this topic, in
which he was advocating the no-tab approach, and I was convinced. What
changed my viewpoint was
Hi Peter,
* Peter Rosin wrote on Sat, Jan 17, 2009 at 12:42:34AM CET:
In the localization test, the output of the compiler is compared
with the grepped output of the compiler when run through libtool.
MSVC outputs its messages with \r\n, but the grep in the above
strips that down to just \n
Pushed to master, sorry for the long delay.
The long line in ltmain.m4sh is actually necessary in order for
libtool --version
to work correctly. Will address in a followup patch.
Cheers,
Ralf
Bump copyright years.
* ChangeLog.2008: New, rotated from ...
* ChangeLog: ...
* Ralf Wildenhues wrote on Mon, Jan 19, 2009 at 09:40:20PM CET:
The long line in ltmain.m4sh is actually necessary in order for
libtool --version
to work correctly. Will address in a followup patch.
OK to push?
Thanks,
Ralf
func_version copes with multi-line copyright headers.
Hi Roumen,
* Roumen Petrov wrote on Sun, Jan 04, 2009 at 02:56:54PM CET:
--- a/tests/convenience.at
+++ b/tests/convenience.at
@@ -263,7 +263,7 @@ EOF
# libgcj.spec or unable to find it. Skip this test for them.
if test $i -eq 1; then
AT_CHECK([$GCJ $GCJFLAGS -c foo1.java ||
Hi Ralf,
Den 2009-01-19 21:35 skrev Ralf Wildenhues:
Ok to push? Or should I just push it to the pr-msvc-support branch
for now?
I think we shouldn't be constantly rebasing pr-msvc-support. I think
instead when we can't decide soonish whether to merge it into master or
to redo it (because it
Hello,
I've had this really small patch to fix a couple of omissions.
Seems obvious, pushed.
Cheers,
Ralf
Another LT_AT_EXEC_CHECK fixup.
* tests/shlibpath.at (shlibpath_overrides_runpath): Use
LT_AT_EXEC_CHECK instead of AT_CHECK.
diff --git a/tests/shlibpath.at
Hello Bruno,
* Bruno Haible wrote on Wed, Jan 14, 2009 at 10:51:46PM CET:
The removal of */.libs/lt- prefixes is done so that make check produces
reliable results, and because the precise location of the executable used
under the hood by libtool is a detail that the user should not know
Hi Charles,
* Charles Wilson wrote on Fri, Jan 16, 2009 at 02:51:21PM CET:
The unexpected failure was
36: execute mode FAILED (execute-mode.at:193)
but it is unrelated; it's a problem in cygwin-1.7's dos-style path
detection...That's not a path!
--- /dev/null 2006-11-30
Hello Charles,
I haven't looked at your patches in detail yet, but a couple of things
caught my eye:
* Charles Wilson wrote on Sat, Jan 03, 2009 at 02:39:15AM CET:
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..c4de91a 100644
---
Den 2009-01-19 21:35 skrev Ralf Wildenhues:
This looks a bit hackish. We already have a handful of places which we
fixed up in order to avoid line ending issues. This one looks hackish
enough to deserve being wrapped in a macro (in testsuite.at, below
LT_AT_HOST_DATA?), so that future
On Mon, 19 Jan 2009, Ralf Wildenhues wrote:
Well,
alias lgdb='libtool --mode=execute gdb'
is still shorter than what you suggest, but for reference, here's a
patch that does what you want.
What do the others think, should libtool be lenient here? I don't have
a strong preference (sure don't
Hi Peter,
* Peter Rosin wrote on Mon, Jan 19, 2009 at 09:52:50PM CET:
Den 2009-01-19 21:35 skrev Ralf Wildenhues:
I think we shouldn't be constantly rebasing pr-msvc-support. I think
instead when we can't decide soonish whether to merge it into master or
to redo it (because it would need
Hello Paul,
let's drop the libtool list.
* Paul Biggar wrote on Tue, Jan 20, 2009 at 03:11:25AM CET:
On Mon, Jan 19, 2009 at 10:15 PM, Ralf Wildenhues wrote:
Please try the patch below.
I had trouble applying this with git apply. Is it against git trunk?
git master, yes. It was updated
Hi Ralf,
Thanks for getting back to me.
On Mon, Jan 19, 2009 at 10:15 PM, Ralf Wildenhues
ralf.wildenh...@gmx.de wrote:
Please try the patch below.
I had trouble applying this with git apply. Is it against git trunk? I
merged it manually however.
$ git apply a
error: patch failed: NEWS:30
18 matches
Mail list logo
