"Registers Python type/class to property mapping.\n\nfactory: Property builder function/class."
"""\
Registers Python type/class to property mapping.
factory: Property builder function/class.
"""
For the wxWidgets headers, you'll have to add -Wno-attributes to the compile-time options until it's fixed upstream.
warnings about deprecated string-conversionI think we should solve those correctly and not suppress, assuming this would become errors in GCC4.3.
I think we should solve those correctly and not suppress, assuming this would become errors in GCC4.3.I can come up with a patch for this if you like, but if you ever want to update the sources from upstream then all my work would magically disappear...
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)The patch fixes the multiline problems, and "progrid.h" and "manager.h" compile without a warning.
... (at least under linux there is no "-Wno-write"-strings documented).
Each of these specific warning options also has a negative form beginning `-Wno-' to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.
...
-Wwrite-strings
When compiling C, give string constants the type const char[length] so that copying the address of one into a non-const char * pointer will get a warning; when compiling C++, warn about the deprecated conversion from string literals to char *. This warning, by default, is enabled for C++ programs. These warnings will help you find at compile time code that can try to write into a string constant, but only if you have been very careful about using const in declarations and prototypes. Otherwise, it will just be a nuisance; this is why we did not make -Wall request these warnings.
jens:... (at least under linux there is no "-Wno-write"-strings documented).Quote from: GCC 4.2.1 ManualEach of these specific warning options also has a negative form beginning `-Wno-' to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.
...
-Wwrite-strings
When compiling C, give string constants the type const char[length] so that copying the address of one into a non-const char * pointer will get a warning; when compiling C++, warn about the deprecated conversion from string literals to char *. This warning, by default, is enabled for C++ programs. These warnings will help you find at compile time code that can try to write into a string constant, but only if you have been very careful about using const in declarations and prototypes. Otherwise, it will just be a nuisance; this is why we did not make -Wall request these warnings.
-Wwrite-strings doesn't turn off the warnings, it enables them (i.e., has no effect when compiling C++). Try it yourself.
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
It could be useful to submit your patch to the propgrid tracker:
http://sourceforge.net/tracker/?group_id=133406
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
It could be useful to submit your patch to the propgrid tracker:
http://sourceforge.net/tracker/?group_id=133406
Why, since it has already been applied to SVN?
Tim S
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
It could be useful to submit your patch to the propgrid tracker:
http://sourceforge.net/tracker/?group_id=133406
Why, since it has already been applied to SVN?
Tim S
@Tim:
He means the tracking system of wxPropertyGrid.
@lazalong:
It's fixed in newer revision(s) that the one used by codeblocks.
/usr/src/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `signpost_alpha'
Index: src/sdk/wxFlatNotebook/src/wxFlatNotebook/fnb_resources.cpp
===================================================================
--- src/sdk/wxFlatNotebook/src/wxFlatNotebook/fnb_resources.cpp (revision 4572)
+++ src/sdk/wxFlatNotebook/src/wxFlatNotebook/fnb_resources.cpp (working copy)
@@ -136,7 +136,7 @@
" ",
" "
};
-const unsigned char signpost_alpha[]={
+unsigned char signpost_alpha[]={
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 7, 174, 240, 238, 148, 0, 0, 0, 0, 0, 0, 0,
I added the const, but on linux everything builded fine for me, just tried on windows same issue, but why should it not be const ??
[now the warning will be back :-( ] It is used once at a place where I cast away the const, but as fas as I can't tell from the wx doc, it seems the argument will not be changed by the wxImage method [not even delete since 2e arg is true]
[I wonder why make or gcc apparently is not working correctly, since for some it breaks compilation, for others it don't]
This had already been done, every windows cbp of CB includes a project build script.The script is OK (and cool ;-)) but I'd like to veto the path where it had been put into. Remember that usually you can checkout the C::B C++ sources only using svn.berlios.de/svnroot/repos/codeblocks/src? This won't work now anymore. Why didn't you put this script under src/build_tools ? That would have been the place to do IMHO...?!
This had already been done, every windows cbp of CB includes a project build script.The script is OK (and cool ;-)) but I'd like to veto the path where it had been put into. Remember that usually you can checkout the C::B C++ sources only using svn.berlios.de/svnroot/repos/codeblocks/src? This won't work now anymore. Why didn't you put this script under src/build_tools ? That would have been the place to do IMHO...?!
With regards, Morten.
for no reason, you could put it in src (next to the main cbp), it is not actually a build tool. It is there temporarily untill the wx guys clean up their ...
[[if (PLATFORM == PLATFORM_MSW && (GetCompilerFactory().GetCompilerVersionString(_T("gcc")) >= _T("4.2.0"))) print(_T("-Wno-attributes"));]]
It is there temporarily untill the wx guys clean up their ...
Then wxPropertyGrid will be gone from the Code::Blocks SDK anyway, and possibly the warnings are magically gone too.
for no reason, you could put it in src (next to the main cbp), it is not actually a build tool. It is there temporarily untill the wx guys clean up their ...
Just remove the script file. Following attached script would do the job for us.Code[[if (PLATFORM == PLATFORM_MSW && (GetCompilerFactory().GetCompilerVersionString(_T("gcc")) >= _T("4.2.0"))) print(_T("-Wno-attributes"));]]
Add the above line to Project > Build options > Compiler settings > Other options section as a compiler option. It would get expanded during building and will remain attached to the Project file.
Please Note: Don't break the line into two or more. It simply won't work. :)
hey you cracked it to put it into the cbp ;-) , I have tried but failed ;-)
However, looking back on this, I think it is better to have it in a script, otherwise you have to make sure every plug-in also has the correct pseudo script in place ...
Why is this so inconsistent, have done a rebuild all. Or are those pch's biting me again ??Nope - there were simply some missing includes in the project files. I'll update the project files for Windows accordingly (had the same issue).
for some reason, CBgames don't compile on my machine with MINGW.3.4.5BTW: I can also do the update with the script path. I have done it on my machine anyways... shall I???
Why is this so inconsistent, have done a rebuild all. Or are those pch's biting me again ??Nope - there were simply some missing includes in the project files. I'll update the project files for Windows accordingly (had the same issue).
for some reason, CBgames don't compile on my machine with MINGW.3.4.5BTW: I can also do the update with the script path. I have done it on my machine anyways... shall I???
That would be very nice, don'tforget the contrib plugins ;-)Massive CBP update and script moving done. I hope it'll work again now. Could any MinGW 3.4.5 user please give it a try? I (hopefully) didn't forget anything...
That would be very nice, don'tforget the contrib plugins ;-)Massive CBP update and script moving done. I hope it'll work again now. Could any MinGW 3.4.5 user please give it a try? I (hopefully) didn't forget anything...
/* wx-2.9 introduces new macros for forward declarations, include them
* here for forward compatibility:
GCC warns about using __attribute__ (and also __declspec in mingw32 case) on
forward declarations while MSVC complains about forward declarations without
__declspec for the classes later declared with it, so we need a separate set
of macros for forward declarations to hide this difference:
*/
#if (defined(__WINDOWS__) && defined(__GNUC__))
#define WXDLLIMPEXP_FWD_BASE
#define WXDLLIMPEXP_FWD_NET
#define WXDLLIMPEXP_FWD_CORE
#define WXDLLIMPEXP_FWD_ADV
#define WXDLLIMPEXP_FWD_QA
#define WXDLLIMPEXP_FWD_HTML
#define WXDLLIMPEXP_FWD_GL
#define WXDLLIMPEXP_FWD_XML
#define WXDLLIMPEXP_FWD_XRC
#define WXDLLIMPEXP_FWD_AUI
#define WXDLLIMPEXP_FWD_RICHTEXT
#define WXDLLIMPEXP_FWD_MEDIA
#define WXDLLIMPEXP_FWD_STC
#else
#define WXDLLIMPEXP_FWD_BASE WXDLLIMPEXP_BASE
#define WXDLLIMPEXP_FWD_NET WXDLLIMPEXP_NET
#define WXDLLIMPEXP_FWD_CORE WXDLLIMPEXP_CORE
#define WXDLLIMPEXP_FWD_ADV WXDLLIMPEXP_ADV
#define WXDLLIMPEXP_FWD_QA WXDLLIMPEXP_QA
#define WXDLLIMPEXP_FWD_HTML WXDLLIMPEXP_HTML
#define WXDLLIMPEXP_FWD_GL WXDLLIMPEXP_GL
#define WXDLLIMPEXP_FWD_XML WXDLLIMPEXP_XML
#define WXDLLIMPEXP_FWD_XRC WXDLLIMPEXP_XRC
#define WXDLLIMPEXP_FWD_AUI WXDLLIMPEXP_AUI
#define WXDLLIMPEXP_FWD_RICHTEXT WXDLLIMPEXP_RICHTEXT
#define WXDLLIMPEXP_FWD_MEDIA WXDLLIMPEXP_MEDIA
#define WXDLLIMPEXP_FWD_STC WXDLLIMPEXP_STC
#endif
Index: include/wx/dlimpexp.h
===================================================================
--- include/wx/dlimpexp.h (revision 49512)
+++ include/wx/dlimpexp.h (working copy)
@@ -234,22 +234,42 @@
#define WXDLLEXPORT_DATA WXDLLIMPEXP_DATA_CORE
/* wx-2.9 introduces new macros for forward declarations, include them
- * here for forward compatibility: */
-#define WXDLLIMPEXP_FWD_BASE WXDLLIMPEXP_BASE
-#define WXDLLIMPEXP_FWD_NET WXDLLIMPEXP_NET
-#define WXDLLIMPEXP_FWD_CORE WXDLLIMPEXP_CORE
-#define WXDLLIMPEXP_FWD_ADV WXDLLIMPEXP_ADV
-#define WXDLLIMPEXP_FWD_QA WXDLLIMPEXP_QA
-#define WXDLLIMPEXP_FWD_ODBC WXDLLIMPEXP_ODBC
-#define WXDLLIMPEXP_FWD_DBGRID WXDLLIMPEXP_DBGRID
-#define WXDLLIMPEXP_FWD_HTML WXDLLIMPEXP_HTML
-#define WXDLLIMPEXP_FWD_GL WXDLLIMPEXP_GL
-#define WXDLLIMPEXP_FWD_XML WXDLLIMPEXP_XML
-#define WXDLLIMPEXP_FWD_XRC WXDLLIMPEXP_XRC
-#define WXDLLIMPEXP_FWD_AUI WXDLLIMPEXP_AUI
-#define WXDLLIMPEXP_FWD_RICHTEXT WXDLLIMPEXP_RICHTEXT
-#define WXDLLIMPEXP_FWD_MEDIA WXDLLIMPEXP_MEDIA
-#define WXDLLIMPEXP_FWD_STC WXDLLIMPEXP_STC
+ * here for forward compatibility:
+
+ GCC warns about using __attribute__ (and also __declspec in mingw32 case) on
+ forward declarations while MSVC complains about forward declarations without
+ __declspec for the classes later declared with it, so we need a separate set
+ of macros for forward declarations to hide this difference:
+ */
+#if (defined(__WINDOWS__) && defined(__GNUC__))
+ #define WXDLLIMPEXP_FWD_BASE
+ #define WXDLLIMPEXP_FWD_NET
+ #define WXDLLIMPEXP_FWD_CORE
+ #define WXDLLIMPEXP_FWD_ADV
+ #define WXDLLIMPEXP_FWD_QA
+ #define WXDLLIMPEXP_FWD_HTML
+ #define WXDLLIMPEXP_FWD_GL
+ #define WXDLLIMPEXP_FWD_XML
+ #define WXDLLIMPEXP_FWD_XRC
+ #define WXDLLIMPEXP_FWD_AUI
+ #define WXDLLIMPEXP_FWD_RICHTEXT
+ #define WXDLLIMPEXP_FWD_MEDIA
+ #define WXDLLIMPEXP_FWD_STC
+#else
+ #define WXDLLIMPEXP_FWD_BASE WXDLLIMPEXP_BASE
+ #define WXDLLIMPEXP_FWD_NET WXDLLIMPEXP_NET
+ #define WXDLLIMPEXP_FWD_CORE WXDLLIMPEXP_CORE
+ #define WXDLLIMPEXP_FWD_ADV WXDLLIMPEXP_ADV
+ #define WXDLLIMPEXP_FWD_QA WXDLLIMPEXP_QA
+ #define WXDLLIMPEXP_FWD_HTML WXDLLIMPEXP_HTML
+ #define WXDLLIMPEXP_FWD_GL WXDLLIMPEXP_GL
+ #define WXDLLIMPEXP_FWD_XML WXDLLIMPEXP_XML
+ #define WXDLLIMPEXP_FWD_XRC WXDLLIMPEXP_XRC
+ #define WXDLLIMPEXP_FWD_AUI WXDLLIMPEXP_AUI
+ #define WXDLLIMPEXP_FWD_RICHTEXT WXDLLIMPEXP_RICHTEXT
+ #define WXDLLIMPEXP_FWD_MEDIA WXDLLIMPEXP_MEDIA
+ #define WXDLLIMPEXP_FWD_STC WXDLLIMPEXP_STC
+#endif
#endif /* _WX_DLIMPEXP_H_ */
Byo is the only one using wxPropertyGrid. I think you should just wait for him to finish his update to the most recent version (which has been talked of a few weeks ago). Then wxPropertyGrid will be gone from the Code::Blocks SDK anyway, and possibly the warnings are magically gone too.
Index: src/include/propgrid/include/wx/propgrid/odcombo.h
===================================================================
--- src/include/propgrid/include/wx/propgrid/odcombo.h (revision 4580)
+++ src/include/propgrid/include/wx/propgrid/odcombo.h (working copy)
@@ -37,8 +37,8 @@
#define wxPGRectContains Contains
#endif
-class WXDLLEXPORT wxTextCtrl;
-class WXDLLEXPORT wxButton;
+class wxTextCtrl;
+class wxButton;
#ifdef WXMAKINGLIB_PROPGRID
#define WXDLLEXPORT_PGODC
Index: src/include/xtra_res.h
===================================================================
--- src/include/xtra_res.h (revision 4580)
+++ src/include/xtra_res.h (working copy)
@@ -10,7 +10,7 @@
#endif
-class WXDLLEXPORT wxXmlResourceHandler;
+class wxXmlResourceHandler;
class wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
{
Byo is the only one using wxPropertyGrid. I think you should just wait for him to finish his update to the most recent version (which has been talked of a few weeks ago). Then wxPropertyGrid will be gone from the Code::Blocks SDK anyway, and possibly the warnings are magically gone too.
Ok, I'll start working on wxPropertyGrid, but it may take a while (over a week in the worst case), don't have much time now.
BYO
I added the const, but on linux everything builded fine for me, just tried on windows same issue, but why should it not be const ??
[now the warning will be back :-( ] It is used once at a place where I cast away the const, but as fas as I can't tell from the wx doc, it seems the argument will not be changed by the wxImage method [not even delete since 2e arg is true]
Have undo-ed that const in the meantime.
[I wonder why make or gcc apparently is not working correctly, since for some it breaks compilation, for others it don't]
Confirmed. SVN access via SVN does not work,
but SVN access via HTTP works.