Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on January 12, 2019, 07:11:09 pm

Title: The 12 January 2019 build (11552) is out.
Post by: killerbot on January 12, 2019, 07:11:09 pm
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll(s) for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx311_gcc810-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 12 January 2019 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2019/CB_20190112_rev11552_win64.7z
  - Linux :
   none

The current SDK version is : 1.37.0

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 12 January 2019 build (11552) is out.
Post by: Xaviou on January 12, 2019, 11:44:15 pm
Hi

OS X version of this rev can be downloaded from my Google Drive (https://drive.google.com/open?id=0B2rFQ8rNHzEeN0xtU3R6emdhUWs).

Debian Stretch (32 and 64 bits) can be installed from my repo (https://wxstuff.xaviou.fr/article/debian-repository.html).

Regards
Xav'
Title: Re: The 12 January 2019 build (11552) is out.
Post by: kingfox on January 13, 2019, 04:34:03 am
Wonderful !!! ;D
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Karutoh on January 15, 2019, 10:43:19 pm
There's a problem when I create an empty file. It's been doing this through a lot of nightly build versions.

Title: Re: The 12 January 2019 build (11552) is out.
Post by: BlueHazzard on January 16, 2019, 12:08:25 am
There's a problem when I create an empty file. It's been doing this through a lot of nightly build versions.

Can you please describe the exact steps you do?
Something like:
1) Open codeblocks version XXX
2) Create a New file with File->New->File
3) Save file
4) Error message appears
ecc....
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Karutoh on January 16, 2019, 12:21:11 am
1.) Open codeblocks version "svn build rev 11552"
2.) Load my projects
3.) Select the project I want to create a new file for
4.) Created a New file with File->New->Empty File
5.) Prompts me with, "Do you want to add this new file to an active project (has to be saved first)?"
6.) I click, "yes"
7.) I save the file under my project's directory
8.) The error shown above appears
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on January 16, 2019, 09:21:00 am
This is due to a failed encoding detection. You can work around this changing the configuration in Settings->Editor->General settings->Encoding settings to bypass C::B autodetection.

Anyway this is only a warning.

EDIT: The problem is in sdk\filemanager.cpp:416, wxCSConv doesn't like wxFONTENCODING_DEFAULT. The file is empty, so autodetection always fails. If I change line 416 to

Code
wxCSConv csconv(wxFONTENCODING_SYSTEM);

then the assert goes away.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Frank_CB on January 16, 2019, 11:00:32 pm
Installed the 01/12/2019 Nightly Build (11552).

Then built C::B from SVN 11554 source, with mingw-w64-gcc-8.1.0 compiler, on Win10 64-bit platform, using the 11552 nightly.

The following contributed plugins failed to build: SpellChecker and Exporter

SVN 11554 source also has the files for the following contributed plugins: appdata, pythonplugins, valgrind, wxSmithDemo, wxSmithExplorer and wxSmithSTC. Were these suppose to be included in the ContribPlugins.wx31_64.workspace?

Regards!
Title: Re: The 12 January 2019 build (11552) is out.
Post by: oBFusCATed on January 16, 2019, 11:09:58 pm
The following contributed plugins failed to build: SpellChecker and Exporter
Are there any build errors?
Title: Re: The 12 January 2019 build (11552) is out.
Post by: stahta01 on January 17, 2019, 12:17:48 am
SVN 11554 source also has the files for the following contributed plugins: appdata, pythonplugins, valgrind, wxSmithDemo, wxSmithExplorer and wxSmithSTC. Were these suppose to be included in the ContribPlugins.wx31_64.workspace?

appdata                 Never heard of this plugin
pythonplugins        No
valgrind                 No, this is a non windows plugin that is included in Linux/Unix workspace
wxSmithDemo        No
wxSmithExplorer    I forgot about this plugin
wxSmithSTC           No

Tim S.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Frank_CB on January 17, 2019, 04:14:20 am
@oBFusCated  Warnings and Errors for both plugins will be sent tomorrow.

