On Jun 17, 2020, at 17:18, Han-Wen Nienhuys wrote:
>
> My proposal is to use -Werror only in CI, so we can keep code free of
> warnings.
>
I'd go along with that if I could have a single switch or environment variable
to configure my local build with all the options that w
On Mon, Jun 15, 2020 at 2:43 PM Jonas Hahnfeld wrote:
>
> Am Montag, den 15.06.2020, 07:50 -0400 schrieb Dan Eble:
> > Han-Wen proposed building with -Werror in a merge request. What do you
> > think?
> >
> > I like -Werror, but I've only ever used it whe
Am Montag, den 15.06.2020, 07:50 -0400 schrieb Dan Eble:
> Han-Wen proposed building with -Werror in a merge request. What do you think?
>
> I like -Werror, but I've only ever used it where there were very few (or one)
> supported build environments, all of which were
Dan Eble writes:
> Han-Wen proposed building with -Werror in a merge request. What do you think?
>
> I like -Werror, but I've only ever used it where there were very few
> (or one) supported build environments, all of which were covered in
> CI. A dimension of the CI cover
Han-Wen proposed building with -Werror in a merge request. What do you think?
I like -Werror, but I've only ever used it where there were very few (or one)
supported build environments, all of which were covered in CI. A dimension of
the CI coverage was optimization level, which can c
, I could not figure out to make this happen, short of
postprocessing the resulting parser.cc file.
That would be one option.
Otherwise, the only solution I can think of for this is to exempt
parser.cc from
-Werror.
Perhaps turn off this particular warning in the source via some #pragma
or wh
http://codereview.appspot.com/5489092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
; may pup up with a 64-bit compile.
hmm, was this with
-Wextra -Wconversion -Werror
?
Nope. Just with -Wconversion -Werror -Wall -W -Wno-pmf-conversions
-Woverloaded-virtual
If I get time, I'll try with -Wextra and see what I get
http://codereview.ap
On 2011/12/20 14:02:50, Reinhold wrote:
Is anyone here using a 64-bit OS? There are ~150 compiler warnings
when
compiling lilypond currently (see bug 1890), so -Werror can't be
enabled on
64-bit systems.
Yes, this does not surprise me. I wish I had a 64-bit system, but I'm
not
, I could not figure
out to make this happen, short of postprocessing the resulting parser.cc
file.
Otherwise, the only solution I can think of for this is to exempt
parser.cc from -Werror.
http://codereview.appspot.com/5489092/
___
lilypond-devel mailing
th
-Wextra -Wconversion -Werror
?
clang definitely finds more warnings, but I recall that gcc has a
bunch of additional warnings that aren't enable with -Wextra. :(
Anyway, that's no reason to hold off on this patch (if David's
concerns about the parser can be resolved). Simply being abl
Reviewers: ,
Message:
A set of changes to allow lilypond to be built with -Werror using gcc
4.6.2 on i386. I don't know if these changes are desirable, but I am
submitting them in the hopes that they may be useful.
Description:
Changes to allow compiling with -Werror using gcc 4.6.2 on
- Original Message -
From:
To: ; ;
; ;
Cc: ;
Sent: Tuesday, December 20, 2011 2:02 PM
Subject: Re: Changes to allow compiling with -Werror using gcc 4.6.2 on
i386.(issue 5489092)
Is anyone here using a 64-bit OS? There are ~150 compiler warnings when
compiling lilypond currently
On 11-12-20 07:02 AM, reinhold.kainho...@gmail.com wrote:
Is anyone here using a 64-bit OS? There are ~150 compiler warnings when
compiling lilypond currently (see bug 1890), so -Werror can't be enabled
on 64-bit systems.
http://codereview.appspot.com/54
Is anyone here using a 64-bit OS? There are ~150 compiler warnings when
compiling lilypond currently (see bug 1890), so -Werror can't be enabled
on 64-bit systems.
http://codereview.appspot.com/5489092/
___
lilypond-devel mailing list
lilypond-
http://codereview.appspot.com/5489092/diff/1/lily/parser.yy
File lily/parser.yy (right):
http://codereview.appspot.com/5489092/diff/1/lily/parser.yy#newcode36
lily/parser.yy:36: /* Define to get rid of conversion warning, int ->
int16_t. This has
I think the side effect of significantly increas
On 2011/12/20 03:55:59, Carl wrote:
Personally, I see no reason to use I64 instead of int. Neil Puttock
changed the
numerator and denominators to be I64 in 2008, with commit
be65b81068e99ed855334f332c3176d8b4942a11
I don't think that research on the history of such changes should be
holding
This patch will collide with the outstanding patch fixing beaming, as
the variables have changed and are treated as int.
Personally, I see no reason to use I64 instead of int. Neil Puttock
changed the numerator and denominators to be I64 in 2008, with commit
be65b81068e99ed855334f332c3176d8b4942
http://codereview.appspot.com/5489092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/12/20 01:54:29, Graham Percival wrote:
You'll probably find a ton of more errors when running 'make check' --
apparently that compiles some stuff in flower/ that isn't compiled
during a
normal make.
In point of fact, I found no additional errors when running make check.
Please unders
http://codereview.appspot.com/5489092/diff/1/lily/beaming-pattern.cc
File lily/beaming-pattern.cc (right):
http://codereview.appspot.com/5489092/diff/1/lily/beaming-pattern.cc#newcode187
lily/beaming-pattern.cc:187: I64 count = 1; //default -- 1 base moments
in a beam
On 2011/12/20 01:54:29, Gr
wow, I'd love to enable -Werror!
You'll probably find a ton of more errors when running 'make check' --
apparently that compiles some stuff in flower/ that isn't compiled
during a normal make.
http://codereview.appspot.com/5489092/diff/1/lily/beaming-pattern.cc
Fil
22 matches
Mail list logo
