I noticed that when I build my project in this nightly, the log shows that it passed "-Wall -g" compiler parameters twice each to the command used to compile each of the source files. I doubt a well-designed compiler would care (GCC doesn't seem to mind) if such parameters were given multiple times, but I don't remember seeing this before, is it some new kind of behavior that shouldn't be happening?The parameters are a sum of the global compiler options (including additional options), the project options, the target options and attached scripts. It such options appear multiple times they might be defined in more than one place by you. Check the settings of you compiler/project accordingly. Nevertheless, as long as these options don't conflict (i.e. debug vs. optimisation) the compiler doesn't care and simply skips options appearing twice.
Is there a way to make it build files in alphabetical order once again?No. Files are compiled in order of their weight (which you can adjust in the file's property). Compiling alphabetically would break that important feature.
crashes on vs2012 sln and vcxproj files, please fixProject (file) to reproduce, please?
All of my source files are using the default build weight of 50. If the weight of all files are the same, what is the next criterion used to determine which file is built next? When none of the files have a unique weight, I don't see how building alphabetically by name would break any such feature.Can you provide a minimal test case?
Can you provide a minimal test case?I opened one of my old projects that had only one source file. I added a second source file to it and when I did a full rebuild of the project, it compiled them out of alphabetical order. Both files had a build priority weight of 50, but even after I set the priority for each file to 0, they still built out of alphabetical order. I don't think I can really simplify the problem further, since two files is the minimum for this problem to even be possible.
zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
Possible build issue on Windows.
Building the SDK now causes an zip command error on post build steps.
Happens if the folders CodeBlocks does not exist.
Months ago, the problem did not exist.
Now, I have to create the folders share/CodeBlocks or run the update.bat after I delete or rename the devel folder.Codezip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
Creating library file: devel\libcodeblocks.a
Output size is 52.62 MB
[ 50.0%] Running target post-build steps
[100.0%] zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
zip I/O error: No such file or directory
zip error: Could not create output file (devel/share/CodeBlocks/manager_resources.zip)
Process terminated with status 15 (13 minutes, 41 seconds)
0 errors, 16 warnings (13 minutes, 41 seconds)
Can zip command automatically create a folder?I think we should revert the commit 7972 completely and instead call update[.bat] from the projects post-build step.
After I read the file "update.bat", I agree with you. "update.bat" do more things than just compact the xrc files.Can zip command automatically create a folder?I think we should revert the commit 7972 completely and instead call update[.bat] from the projects post-build step.
Or would this break anything else ?
If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.
It never made it into linux by the way.
call update[.bat] from the projects post-build stepIf so, which target can we put the "update.bat" in post-build step?
If so, which target can we put the "update.bat" in post-build step?
[...] call update[.bat] from the projects post-build step.
typedef std::enable_if<N > 1, get_type_N<N-1, Tail...>> type;Looks like parser gets stuck on "N > 1". If to surround it by parentheses, then all works fine.
If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.True. We basically use two ways to update the resources in all plugins / projects: Either we call an update.bat or we zip the resources form inside the project's post-build steps (in that case these steps should always be executed - that is a common error).
[...]What does not work ?
The latter has one drawback though: If you compile a specific target (like I do sometimes) this won't work probably.
[...]
If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.the wizard created plugins should create a cbplugin-file (packed library and resources), that can be installed by C::B's pluginmanager.
If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.the wizard created plugins should create a cbplugin-file (packed library and resources), that can be installed by C::B's pluginmanager.
Doing this in pre- and postbuild steps would make the compiled plugins undeployable.
So I tend to solution 1: Add the creation of that output folders either to the pre- or post-build steps.I like this solution, because I think each target should contain its own "update" script(not copy or zip other target's data).
Calling update.bat will mean that the output folder copy of Code::Blocks can not be used to build the devel copy of code::blocks.
Tim S.
There is critical bug in C++ parser. If you insert "magic" code in any unit/header file (included in C++ project) then Code::Blocks will hangs up.The code is toooooo magic for me that I can't understand the grammar, but the parser should not hang in any case, so I will dig into it.
Magic code (copy exactly all quote):Quotetypedef std::enable_if<N > 1, get_type_N<N-1, Tail...>> type;Looks like parser gets stuck on "N > 1". If to surround it by parentheses, then all works fine.
The code is toooooo magic for me that I can't understand the grammar, but the parser should not hang in any case, so I will dig into it.This patch can avoid the loop.
src/plugins/codecompletion/parser/parserthread.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/plugins/codecompletion/parser/parserthread.cpp b/src/plugins/codecompletion/parser/parserthread.cpp
index d193e0d..9062ded 100644
--- a/src/plugins/codecompletion/parser/parserthread.cpp
+++ b/src/plugins/codecompletion/parser/parserthread.cpp
@@ -2504,7 +2504,7 @@ void ParserThread::ReadClsNames(wxString& ancestor)
else // unexpected
{
TRACE(_T("ReadClsNames() : Unexpected token '%s'."), token.wx_str());
- m_Tokenizer.UngetToken();
+ //m_Tokenizer.UngetToken();
break;
}
}
What does not work ?It means that pre-requisite might not be fulfilled and therefore the script can fail.
Hello!I do not have such issues here.
First - thanks for your great job. I have recognized since some time that the multi-line edit does not work correctly with using the tab-key or deleting in multi-line edit mode. The first attached screenshot shows the multi-line selection spanning three lines. After pressing the tab-key, the cursor jumps to the first column and selects a region before the previous position (see second screenshot). Using the delete-key (starting from situation in the first screenshot), the result becomes even more strange (see third screenshot). Could you please fix this? Thanks!
Best, Daniel
-- Just see that there is a new nightly. But the issue remains with 8081 as well (on Win7).
Now, nightly 8081 on Win7 using Settings/Editor/.../Selections:Works here with the same settings (fedora 17 64 bit).
[ ] Enable virtual space
[ x ] Allow multiple sections
[ x ] Enable typing ...
Works here with the same settings (fedora 17 64 bit).
I will test it on win7 as soon as possible.
I have downloaded the files "en_US.aff, en_US.dat" from OpenOffice again and copied it into a clean installation/download of CodeBlocks nightly 8081. Actually, I downloaded "en_US.oxt", opened it with 7z and copied the files into the SpellChecker folder.i still cannot reproduce it.
Anyway - again, I can reproduce the above behaviour with the multiline edit. Can someone else reproduce it as well?
Best, Daniel
i still cannot reproduce it.
You can try what happens, if you disable the spellchecker-plugin from "Plugins -> Manage plugins..." and if that helps, what happens if you play with the spellchecker settings (not really much, I know).
This patch can avoid the loop....but introduces a lot other hangs / freezes on "not so complex" code. BE careful, this introduces even more serious hangs!
3. How to install a nightly buildThe 8059 nightly, mingwm10.dll, and wxmsw28u_gcc_cb.dll are all in the C:\Program Files (x86)\CodeBlocks directory, yet I see this error every time I start up CodeBlocks and programs simply do not respond to the Compile button (surprise, surprise).
Allrighty, time for a small recap :
1) CB nightly
2) mingwm10.dll
3) wxmsw28u_gcc_cb.dll
Those are the 3 things we need to install and start up a nigthly build. All 3 of them are available in their own zip file, zipped by using the free and excellent 7-zip (www.7-zip.org). Just get your copy of 7-zip for unzipping.
Final steps :
1) unzip the CB nightly in some directory
2) unzip both dll's : requirement : they need to be in your PATH, most easiest is to unzip both of them into the same directory where you unzipped the nightly, so they reside next to the codeblocks.exe .
By performing these simple steps you nightly is ready to roll.
Some browsing on the forum made it seem like it has something to do with changing Settings > Compiler > (GNU GCC Compiler) > Search Directories to include this path under the Compiler sub-tab ("they need to be in your PATH"), but this only makes the error appear again. Help setting this us would be very appreciated!Well you have to install a full compiler suite (which is not part of the nightlies) and adjust the path to the tool chain executables in the compiler options accordingly. There is a note given what path you have to provide: the "master path" to your compiler, so not the bin sub-folder or alike.
Some browsing on the forum made it seem like it has something to do with changing Settings > Compiler > (GNU GCC Compiler) > Search Directories to include this path under the Compiler sub-tab ("they need to be in your PATH"), but this only makes the error appear again. Help setting this us would be very appreciated!Well you have to install a full compiler suite (which is not part of the nightlies) and adjust the path to the tool chain executables in the compiler options accordingly. There is a note given what path you have to provide: the "master path" to your compiler, so not the bin sub-folder or alike.
else // The compiler is *probably*Ü invalid, but at least a master-path is set else // The compiler is *probably* invalid, but at least a master-path is setthere is apparently a small error introduced at line 71 in sdk/autodetectcompilers.cpp (svn 8086) which makes xgettext fail to prepare strings for CB Translation.My fault. Fixed in SVN.
src\plugins\contrib\wxSmith\wxwidgets\wxsitemresdataobject.cpp|127|warning: converting 'false' to pointer type 'wxsItem*' [-Wconversion-null]|
Index: src/plugins/contrib/wxSmith/wxwidgets/wxsitemresdataobject.cpp
===================================================================
--- src/plugins/contrib/wxSmith/wxwidgets/wxsitemresdataobject.cpp (revision 8093)
+++ src/plugins/contrib/wxSmith/wxwidgets/wxsitemresdataobject.cpp (working copy)
@@ -124,7 +124,7 @@
if ( !Item )
{
Item = wxsItemFactory::Build(_T("Custom"),Data);
- if ( !Item ) return false;
+ if ( !Item ) return 0;
}
Item->XmlRead(Root,true,true);
Do I need to worry about adding the directory for MinGW every time I upgrade the nightly?Usually not. The path is stored in the default.conf configuration file of Code::BLocks which is by default not in the installation folder. However, if you are using a portable installation - then it is. If you remove it, you have to setup the path again afterwards.
I've just switched from 10.05 to nightly build 8059 and have encountered a problem with linker settings (using Ubuntu 12.04, 64-bit). In 10.05 I could specify $ORIGIN in the linker settings by putting '-Wl,-R\\$$ORIGIN' in the 'other linker options' section, but this doesn't work any more. The build log shows '-Wl,-R\\', but no mention of $ORIGIN. Is there a better/different way of specifying $ORIGIN now?Since some revisions we replace macros and variables in the linker settings.