@stahta01  Thanks for your response.

Regards
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Frank_CB on January 17, 2019, 05:11:31 pm
@oBFusCated

The Build Messages continuing the warnings and errors for SpelllChecker and Exporter are attached, as separate files.

Regards
Title: Re: The 12 January 2019 build (11552) is out.
Post by: oBFusCATed on January 17, 2019, 07:55:02 pm
It seems these projects doesn't link to some base library. Or you're not using a monolithic wxwidgets, but this is highly unlikely.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: stahta01 on January 17, 2019, 09:04:22 pm
Frank_CB: What version of wxWidgets library did you use 3.1.1 or 3.1.2?

Edit: found 3.1.2 in logs

If I get free time I will try to duplicate your build issue with  SpellChecker and Exporter plugins.

Edit: Started building wxWidgets which can take a few hours

Edit: Did not see the problem when I built using CB 17.12; will try it with the nightly build, likely be a day or two.
Edit: The NB did not show the error; did show the warning. Possible patch to fix the warning.

Code
diff --git a/src/plugins/contrib/source_exporter/Exporter_wx31_64.cbp b/src/plugins/contrib/source_exporter/Exporter_wx31_64.cbp
index 8588982b8..2e21842a8 100644
--- a/src/plugins/contrib/source_exporter/Exporter_wx31_64.cbp
+++ b/src/plugins/contrib/source_exporter/Exporter_wx31_64.cbp
@@ -58,7 +58,7 @@
  <Target title="default">
  <Option output="../../../devel31_64/share/CodeBlocks/plugins/Exporter" prefix_auto="0" extension_auto="1" />
  <Option object_output="../../../.objs31_64/plugins/contrib/source_exporter" />
- <Option external_deps="wxPdfDocument/lib31_64/wxPdfDocument.a;" />
+ <Option external_deps="wxPdfDocument/lib31_64/libwxPdfDocument.a;" />
  <Option type="3" />
  <Option compiler="gcc" />
  <Option parameters="--debug-log --multiple-instance -na -ns -nd -p debug" />
--
2.19.1.windows.1

Tim S.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Frank_CB on January 18, 2019, 05:40:41 am
Using Monolithic build of wxWidgets-3.1.2.

Started having issues with SVN 11552 source. Used mingw-w64-gcc-8.1.0 as the compiler since it started being used to create NBs.

Regards
Title: Re: The 12 January 2019 build (11552) is out.
Post by: stahta01 on January 18, 2019, 01:22:08 pm
Using Monolithic build of wxWidgets-3.1.2.

Started having issues with SVN 11552 source. Used mingw-w64-gcc-8.1.0 as the compiler since it started being used to create NBs.

Regards

You did try rebuilding the two projects with the virtual target "All" selected?

Tim S.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Frank_CB on January 18, 2019, 06:32:21 pm
You did try rebuilding the two projects with the virtual target "All" selected?

I never noticed when it was orginaly done, so I just redid it with "All" definitely selected. Exporter failed again.  Removed Expoorter and Spellchecker files from workspace and rebuilt.  Workspace completed successfully.  Re-added files for Exporter and Spellchecker recursively.

Exporter failed again because it couldn't find wxScintilla.h.  Spellchecker failed again because it couldn't find annoyingdialog.h.  I coidn't find either header file in wxWidgets-3.1.2\includw. What does that imply?

Regards.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: oBFusCATed on January 18, 2019, 06:36:03 pm
Exporter failed again because it couldn't find wxSinctilla.h.  Spellchecker failed again because it couldn't find annoyingdialog.h.  I coidn't find either header file in wxWidgets-3.1.2\includw. What does that imply?
These are files from the cb's sources and not from wxwidgets. Something is broken on your side, I guess, but I'm not using windows regularly, so I don't know.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Frank_CB on January 18, 2019, 07:50:19 pm
These are files from the cb's sources and not from wxwidgets. Something is broken on your side, I guess, but I'm not using windows regularly, so I don't know.

