Hi,
Jan Engelhardt writes:
> On Monday 2009-03-09 15:57, Ralf Corsepius wrote:
> For this patch, I'm unsure if we should even add it at all.
>
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of
errors.
>>>
>>
Den 2009-03-09 22:09 skrev Ralf Wildenhues:
* Peter Rosin wrote on Mon, Mar 09, 2009 at 09:51:14PM CET:
Den 2009-03-04 00:07 skrev Ralf Wildenhues:
Not a really nice fix, but I've come up with this below. Can you try
it (at least the tests/dep* tests from automake, please)?
depcomp.test is ok
* Peter Rosin wrote on Mon, Mar 09, 2009 at 09:51:14PM CET:
> Den 2009-03-04 00:07 skrev Ralf Wildenhues:
>> Not a really nice fix, but I've come up with this below. Can you try
>> it (at least the tests/dep* tests from automake, please)?
>
> depcomp.test is ok,
> depcomp2.test and depcomp3.test a
* Ralf Wildenhues wrote on Sun, Mar 08, 2009 at 10:07:06AM CET:
> * Jan Engelhardt wrote on Sat, Mar 07, 2009 at 07:17:03PM CET:
> >
> > I am missing the definition of am__v_GEN in the generated Makefile
> > that is designed for use with manual rules. Like,
> >
> > # -*- Makefile -*-
> >
Den 2009-03-04 00:07 skrev Ralf Wildenhues:
* Peter Rosin wrote on Wed, Jan 28, 2009 at 12:57:43PM CET:
But if you are looking for bugs to squash, one obvious problem is
that the standard
AC_PROG_CC
AM_PROG_CC_C_O
puts the dependency check before the -c -o check, which forces losers
like me to c
* Jan Engelhardt wrote on Sun, Mar 08, 2009 at 04:02:06PM CET:
> On Sunday 2009-03-08 10:01, Ralf Wildenhues wrote:
> >>
> >> Well newlines can easily be avoided by getting rid of all the
> >> continuation lines within an if block and writing the full command
> >> lines out on every line. Yes, red
Hi Ralf!
Den 2009-03-03 22:35 skrev Ralf Wildenhues:
Hi Peter,
* Peter Rosin wrote on Fri, Jan 30, 2009 at 11:20:13AM CET:
+2009-01-30 Peter Rosin
+
+ Add depmode=msvcmsys for Microsoft Visual C++ on MSYS.
+ * lib/depcomp [msvisualcpp]: Fork fewer processes. Filter out
+ l
* Ralf Wildenhues wrote on Sun, Mar 08, 2009 at 10:18:51AM CET:
> This warning channel is currently turned on by -Wall, but it should also
> be turned on by -Wportability, I guess; or get its own switch. As noted
> in some of the earlier discussions, recursive $(var1$(var2)) variable
> expansions
* Ralf Corsepius wrote on Mon, Mar 09, 2009 at 03:57:58PM CET:
> Jan Engelhardt wrote:
>> On Monday 2009-03-09 15:44, Ralf Corsepius wrote:
>>> Ralf Wildenhues wrote:
For this patch, I'm unsure if we should even add it at all.
>>> FWIW: I am opposed to it.
I suppose you are opposed to th
* Peter Rosin wrote on Mon, Mar 09, 2009 at 04:53:11PM CET:
>
> Here's a tiny fix for a typo in the new compile2.test. With this fix I get
> exitcode 77 between the two subtests.
Thanks, applied.
Cheers,
Ralf
> commit 3f63a77c0647199d4121c54ea29d28d509539369
> Author: Peter Rosin
> Date: Mon
On Monday 2009-03-09 16:54, Ralf Corsepius wrote:
>
>> which has some similar silent mode too (by default even!)...
>>
> Correct. that's one of cmake's sillynesses. It hides away the silent bugs a
> package suffers from.
Potential bugs in the command line invoking $CC that automake generates
ju
Jan Engelhardt wrote:
On Monday 2009-03-09 16:10, Ralf Corsepius wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of
errors.
Which ones, please?
Den 2009-03-03 22:07 skrev Ralf Wildenhues:
Hi Peter,
* Peter Rosin wrote on Mon, Mar 02, 2009 at 02:16:51PM CET:
Den 2009-03-01 19:10 skrev Ralf Wildenhues:
* Peter Rosin wrote on Sun, Feb 01, 2009 at 08:30:20PM CET:
Constant name 'HASH(0xa2a1ea8)' has invalid characters at ./automake.tmp li
On Monday 2009-03-09 16:10, Ralf Corsepius wrote:
>> For this patch, I'm unsure if we should even add it at all.
> FWIW: I am opposed to it.
> All this silencing stuff does is to add further potential sources of
> errors.
>
Which ones, please?
>>> Those
Jan Engelhardt wrote:
On Monday 2009-03-09 15:57, Ralf Corsepius wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of errors.
Which ones, plea
On Monday 2009-03-09 15:57, Ralf Corsepius wrote:
>>>
For this patch, I'm unsure if we should even add it at all.
>>> FWIW: I am opposed to it.
>>>
>>> All this silencing stuff does is to add further potential sources of errors.
>>
>> Which ones, please?
>>
> Those yet to be
Jan Engelhardt wrote:
On Monday 2009-03-09 15:44, Ralf Corsepius wrote:
Ralf Wildenhues wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of errors.
Which ones, p
On Monday 2009-03-09 15:44, Ralf Corsepius wrote:
> Ralf Wildenhues wrote:
>> For this patch, I'm unsure if we should even add it at all.
>
> FWIW: I am opposed to it.
>
> All this silencing stuff does is to add further potential sources of errors.
Which ones, please?
Ralf Wildenhues wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of errors.
Ralf
19 matches
Mail list logo