On Sat, 18 Jul 2009 22:17:06 +1000, Lex wrote: >2009/7/18 Enrico Tröger <[email protected]>: >> 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 -- Get my GPG key from http://www.uvena.de/pub.asc
pgpac9Yo0He40.pgp
Description: PGP signature
_______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