Thanks for the information.

I found those headers in SVN 11554's source.  Will try to fix the two plugins on my platform.

Regards. 
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Frank_CB on January 19, 2019, 05:58:27 pm
...Will try to fix the two plugins on my platform.
My bad.

Had used wrong URL to obtain SVN 11554 source.  Have made correction.

Exporter and SpellChecker now building correctly within workspace. Building rest of workspace currently.

Thanks for the suggestions and remarks!

Regards.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: delphi13 on February 05, 2019, 09:38:45 pm
Unless I am missing something really obvious, it appears the pre-build steps are not being called when rebuilding a project using the Code::Blocks command line.  Inside the environment everything is working fine, but when called with --rebuild from the command line it exits almost immediately with "Nothing to be done (all items are up-to-date)."  I couldn't see any options on the Wiki for command line use referring to the pre or post steps.

I upgraded to this nightly from an older install (17.12) hoping it might be fixed, but there was no change.

I've successfully automated other projects to build using the command line, but this one needs a pre-build step to run qmake.

Any suggestions?
Title: Re: The 12 January 2019 build (11552) is out.
Post by: BlueHazzard on February 06, 2019, 12:15:30 am
Can you provide full steps to reproduce, with minimal example project?
Title: Re: The 12 January 2019 build (11552) is out.
Post by: delphi13 on February 06, 2019, 06:36:36 pm
It appears my "Unless I am missing something really obvious" statement came true. While building the minimal example I had the same problem occur. However when double checking things before submitting I noticed the case was wrong on the build target name ("Release" vs. "release"). Going back to my original project I had done the same thing there.

If you're open to process improvements, perhaps an error could be added to Code::Blocks if the command line --target doesn't match any of the build target names in the project. Currently it displays "Nothing to be done (all items are up-to-date)." which is not the most helpful thing when trying to debug human errors.

It's the simple things that often take the longest to find. Sorry for the false alarm.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Manolo on February 06, 2019, 09:17:28 pm
Since several nighties, C::B flickes on the task bar when it starts. See attached gif (the smallest I could create).

Windows 10 1803 (17134.523)
Title: Re: The 12 January 2019 build (11552) is out.
Post by: BlueHazzard on February 07, 2019, 02:03:11 am
If you're open to process improvements, perhaps an error could be added to Code::Blocks if the command line --target doesn't match any of the build target names in the project. Currently it displays "Nothing to be done (all items are up-to-date)." which is not the most helpful thing when trying to debug human errors.
a ticket only for you: https://sourceforge.net/p/codeblocks/tickets/796/ ;)
Title: Re: The 12 January 2019 build (11552) is out.
Post by: riban on February 21, 2019, 02:45:10 pm
Since several nighties, C::B flickes on the task bar when it starts. See attached gif (the smallest I could create).

Windows 10 1803 (17134.523)

I experience this too. I thought it might be something else in Windows but I guess it is only CodeBlocks doing it. I see this with Windows 7 Professional 64-bit.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on February 21, 2019, 03:02:20 pm
The flickering has been always there (every time a plugin loads a C::B icon appears and then disappears).

Now it is more visible because the old splash screen created a fixed icon that covered the plugin icons almost completely, but the new splash screen (using wxSplashCreen from wxWidgets) does not create such task bar icon.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: oBFusCATed on February 21, 2019, 08:39:28 pm
Can someone try to find why this problem happens?
Title: Re: The 12 January 2019 build (11552) is out.
Post by: BlueHazzard on February 22, 2019, 10:49:13 am
Quote
every time a plugin loads a C::B icon appears and then disappears
Plugins or wxAUI windows? I was thinking this comes from top level windows created...
I do not think that there is an easy fix...
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on February 22, 2019, 11:34:40 am
Quote
Plugins or wxAUI windows?

Will check.

