Release 15.12, RC1 has arrived

[Krice]

Settings - Environment... and it actually works for CppCheck.

Here some more finds:
-Compile doesn't switch to build log, which is annoying.
-How to clear build log?
-Find implementation doesn't work if declaration has typedef for variable type and definition doesn't (for example Uint8 - unsigned char which are the same type).
-gcc is showing compiler warnings for external header files (in this case SDL_stdinc.h of SDL2), I don't know if this is C::B problem or not.

[BlueHazzard]

-How to clear build log?

You can't clear the build log (Why would you clear it?). It gets cleared automatically if you hit the build button. You can hide the build log with the F2 key or set the auto hide setting: Settings->Environment->View->Auto hide/show message pane

-Find implementation doesn't work if declaration has typedef for variable type and definition doesn't (for example Uint8 - unsigned char which are the same type).

can you give a minimal code example?

Settings - Environment... and it actually works for CppCheck.

Here some more finds:
-gcc is showing compiler warnings for external header files (in this case SDL_stdinc.h of SDL2), I don't know if this is C::B problem or not.

Are you using SDL? Have you created your project with the SDL wizard? Can you post a full rebuild log?

thank you for reporting your findings

[BlueHazzard]

It would be worth to think about shipping a current release of these tools with the release. The two tools are really tiny...

And answer all the cppcheck related questions from noobs in this forum 

[Krice]

You can't clear the build log (Why would you clear it?).

I wanted that stuff to clear when compiling a single file, but now I noticed there is also Build messages.. I think it's kind of confusing to have two logs for the same thing, but I guess there is some kind of logic there.

can you give a minimal code example?

surface.h:
void Set_Colorkey(Uint8 r, Uint8 g, Uint8 b);

surface.cpp:
void G_Surface::Set_Colorkey(unsigned char r, unsigned char g, unsigned char b)

If you try to find implementation from the header, it doesn't find it because while types are same the definition is not using typedef (which could be fixed, but..)

Have you created your project with the SDL wizard?

No. I always create an empty project for that. However I found the reason: if you put SDL file locations to Compiler search directory then it's warning about SDL header problems. I fixed that by copying SDL include directory to gcc's include and also SDL library files to gcc library directory and of course removing search directory locations.

[Miguel Gimenez]

You can't clear the build log (Why would you clear it?). It gets cleared automatically if you hit the build button. You can hide the build log with the F2 key or set the auto hide setting: Settings->Environment->View->Auto hide/show message pane

I think that the build log (and build messages) should be cleared when closing a workspace. If I change workspaces, the old build log is there.

[Pecan]

Right-click the tab (eg. Build Log) and click "clear contents"

One log is for messages from CodeBlocks while the other log is for message from the compiler.

IMHO, merging the two would be most confusing.

[MortenMacFly]

-How to clear build log?

You can clear any log (including the build log) if you right-click on the tab ans select "clear".

[Krice]

IMHO, merging the two would be most confusing.

Visual Studio has only one Output window for compiler messages (which also clear when you compile a file or build the project). I think it's less confusing.

[Morwenn]

It would be worth to think about shipping a current release of these tools with the release. The two tools are really tiny...

Yes please :p

While the tools are easy to install, people won't generally bother if they are not installed by default. When I started using Code::Blocks, I think that the time I actually started using CppCheck and CCCC was delayed by a few because I didn't really want to install a few tools I didn't know and whose value I didn't understand at the time. I think that it would make people discover the tools sooner and avoid questions about why they don't work out-of-the-box.

To sum up, while these tools are easy to install, people aren't likely to install them if they don't already know what they do (which they could discover in no time if the binaries shipped with Code::Blocks).

[scarphin]

Shipping 3rd party tools with cb won't be a good idea imo. I can think of at least 2 reasons:
1- I prefer not to add cb binary path to my system path as it's a mess already,
2- Updating the 3rd party tool by hand might generate other problems for the users that has manually installed the tool.

[White-Tiger]

