Hi, I haven't built Geany for some time. I remember there was some refactoring of headers, and now build.c errors because win32_expand_environment_variables is not declared. Adding the win32.h include fixes it, but I can't work out how other files like dialogs.c include win32.h, it doesn't seem to be manually included anywhere. What's the correct fix?
Regards, Nick
On 01/08/2014 11:48, Nick Treleaven wrote:
I'll just add the includes manually
Le 01/08/2014 13:03, Nick Treleaven a écrit :
On 01/08/2014 11:48, Nick Treleaven wrote:
I'll just add the includes manually
Looks good to me, I merged it :)
On 01/08/2014 13:38, Colomban Wendling wrote:
Le 01/08/2014 13:03, Nick Treleaven a écrit :
On 01/08/2014 11:48, Nick Treleaven wrote:
I'll just add the includes manually
Looks good to me, I merged it :)
Thanks.
On 1 August 2014 20:48, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 01/08/2014 11:43, Nick Treleaven wrote:
I can't work out how other files like dialogs.c include win32.h
Update: it isn't either ;-) So I suppose I'll just add the includes manually. I thought maybe there was some magic happening somewhere.
Maybe magic somewhere, the windows nightlys are passing :)
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 01/08/2014 12:13, Lex Trotman wrote:
On 1 August 2014 20:48, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 01/08/2014 11:43, Nick Treleaven wrote:
I can't work out how other files like dialogs.c include win32.h
Update: it isn't either ;-) So I suppose I'll just add the includes manually. I thought maybe there was some magic happening somewhere.
Maybe magic somewhere, the windows nightlys are passing :)
Hmm, probably they don't use the makefile.win32 makefiles.
On 1 August 2014 21:18, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 01/08/2014 12:13, Lex Trotman wrote:
On 1 August 2014 20:48, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 01/08/2014 11:43, Nick Treleaven wrote:
I can't work out how other files like dialogs.c include win32.h
Update: it isn't either ;-) So I suppose I'll just add the includes manually. I thought maybe there was some magic happening somewhere.
Maybe magic somewhere, the windows nightlys are passing :)
Hmm, probably they don't use the makefile.win32 makefiles.
Right, Enrico uses waf IIRC
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[...]
Update: it isn't either ;-) So I suppose I'll just add the includes manually. I thought maybe there was some magic happening somewhere.
Maybe magic somewhere, the windows nightlys are passing :)
I appears that the "magic" is that the compile options are not strict enough, there are lots of implicit prototype warnings, but they are not errors.
Cheers Lex
Hmm, probably they don't use the makefile.win32 makefiles.
Right, Enrico uses waf IIRC
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 14-08-01 09:34 AM, Nick Treleaven wrote:
On 01/08/2014 12:23, Lex Trotman wrote:
Maybe magic somewhere, the windows nightlys are passing:)
I appears that the "magic" is that the compile options are not strict enough, there are lots of implicit prototype warnings, but they are not errors.
OK then.
Thanks, you completed two of my TODOs at the end of commit message :)
https://github.com/geany/geany/commit/4efcbab33234d13a7c6d1dea2901535d9317e4...
Cheers, Matthew Brush
On 01/08/14 13:23, Lex Trotman wrote:
[...]
Update: it isn't either ;-) So I suppose I'll just add the includes manually. I thought maybe there was some magic happening somewhere.
Maybe magic somewhere, the windows nightlys are passing :)
I appears that the "magic" is that the compile options are not strict enough, there are lots of implicit prototype warnings, but they are not errors.
As usual, I'm a bit late on the topic but I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
Hmm, probably they don't use the makefile.win32 makefiles.
Right, Enrico uses waf IIRC
Oh yeah, the bad boy still does.
Regards, Enrico
Le 07/08/2014 18:24, Enrico Tröger a écrit :
[...] I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
-Werror-implicit-function-declaration
I use the following when building Geany, and although it shows a few warnings (one in Scintilla that is fixed upstream, a few harmless const promotions, and a few non-literals passed as printf-like formats) it's pretty neat, maybe we'd like to be able to look at these in the logs. Not sure it's so important though.
-Wall -Wextra -g -O2 -Wunused -Wno-unused-parameter -Wunreachable-code -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Werror-implicit-function-declaration -Wno-deprecated-declarations
On 07/08/14 18:41, Colomban Wendling wrote:
Le 07/08/2014 18:24, Enrico Tröger a écrit :
[...] I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
-Werror-implicit-function-declaration
I use the following when building Geany, and although it shows a few warnings (one in Scintilla that is fixed upstream, a few harmless const promotions, and a few non-literals passed as printf-like formats) it's pretty neat, maybe we'd like to be able to look at these in the logs. Not sure it's so important though.
-Wall -Wextra -g -O2 -Wunused -Wno-unused-parameter -Wunreachable-code -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Werror-implicit-function-declaration -Wno-deprecated-declarations
Thanks. I applied these to the Windows nightly builds and also printed the used CFLAGS into the logfile (for reference).
http://nightly.geany.org/win32/build_win32_geany_stderr.log
Regards, Enrico
Le 07/08/2014 23:38, Enrico Tröger a écrit :
On 07/08/14 18:41, Colomban Wendling wrote:
Le 07/08/2014 18:24, Enrico Tröger a écrit :
[...] I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
-Werror-implicit-function-declaration
I use the following when building Geany, and although it shows a few warnings (one in Scintilla that is fixed upstream, a few harmless const promotions, and a few non-literals passed as printf-like formats) it's pretty neat, maybe we'd like to be able to look at these in the logs. Not sure it's so important though.
-Wall -Wextra -g -O2 -Wunused -Wno-unused-parameter -Wunreachable-code -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Werror-implicit-function-declaration -Wno-deprecated-declarations
Thanks. I applied these to the Windows nightly builds and also printed the used CFLAGS into the logfile (for reference).
Hum, this is weird. There are many more warnings that I saw locally, and the compiled code looks outdated -- when I go to e.g. "src/symbols.c:579: warning: will never be executed", I see... an accolade starting the function body.
Also, the headers used seem to generate a lot of shadowing warnings, so maybe we should disable this one. Though, some are really weird, like having a math.h having a global "y0" symbol!?
Anyway, as-is it's not really useful, so maybe we should either fix the warnings or remove the flags triggering them when not important.
Regards, Colomban
On 14-08-07 02:58 PM, Colomban Wendling wrote:
Le 07/08/2014 23:38, Enrico Tröger a écrit :
On 07/08/14 18:41, Colomban Wendling wrote:
Le 07/08/2014 18:24, Enrico Tröger a écrit :
[...] I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
-Werror-implicit-function-declaration
I use the following when building Geany, and although it shows a few warnings (one in Scintilla that is fixed upstream, a few harmless const promotions, and a few non-literals passed as printf-like formats) it's pretty neat, maybe we'd like to be able to look at these in the logs. Not sure it's so important though.
-Wall -Wextra -g -O2 -Wunused -Wno-unused-parameter -Wunreachable-code -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Werror-implicit-function-declaration -Wno-deprecated-declarations
Thanks. I applied these to the Windows nightly builds and also printed the used CFLAGS into the logfile (for reference).
Hum, this is weird. There are many more warnings that I saw locally, and the compiled code looks outdated -- when I go to e.g. "src/symbols.c:579: warning: will never be executed", I see... an accolade starting the function body.
s/accolade/brace/ ... maybe the hook/timer that updates from Git stopped working or something?
Also, the headers used seem to generate a lot of shadowing warnings, so maybe we should disable this one. Though, some are really weird, like having a math.h having a global "y0" symbol!?
Looking in my MinGW math.h, it seems you need to define _NO_OLDNAMES to get rid of those non-ANSII names. It might also be useful to define __STRICT_ANSI__ to get rid of more non-std/non-prefixed names.
Anyway, as-is it's not really useful, so maybe we should either fix the warnings or remove the flags triggering them when not important.
It would be a lot more useful if there's a way to hide errors that originate in "system headers" (ie. not any of ours).
@Enrico, is there anyway to make the "nightlies" rebuild on a Git hook instead of only once per day? Like maybe giving 10 minutes buffer time to allow merging massive branches without re-compiling a bunch of times. It would be more immediate feedback on how badly one has broken Windows build :)
Cheers, Matthew Brush
Heyho,
On 08/08/14 01:19, Matthew Brush wrote:
On 14-08-07 02:58 PM, Colomban Wendling wrote:
Le 07/08/2014 23:38, Enrico Tröger a écrit :
On 07/08/14 18:41, Colomban Wendling wrote:
Le 07/08/2014 18:24, Enrico Tröger a écrit :
[...] I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
-Werror-implicit-function-declaration
I use the following when building Geany, and although it shows a few warnings (one in Scintilla that is fixed upstream, a few harmless const promotions, and a few non-literals passed as printf-like formats) it's pretty neat, maybe we'd like to be able to look at these in the logs. Not sure it's so important though.
-Wall -Wextra -g -O2 -Wunused -Wno-unused-parameter -Wunreachable-code -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Werror-implicit-function-declaration -Wno-deprecated-declarations
Thanks. I applied these to the Windows nightly builds and also printed the used CFLAGS into the logfile (for reference).
Hum, this is weird. There are many more warnings that I saw locally, and the compiled code looks outdated -- when I go to e.g. "src/symbols.c:579: warning: will never be executed", I see... an accolade starting the function body.
s/accolade/brace/ ... maybe the hook/timer that updates from Git stopped working or something?
Nope: rm -rf /home/geany/build/geany_git
git clone --depth=1 git://github.com/geany/geany.git /home/geany/build/geany_git
this happens very early in the build process, i.e. getting a fresh clone frm Github.
Additionally, I checked src/symbols.c:579 on the build host against my local version and this line is the same containing a '{'. So, I guess it's just gcc which issues this warning on that exact line though I have no idea *why* it thinks that find_toplevel_iter() will never be executed. But given that this is a very old gcc 3.4.5, it might be just gcc's secret.
Maybe we could update the toolchain used there if anyone knows a working toolchain and has enough will to do it. I personally don't want to do this as long as the code compiles against gcc 3.4 because it is always a pain (for me).
Also, the headers used seem to generate a lot of shadowing warnings, so
-Wshadow is removed.
I'd also remove the warning which causes 'warning: function declaration isn't a prototype' if there are no objections.
maybe we should disable this one. Though, some are really weird, like having a math.h having a global "y0" symbol!?
Looking in my MinGW math.h, it seems you need to define _NO_OLDNAMES to get rid of those non-ANSII names. It might also be useful to define __STRICT_ANSI__ to get rid of more non-std/non-prefixed names.
Should I define those for the Windows builds?
Anyway, as-is it's not really useful, so maybe we should either fix the warnings or remove the flags triggering them when not important.
It would be a lot more useful if there's a way to hide errors that originate in "system headers" (ie. not any of ours).
@Enrico, is there anyway to make the "nightlies" rebuild on a Git hook instead of only once per day? Like maybe giving 10 minutes buffer time to allow merging massive branches without re-compiling a bunch of times. It would be more immediate feedback on how badly one has broken Windows build :)
Yeah, this is on my TODO list though I cannot say when this will happen but yeah, it would be very cool. Even though we need a bigger buffer than 10 minutes, the last whole build tonight (Windows, ArchLinux & Debian) took about 40 minutes so I'd rather use a buffer of 60 minutes..
But one hours is still better than 24 hours, I guess :).
I will do, at some point.
Regards, Enrico
Le 08/08/2014 17:55, Enrico Tröger a écrit :
[...]
Maybe we could update the toolchain used there if anyone knows a working toolchain and has enough will to do it. I personally don't want to do this as long as the code compiles against gcc 3.4 because it is always a pain (for me).
OK, no problem for me, we just need to tailor the warnings for GCC 3.4 then.
Also, the headers used seem to generate a lot of shadowing warnings, so
-Wshadow is removed.
OK
I'd also remove the warning which causes 'warning: function declaration isn't a prototype' if there are no objections.
I have no objection as it won't likely show a windows-specific important issue, but FWIW the Scintilla ones should be fixed with our next Scintilla update. But the GTK2 one won't.
Cheers, Colomban
On 8 August 2014 02:24, Enrico Tröger enrico.troeger@uvena.de wrote:
On 01/08/14 13:23, Lex Trotman wrote:
[...]
Update: it isn't either ;-) So I suppose I'll just add the includes manually. I thought maybe there was some magic happening somewhere.
Maybe magic somewhere, the windows nightlys are passing :)
I appears that the "magic" is that the compile options are not strict enough, there are lots of implicit prototype warnings, but they are not errors.
As usual, I'm a bit late on the topic but I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
This is gcc right? So you should be able to -Werror=implicit to turn just that warning into an error. You can add more that way -Werror=.....
Cheers Lex
Hmm, probably they don't use the makefile.win32 makefiles.
Right, Enrico uses waf IIRC
Oh yeah, the bad boy still does.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 08/08/14 01:23, Lex Trotman wrote:
On 8 August 2014 02:24, Enrico Tröger enrico.troeger@uvena.de wrote:
On 01/08/14 13:23, Lex Trotman wrote:
[...]
> Update: it isn't either ;-) So I suppose I'll just add the includes > manually. I thought maybe there was some magic happening somewhere.
Maybe magic somewhere, the windows nightlys are passing :)
I appears that the "magic" is that the compile options are not strict enough, there are lots of implicit prototype warnings, but they are not errors.
As usual, I'm a bit late on the topic but I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems.
Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling.
This is gcc right? So you should be able to -Werror=implicit to turn just that warning into an error. You can add more that way -Werror=.....
Ah cool, thanks. b4n posted a similar approach, as you have probably seen.
Regards, Enrico