[Geany-devel] ANN: Configurable Build Menu Alpha in SVN
enrico.troeger at xxxxx
Sat Jul 18 12:32:11 UTC 2009
On Sat, 18 Jul 2009 22:17:06 +1000, Lex wrote:
>2009/7/18 Enrico Tröger <enrico.troeger at uvena.de>:
>> On Fri, 17 Jul 2009 10:03:15 +1000, Lex wrote:
>>>> - you really should fix the compiler warnings, I get a whole bunch
>>>> when compiling the code (see attachment). Most of them are harmless
>>>> like unused variables but the more warnings you usually have, the
>>>> bigger the danger is to overlook a real warning which you want to
>>>I don't get any of these, is there an option I need to give make or
>>>configure to make it picky???
>>>Should be all fixed, but I can't actually check since I don't get
>>>them. BTW the filetypes one was useful, but most build ones were just
>> The most important flag is -Wall, this should be used generally I
>> think. I personally use some more flags like (set before
>> running ./configure resp. ./waf configure):
>> export CFLAGS="-Wall -O0 -g -pipe -march=athlon64 \
>> -DGEANY_DEBUG \
>> -D_FORTIFY_SOURCE=2 \
>> -Waggregate-return \
>> -Wdeclaration-after-statement \
>> -Wdisabled-optimization \
>> -Wfloat-equal \
>> -Wformat-nonliteral \
>> -Wformat-security \
>> -Wformat=2 \
>> -Winit-self \
>> -Winline \
>> -Wmissing-field-initializers \
>> -Wmissing-include-dirs \
>> -Wmissing-noreturn \
>> -Wpointer-arith \
>> -Wshadow \
>> -Wsign-compare \
>> -fno-common \
>> -funit-at-a-time \
>> But this is enables rather much stuff. Anyway, the latest SVN builds
>> pretty fine with these fine, good job.
>Oh, OK environment variable!!
>couple of (maybe helpful, maybe not) comments
>I think Wformat=2 includes Wformat-security and Wformat-nonliteral
>I don't think Winit-self will work without -Wuninitialized and -O1
>Winline seems wasted since no Geany currently inlines and anyway its
>not really useful even if you use inlines, if the compiler won't
>inline something, it won't, so whats the point of a warning? (C++ user
>funit-at-a-time isn't much use at low optimisation levels & is
>automatically on at high levels anyway.
Probably all true but on the other hand, it just don't hurt :). I
didn't say you should use them, just that I use them.
>probably worth Wstrict-prototypes
This causes lots of warnings in the GTK headers, kinda unfortunate.
>> Yes, as I said I don't have a better idea so far and so I'm not in
>> the position to criticise the dialog too much :).
>> Maybe we find a solution, if needed at all, later. And since the
>> dialog UI exists for now, it's more important to get everything
>> behind working. Changing the GUI can be done easily afterwards.
>Yes, I am about to say that this branch is feature complete and any
>problems that come up now are bugs or put in the TODO list
Cool, so we can slowly start talking about merging the branch back to
I think it's best to test this code and to find and fix obvious bugs
and problems. And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the
branch or to do it before.
Doing a releasing before merging would make the release more stable
probably and gives us more time to test the new code.
OTOH merging the branch soon and delaying a possible new release a bit
is maybe better for the users because they don't need to wait for
another release cycle to see the new and fancy build system code :).
I tend to merge it and then make a release.
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the Devel