[...]
Windows XP Look'n'feel -> You need a gui program. This plugin creates the manifest file that you get a XP Looking gui (this can probably be removed because it isn't necessary in windows > XP, but there are still people out there that use XP)
[...]

well... it's still necessary even though I've never used the plugin as it is lacking important features and I'm also preferring tabs to spaces to reduce my program's size.
And also quite important: it's useless for x86_64.

A proper (and "minimal") manifest would have to look like this (for XP and >Vista support)

Code: xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<dependency>
<dependentAssembly>
	<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
	<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
	<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/><!--7-->
	<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/><!--8-->
	<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/><!--8.1-->
	<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/><!--10-->
</application>
</compatibility>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
	<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>

For comparison, this is the generated XP manifest: (also note that it's using \n as line break which won't work for most Windows users as it'll look like a huge single line in Notepad)

Code: xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>"
<assembly
  xmlns="urn:schemas-microsoft-com:asm.v1"
  manifestVersion="1.0">
<assemblyIdentity
    name="PROJECT.TARGET.App"
    processorArchitecture="x86"
    version="1.0.0.0"
    type="win32"/>
<description>Executable</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

[stahta01]

Several months or a year or so ago, Cygwin redid their Compiler exe names.
The gcc-3.exe is no longer in the installation. Using GCC 4.9.? GCC version as of  today.

Tim S.

Code

From 1208d759474681795640e974263b74065241d324 Mon Sep 17 00:00:00 2001
From: Tim S <stahta01@users.sourceforge.net>
Date: Fri, 4 Dec 2015 14:46:56 -0500
Subject: [PATCH 2/2] * cygwin_support: Removed "-3" suffix from exe files.
 (Thanks stahta01)

---
 .../compilergcc/resources/compilers/options_cygwin.xml      | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/plugins/compilergcc/resources/compilers/options_cygwin.xml b/src/plugins/compilergcc/resources/compilers/options_cygwin.xml
index fca1b7c..5f46924 100644
--- a/src/plugins/compilergcc/resources/compilers/options_cygwin.xml
+++ b/src/plugins/compilergcc/resources/compilers/options_cygwin.xml
@@ -1,12 +1,13 @@
 <?xml version="1.0"?>
 <!DOCTYPE CodeBlocks_compiler_options>
 <CodeBlocks_compiler_options extends="gcc">
-    <!-- NOTE: Cygwin's gcc.exe maybe a file link and
-         is not a good default name for running via cmd.exe
-         TODO: May also be gcc-4.exe!!! -->
-    <Program name="C"         value="gcc-3.exe"/>
-    <Program name="CPP"       value="g++-3.exe"/>
-    <Program name="LD"        value="g++-3.exe"/>
+    <!-- NOTE: In the old Cygwin's gcc.exe maybe a file
+         link and is not a good default name for
+         running via cmd.exe; tested good using gcc.exe
+         and g++.exe under Cygwin 2.873 32 bit -->
+    <Program name="C"         value="gcc.exe"/>
+    <Program name="CPP"       value="g++.exe"/>
+    <Program name="LD"        value="g++.exe"/>
     <Program name="DBGconfig" value="gdb_debugger:Default"/>
     <Program name="LIB"       value="ar.exe"/>
     <Program name="WINDRES"   value="windres.exe"/>
-- 
2.6.3.windows.1

[MortenMacFly]

The gcc-3.exe is no longer in the installation. Using GCC 4.9.? GCC version as of  today.

I noted that one, too and had to modify my local (run-time) C::B already way back. I would say its more years than month. So its time to make it official. Your patch is in trunk now. Thank you!

[dcorbit]

The Watcom compilers are now available in 64 bits (C/C++/Fortran77):
http://sourceforge.net/projects/openwatcom/

When I tried to configure the Watcom Fortran compiler using 15.12 RC1, it reverted to strange settings (gunk from GCC, Watcom C stuff, clearly did not understand what to do).

Feature request (I know, not for this release):
Run a batch file to set the environment for a given compiler.
For instance, for Watcom, it is:
C:\WATCOM\owsetenv.bat
in my case for Watcom.

Also, LLVM gets installed here when I run the Installation for Visual Studio:
C:\Program Files\LLVM

I would like to be able to run it from Code::Blocks also.

[dcorbit]

F:\hello>wfl386 hello.f
Open Watcom F77 x86 32-bit Compile and Link Utility
Version 2.0 beta Apr  2 2015 10:17:14 (64-bit)
Copyright (c) 2002-2015 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1990-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
        wfc386 hello.f
Open Watcom FORTRAN 77 x86 32-bit Optimizing Compiler
Version 2.0 beta Apr  2 2015 10:10:56 (64-bit)
Copyright (c) 2002-2015 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
hello.f: 5 statements, 37 bytes, 2 extensions, 0 warnings, 0 errors
        wlink @__wfl__.lnk
Open Watcom Linker Version 2.0 beta Apr  2 2015 09:56:44 (64-bit)
Copyright (c) 2002-2015 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT character-mode executable

F:\hello>hello
  Hello, world!

F:\hello>depends hello.exe

F:\hello>type hello.f
      program main

c*********************************************************************72
c
cc MAIN is the main program for HELLO.
c
c  Discussion:
c
c    HELLO is a simple FORTRAN77 program that says "Hello, world!".
c
c  Licensing:
c
c    This code is distributed under the GNU LGPL license.
c
c  Modified:
c
c    18 May 2009
c
c  Author:
c
c    John Burkardt
c
      implicit none

      write ( *, '(a)' ) '  Hello, world!'

      stop
      end

F:\hello>