The problem with wxSplashScreen is that it uses wxFRAME_TOOL_WINDOW and wxFRAME_NO_TASKBAR; both imply that no taskbar icon will be shown.

There are three possible solutions:
  1.- restore previous behaviour of the splash screen (icon in taskbar with flashing icons behind it)
  2.- no icon with splash screen and try to remove flashing icons for plugins/AUI windows
  3.- Icon with splash screen, try to remove flashing icons.

Option 1 is easy. Option 2 means no icon will be shown until the main window is opened, and may be less easy. 3 may be easy or not.

Which is the preferred way?
Title: Re: The 12 January 2019 build (11552) is out.
Post by: oBFusCATed on February 22, 2019, 07:07:31 pm
4. Find out why flashing happens and eradicate it.  8) :o  ;D
Title: Re: The 12 January 2019 build (11552) is out.
Post by: New Pagodi on February 23, 2019, 12:19:23 am
Quote
Plugins or wxAUI windows?

Will check.

The problem with wxSplashScreen is that it uses wxFRAME_TOOL_WINDOW and wxFRAME_NO_TASKBAR; both imply that no taskbar icon will be shown.

There are three possible solutions:
  1.- restore previous behaviour of the splash screen (icon in taskbar with flashing icons behind it)
  2.- no icon with splash screen and try to remove flashing icons for plugins/AUI windows
  3.- Icon with splash screen, try to remove flashing icons.

Option 1 is easy. Option 2 means no icon will be shown until the main window is opened, and may be less easy. 3 may be easy or not.

Which is the preferred way?

You can override wxWidgets' choices for window styles by calling winapi functions in the splash screen constructor.  Two things that look like they might be promising to me are to remove the WS_EX_APPWINDOW flag and add the WS_EX_NOACTIVATE flag.

Code
#ifdef __WXMSW__
    WXHWND hWnd = reinterpret_cast<WXHWND>(GetHandle());
    wxIntPtr winExStyle = ::GetWindowLongPtr(hWnd, GWL_EXSTYLE);
    winExStyle &= ~WS_EX_APPWINDOW;  // remove WS_EX_APPWINDOW flag
    winExStyle |= WS_EX_NOACTIVATE;  // add WS_EX_NOACTIVATE flag
    ::SetWindowLongPtr(hWnd, GWL_EXSTYLE, winExStyle);
#endif

The documentation for SetWindowLongPtr says

Quote
Certain window data is cached, so changes you make using SetWindowLongPtr will not take effect until you call the SetWindowPos function.

so you may have to add a line like this at the end

Code
    ::SetWindowPos(hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOREPOSITION|SWP_NOACTIVATE);

The only problem is you'll have to add user32.lib to the link libraries. I don't know how the codeblocks build system works, so that may or may not be a big problem.

relevant references:
GetWindowLongPtr (https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getwindowlongptra)
SetWindowLongPtr (https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setwindowlongptra)

