On Sat, 18 Jul 2009 22:17:06 +1000, Lex wrote:
2009/7/18 Enrico Tröger enrico.troeger@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 see
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 annoying thankfully.
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 speaking) 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 trunk (slowly). 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 :).
Any opinions? I tend to merge it and then make a release.
Regards, Enrico