On Fri, Dec 2, 2016 at 9:53 PM, Bob Uhl wrote:
> Anyway, consider the patch withdrawn. If folks are maintaining their
> changes in config.h then it's obviously a terrible idea to obliterate
> it. I wouldn't submit a patch that I think makes things worse for
> folks.
Because you
Laslo Hunhold writes:
>
>> How come? At least in my own workflow, I've been surprised by an
>> uncopied config.h repeatedly. My expectation is that if I change a
>> source file (e.g. config.def.h) that config.h will be updated.
>
> config.def.h contains the default settings. Of
On Fri, 2 Dec 2016 20:41:51 +0100
Martin Kühne wrote:
Hey Martin,
> Just keep your config.h and merge changes from config.def.h.
> Why are you destroying a perfect system?
just calm down. I think it was positive we discussed this here. This
way, Bob saw the reasoning behind
Just keep your config.h and merge changes from config.def.h.
Why are you destroying a perfect system?
cheers!
mar77i
On Fri, 02 Dec 2016 11:58:07 -0700
Bob Uhl wrote:
Hey Bob,
> How come? At least in my own workflow, I've been surprised by an
> uncopied config.h repeatedly. My expectation is that if I change a
> source file (e.g. config.def.h) that config.h will be updated.
config.def.h
ACE writes:
>
> I would say this patch causes more problems than it solves.
How come? At least in my own workflow, I've been surprised by an
uncopied config.h repeatedly. My expectation is that if I change a
source file (e.g. config.def.h) that config.h will be updated.
Hi Bob.
I would say this patch causes more problems than it solves.
Currently, if one edits config.def.h one must manually delete
config.h (or manually copy the former over the latter); this ensures
that changes force a 'regeneration' (really, a copy).
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index
commit 93d75a07943f4352dfe617954341c0c7a0ffe532
Author: Roberto E. Vargas Caballero
AuthorDate: Fri Dec 2 14:31:19 2016 +0100
Commit: Roberto E. Vargas Caballero
CommitDate: Fri Dec 2 14:31:19 2016 +0100
Revert "[cc2] Fix the order of elements of
On Fri, 2 Dec 2016 13:54:22 +0100
Anselm R Garbe wrote:
> Hi there,
>
> On 2 December 2016 at 13:34, Mattias Andrée
> wrote:
> > If it's actually need, the package could call strip on
> > the binaries that fail, or the developer can call strip
> >
Hi there,
On 2 December 2016 at 13:34, Mattias Andrée wrote:
> If it's actually need, the package could call strip on
> the binaries that fail, or the developer can call strip
> explicitly. If it's even possible symbols could be problem,
> it's so rare that it wouldn't be much
On Fri, 2 Dec 2016 13:22:16 +0100
Laslo Hunhold wrote:
> On Thu, 1 Dec 2016 22:50:20 -0800
> Michael Forney wrote:
>
> Hey Michael,
>
> > memmove moves a number of bytes, not pointers, so if
> > you passed a number of arguments that is larger than
> > the
On Fri, 2 Dec 2016 13:22:16 +0100
Laslo Hunhold wrote:
> We _must not_ use memmove here as we invoke undefined behaviour,
> given the two memory regions overlap.
Nevermind this part, sorry. I mixed it up with memcpy. Still, do we
need this here?
--
Laslo Hunhold
On Thu, 1 Dec 2016 22:50:20 -0800
Michael Forney wrote:
Hey Michael,
> memmove moves a number of bytes, not pointers, so if you passed a
> number of arguments that is larger than the pointer byte size, you
> could end up crashing or skipping the install of a file and
>
14 matches
Mail list logo