Window Styles (https://docs.microsoft.com/en-us/windows/desktop/winmsg/window-styles)
Extended Window Styles (https://docs.microsoft.com/en-us/windows/desktop/winmsg/extended-window-styles)

SetWindowPos (https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setwindowpos)
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on February 23, 2019, 11:28:25 am
The icon appears and disappears when calling cbPlugin::OnAttach() within cbPlugin::Attach() (in cbplugin.cpp:73). The OnAttach() method is overriden by every plugin, so I think the problem is inside some of the plugins, probably when creating the log window.

I will explore further this weekend.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on February 25, 2019, 09:56:08 am
The creator of the flashing icons is the compiler plugin; all the icons appears inside

Code
void CompilerGCC::DoRegisterCompilers()

with one icon for every call to

Code
CompilerFactory::RegisterCompiler(new Compiler....);

The RegisterCompiler method only inserts the new compiler in a list, so the problem must be inside the Compiler constructor.

EDIT: the icon appears while executing void Compiler::LoadDefaultOptions(const wxString& name, int recursion)
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on February 25, 2019, 02:51:24 pm
OK, the problem is in compiler.cpp:1242. The call to wxExecute() makes the icon appear while the command is executing.
Adding the wxEXEC_HIDE_CONSOLE flag does not change anything.

EDIT: there is another call in complierMINGW.cpp:234
Title: Re: The 12 January 2019 build (11552) is out.
Post by: oBFusCATed on February 25, 2019, 07:46:42 pm
Seems familiar... :(
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on February 26, 2019, 01:13:29 pm
This patch solves the flashing icons issue with the compiler plugin in MSW. It does not modify the other platforms.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: oBFusCATed on February 26, 2019, 09:01:46 pm
This is one very brave patch.
You'll have to explain why this works because the patch contains just a single vague comment.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on February 27, 2019, 09:49:26 am
This is the commented and revised patch. I changed the call to wxTheApp()->Yield() with Manager::Yield().

Tested in Windows 7 and Windows 10 with wx3.1.2.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on March 04, 2019, 01:49:59 pm
Created ticket 805

https://sourceforge.net/p/codeblocks/tickets/805/ (https://sourceforge.net/p/codeblocks/tickets/805/)
Title: Re: The 12 January 2019 build (11552) is out.
Post by: MortenMacFly on March 09, 2019, 09:49:10 am
a ticket only for you: https://sourceforge.net/p/codeblocks/tickets/796/ ;)
...unfortunately the patch attached (https://sourceforge.net/p/codeblocks/tickets/805/attachment/execute.patch) does not compile wit wx2.8.x.

The method wxTextInputStream::GetInputStream() is available since wx2.9.2 only.

The check on the parent (input stream) may work though but needs testing.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on March 09, 2019, 10:39:45 am
Thank you for the revision. I have corrected the patch and posted it again in the ticket.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: MortenMacFly on March 09, 2019, 11:07:26 am
Thank you for the revision. I have corrected the patch and posted it again in the ticket.
I am testing this from now on. It may resolve another issue I was facing on Windows "on accident". Nag me if you like after a week or so to see if I figured out some unexpected problems. :-)
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on March 18, 2019, 09:21:11 am
Nag me if you like after a week or so to see if I figured out some unexpected problems. :-)

Consider yourself nagged.  ;) Have you found any glitch?.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: MortenMacFly on May 21, 2019, 07:40:15 pm
Consider yourself nagged.  ;) Have you found any glitch?.
Not on Windows. It seems to work just fine. I would welcome people testing it on Linux?! My VM is too old by now... :-(
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on January 02, 2020, 01:21:38 pm
@Morten, the Linux version is not affected by the patch. If it works fine in Windows, please consider applying it to trunk.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: gd_on on January 02, 2020, 04:03:32 pm
Hi,
I tried to apply the patch found in ticket 805 (the revised version) on my svn revision (11931). But I obtain compilation errors, even on a full rebuild :
Code
||=== Nettoyer : tinyXML dans Code::Blocks wx3.1.x (64 bit) (compilateur : GNU GCC Compiler) ===|
...
||=== Générer : Squirrel dans Code::Blocks wx3.1.x (64 bit) (compilateur : GNU GCC Compiler) ===|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqapi.cpp||In function 'SQRESULT sq_setdelegate(HSQUIRRELVM, SQInteger)':|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqapi.cpp|784|warning: this 'if' clause does not guard... [-Wmisleading-indentation]|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqapi.cpp|784|note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'|
include\scripting\squirrel\squtils.h||In instantiation of 'void sqvector<T>::remove(SQUnsignedInteger) [with T = SQObjectPtr; SQUnsignedInteger = long long unsigned int]':|
include\scripting\squirrel\sqarray.h|77|required from here|
include\scripting\squirrel\squtils.h|88|warning: 'void* memmove(void*, const void*, size_t)' writing to an object of type 'struct SQObjectPtr' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]|
include\scripting\squirrel\sqobject.h|130|note: 'struct SQObjectPtr' declared here|
include\scripting\squirrel\squtils.h||In instantiation of 'void sqvector<T>::remove(SQUnsignedInteger) [with T = SQObjectPtr; SQUnsignedInteger = long long unsigned int]':|
include\scripting\squirrel\sqarray.h|77|required from here|
include\scripting\squirrel\squtils.h|88|warning: 'void* memmove(void*, const void*, size_t)' writing to an object of type 'struct SQObjectPtr' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]|
include\scripting\squirrel\sqobject.h|130|note: 'struct SQObjectPtr' declared here|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqcompiler.cpp||In member function 'void SQCompiler::ParseTableOrClass(SQInteger, SQInteger)':|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqcompiler.cpp|829|warning: unused variable 'attrs' [-Wunused-variable]|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqdebug.cpp||In member function 'SQString* SQVM::PrintObjVal(const SQObject&)':|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqdebug.cpp|79|warning: format '%d' expects argument of type 'int', but argument 3 has type 'SQInteger' {aka 'long long int'} [-Wformat=]|
include\scripting\include\squirrel.h|151|note: in definition of macro '_SC'|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqfuncstate.cpp||In function 'void DumpLiteral(SQObjectPtr&)':|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqfuncstate.cpp|85|warning: format '%d' expects argument of type 'int', but argument 2 has type 'SQInteger' {aka 'long long int'} [-Wformat=]|
include\scripting\include\squirrel.h|151|note: in definition of macro '_SC'|
include\scripting\squirrel\squtils.h||In instantiation of 'void sqvector<T>::remove(SQUnsignedInteger) [with T = SQObjectPtr; SQUnsignedInteger = long long unsigned int]':|
include\scripting\squirrel\sqarray.h|77|required from here|
include\scripting\squirrel\squtils.h|88|warning: 'void* memmove(void*, const void*, size_t)' writing to an object of type 'struct SQObjectPtr' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]|
include\scripting\squirrel\sqobject.h|130|note: 'struct SQObjectPtr' declared here|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqstate.cpp||In member function 'SQInteger SQSharedState::CollectGarbage(SQVM*)':|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqstate.cpp|255|warning: unused variable 'x' [-Wunused-variable]|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqstate.cpp|292|warning: unused variable 'z' [-Wunused-variable]|
include\scripting\squirrel\squtils.h||In instantiation of 'void sqvector<T>::remove(SQUnsignedInteger) [with T = SQObjectPtr; SQUnsignedInteger = long long unsigned int]':|
include\scripting\squirrel\sqarray.h|77|required from here|
include\scripting\squirrel\squtils.h|88|warning: 'void* memmove(void*, const void*, size_t)' writing to an object of type 'struct SQObjectPtr' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]|
include\scripting\squirrel\sqobject.h|130|note: 'struct SQObjectPtr' declared here|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqvm.cpp||In member function 'void SQVM::ToString(const SQObjectPtr&, SQObjectPtr&)':|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\scripting\squirrel\sqvm.cpp|254|warning: format '%d' expects argument of type 'int', but argument 3 has type 'SQInteger' {aka 'long long int'} [-Wformat=]|
include\scripting\include\squirrel.h|151|note: in definition of macro '_SC'|
include\scripting\squirrel\squtils.h||In instantiation of 'void sqvector<T>::remove(SQUnsignedInteger) [with T = SQObjectPtr; SQUnsignedInteger = long long unsigned int]':|
include\scripting\squirrel\sqarray.h|77|required from here|
include\scripting\squirrel\squtils.h|88|warning: 'void* memmove(void*, const void*, size_t)' writing to an object of type 'struct SQObjectPtr' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]|
include\scripting\squirrel\sqobject.h|130|note: 'struct SQObjectPtr' declared here|
||=== Générer : Squirrel std lib dans Code::Blocks wx3.1.x (64 bit) (compilateur : GNU GCC Compiler) ===|
||=== Générer : SqPlus dans Code::Blocks wx3.1.x (64 bit) (compilateur : GNU GCC Compiler) ===|
||=== Générer : scintilla dans Code::Blocks wx3.1.x (64 bit) (compilateur : GNU GCC Compiler) ===|
||=== Générer : sdk dans Code::Blocks wx3.1.x (64 bit) (compilateur : GNU GCC Compiler) ===|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\compiler.cpp|1287|error: invalid use of incomplete type 'class wxProcess'|
C:\wxWidgets-3.1.3\include\wx\utils.h|51|note: forward declaration of 'class wxProcess'|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\compiler.cpp||In member function 'long int Compiler::Execute(const wxString&, wxArrayString&)':|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\compiler.cpp|1317|error: 'class ExecProcess' has no member named 'Redirect'|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\compiler.cpp|1321|error: no matching function for call to 'wxExecute(const wxString&, <unnamed enum>, ExecProcess*)'|
C:\wxWidgets-3.1.3\include\wx\utils.h|388|note: candidate: 'long int wxExecute(const wxString&, int, wxProcess*, const wxExecuteEnv*)'|
C:\wxWidgets-3.1.3\include\wx\utils.h|388|note:   no known conversion for argument 3 from 'ExecProcess*' to 'wxProcess*'|
C:\wxWidgets-3.1.3\include\wx\utils.h|392|note: candidate: 'long int wxExecute(const char* const*, int, wxProcess*, const wxExecuteEnv*)'|
C:\wxWidgets-3.1.3\include\wx\utils.h|392|note:   no known conversion for argument 3 from 'ExecProcess*' to 'wxProcess*'|
C:\wxWidgets-3.1.3\include\wx\utils.h|397|note: candidate: 'long int wxExecute(const wchar_t* const*, int, wxProcess*, const wxExecuteEnv*)'|
C:\wxWidgets-3.1.3\include\wx\utils.h|397|note:   no known conversion for argument 3 from 'ExecProcess*' to 'wxProcess*'|
C:\wxWidgets-3.1.3\include\wx\utils.h|405|note: candidate: 'long int wxExecute(const wxString&, wxArrayString&, int, const wxExecuteEnv*)'|
C:\wxWidgets-3.1.3\include\wx\utils.h|405|note:   no known conversion for argument 2 from '<unnamed enum>' to 'wxArrayString&'|
C:\wxWidgets-3.1.3\include\wx\utils.h|411|note: candidate: 'long int wxExecute(const wxString&, wxArrayString&, wxArrayString&, int, const wxExecuteEnv*)'|
C:\wxWidgets-3.1.3\include\wx\utils.h|411|note:   no known conversion for argument 2 from '<unnamed enum>' to 'wxArrayString&'|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\compiler.cpp|1331|error: 'class ExecProcess' has no member named 'GetInputStream'|
C:\Users\Gerard\Documents\CodeBlocks_SVN\CodeBlocks_src\src\sdk\compiler.cpp|1332|error: variable 'wxTextInputStream text' has initializer but incomplete type|
||=== Génération de terminé : 5 erreur(s), 22 avertissement(s) (1 minute(s), 43 seconde(s)) ===|

Did I forget something ?
Title: Re: The 12 January 2019 build (11552) is out.
Post by: Miguel Gimenez on January 02, 2020, 04:56:47 pm
I am now very far away from home, so I can't check this until next week.

I don't know why it compiled a year ago and not now, but probably adding this

Code
#include <wx/process.h>
#include <wx/txtstrm.h>

to compiler.cpp fixes the issue.
Title: Re: The 12 January 2019 build (11552) is out.
Post by: gd_on on January 02, 2020, 05:51:49 pm
OK, that did the job. Thanks.
As I didn't know if it's better to put these lines inside or outside the CB_PRECOMP bloc, I have added them outside, at line 30. It's OK there apparently. And the most important, it works : no flashing icon !
Thanks again.
hace a nice trip and an Happy New Year :D

gd_on