Author Topic: The 06 December 2014 build (10050) is out.  (Read 24975 times)

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 06 December 2014 build (10050) is out.
« Reply #15 on: January 09, 2015, 06:21:50 am »
I have attached a copy of the update_debug.bat can you guys please get it committed?
This will for sure not be committed, because it does not make sense.

The build-process (and update[.bat]-script) create two folders: devel and output.
The first one is (as the name clearly states) for developping and includes debugging symbols, the second one includes the stripped (release-)version.

I don't see any cause to change this.
Renaming the *.bat-files to *.cmd is possible, but has no real benefit (at least not at this moment), but might break existing (more or less aoutomated) build-processes, that rely on the existing names.

Offline Melchior

  • Multiple posting newcomer
  • *
  • Posts: 63
  • Sage of Life, Reason, and Time
Re: The 06 December 2014 build (10050) is out.
« Reply #16 on: January 09, 2015, 07:46:41 am »
I attached a png image where I combined the image of all three Global Variables needed by
Code-blocks....
- Boost
- cb_release_type
- wx

yah I get the "quote" thing... CodeBlocks treats the whole box as a string so " " is unnecessary and
only used here to show a bit of text as a string...
"F:\Dev-src\CodeBlocks_src\src -g"

is what I am using now after your suggestion to add to base and mot a user-defined variable....

I also attached the rpt file I found, thx for letting me know about it =D...


debugging plugin? I didn't see one on the plugin drop down, you must mean the main debug drop down menu..

For most debugging I create a simple cmd file like this one which I created to run codeblocks.exe through gdb...

Debugging (gdb)_CodeBlocks.cmd
Quote
@ECHO on
:: Core Dump Checking through the GNU Debugger (GDB)
::
:: Symbol Servers
::             - http://msdl.microsoft.com/download/symbols
::
:: --directory=" "   // Specifies location of Source code,
::                   // multiply Directories can be listed one per cmd flag.
::
:: --symbols=" "     // Debug Symbol file(s).
:: --exec=" "        // exe to be debugged (does not contain debug symbols).
:: --se=" "          // exe to be debugged (contains debug symbols ^_^).

gdb -readnow -se="codeblocks.exe"
pause



for the .bat to .cmd suggestion, fair enough.


I have attached a copy of the update_debug.bat can you guys please get it committed?
This will for sure not be committed, because it does not make sense.

The build-process (and update[.bat]-script) create two folders: devel and output.
The first one is (as the name clearly states) for developping and includes debugging symbols, the second one includes the stripped (release-)version.

I don't see any cause to change this.
Renaming the *.bat-files to *.cmd is possible, but has no real benefit (at least not at this moment), but might break existing (more or less automated) build-processes, that rely on the existing names.


I believe you misunderstand me....
there exists now in the repo three update.bat files, and all three are release grade:
- update.bat              <-- wx v2.8
- update30.bat          <-- wx v3.0
- update30_64.bat    <-- wx v3.0 but it appears to be 64bit..

all three files already part of the Codeblocks svn repository have strip at the end of them...
Quote
echo Stripping debug info from output tree
strip output30_64\*.exe
strip output30_64\*.dll
strip %CB_OUTPUT_RESDIR%\plugins\*.dll

so I made a copy of the "update.bat" file and renamed it  "update_debug.bat"
where I commented out the strip commands so debugging info remains intact

my customized copy of "update.bat" is not part of the repository and I was asking for it to be added

That and maybe a bit of renaming work...  =D
As these two files imply they are for wxWidgets v3.0
- update30.bat
- update30_64.bat
would it not make sense to rename
update.bat  and update_debug.bat
to
- update28.bat
- update28_debug.bat

?  optional suggestion of course...







[attachment deleted by admin]
(PC Specs)
CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
Motherboard: Asus SABERTOOTH 990FX R2.0
GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
OS: Windows 7 Ultimate 64-bit SP1 (x64)

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 06 December 2014 build (10050) is out.
« Reply #17 on: January 09, 2015, 09:03:21 am »
I have attached a copy of the update_debug.bat can you guys please get it committed?
This will for sure not be committed, because it does not make sense.

The build-process (and update[.bat]-script) create two folders: devel and output.
The first one is (as the name clearly states) for developing and includes debugging symbols, the second one includes the stripped (release-)version.

I don't see any cause to change this.
Renaming the *.bat-files to *.cmd is possible, but has no real benefit (at least not at this moment), but might break existing (more or less automated) build-processes, that rely on the existing names.


I believe you misunderstand me....
I think it's not me who misunderstands something.
It's your choice how to debug C::B, but I prefer to use C::B to do it and never had unsolvable problems.
Using gdb via  commandline is possible and makes sense sometimes, but most of the times a gui is much easier to use.

Offline eMan.Lived

  • Multiple posting newcomer
  • *
  • Posts: 21
Re: The 06 December 2014 build (10050) is out.
« Reply #18 on: January 10, 2015, 02:15:53 am »
The height of the Todo list docked to the top or bottom is not remembered after hiding and is reset to the some minimum in the subsequent show.

BTW, there is some possibility to make the Todo list as a tab in the Logs & others?
[AAAA|+}

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5230
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 December 2014 build (10050) is out.
« Reply #19 on: January 10, 2015, 04:31:26 am »
BTW, there is some possibility to make the Todo list as a tab in the Logs & others?
Yes, you can check on the option: Menu->Settings->Environment->TO DO->Include the todo list in the message panel, and restart C::B.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline eMan.Lived

  • Multiple posting newcomer
  • *
  • Posts: 21
Re: The 06 December 2014 build (10050) is out.
« Reply #20 on: January 10, 2015, 05:52:32 am »
Yes, you can ...
Thanks! Don't know how I missed it. :)
[AAAA|+}

Offline Melchior

  • Multiple posting newcomer
  • *
  • Posts: 63
  • Sage of Life, Reason, and Time
Re: The 06 December 2014 build (10050) is out.
« Reply #21 on: January 10, 2015, 08:45:11 am »
wx_sufix = u
is the default set in each project file...
but DO TO THE FACT that I need to compile a debug version of Codeblocks.... so I can get to the bottom of this bug/crash I discovered...
it is needed to either manually edit every single project file  which will cause them to be out of sync with the repo...
or define a global variable....

some help please...
(PC Specs)
CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
Motherboard: Asus SABERTOOTH 990FX R2.0
GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
OS: Windows 7 Ultimate 64-bit SP1 (x64)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6664
    • My Best Post
Re: The 06 December 2014 build (10050) is out.
« Reply #22 on: January 10, 2015, 09:13:07 am »
wx_sufix = u
is the default set in each project file...
but DO TO THE FACT that I need to compile a debug version of Codeblocks.... so I can get to the bottom of this bug/crash I discovered...
it is needed to either manually edit every single project file  which will cause them to be out of sync with the repo...
or define a global variable....

some help please...

Use the new contrib plugin a few months old named something like project manipulator.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 06 December 2014 build (10050) is out.
« Reply #23 on: January 10, 2015, 09:16:21 am »
wx_sufix = u
is the default set in each project file...
but DO TO THE FACT that I need to compile a debug version of Codeblocks.... so I can get to the bottom of this bug/crash I discovered...
it is needed to either manually edit every single project file  which will cause them to be out of sync with the repo...
or define a global variable....

some help please...
You should not need debug-versions of wxWidgets unless you want to debug wxWidgets itself.

Offline Melchior

  • Multiple posting newcomer
  • *
  • Posts: 63
  • Sage of Life, Reason, and Time
Re: The 06 December 2014 build (10050) is out.
« Reply #24 on: January 10, 2015, 10:57:08 am »
Jens...   it is only makes sense to ensure the complete program and its dependencies EACH have their symbols... 
that way no matter where the bug may be... it can be found without having to compile again and again...

Compiling wxWidgets as debug was easy...
makeWX_dll__gcc__Debug.cmd
Quote
mingw32-make -f makefile.gcc BUILD=debug UNICODE=1 MONOLITHIC=1 SHARED=1 DEBUG_FLAG=1 DEBUG_INFO=1
pause
Compiling Code::Blocks as debug has been a headache,
the project files  DO NOT have a [debug-all] target if you guys could please add one some day would be great ;^_^;
and would make it easier to get a debug build complied

i got around this by editing the
Project build options --> Custom variables -->
changing  [WX_SUFFIX = u]  to [WX_SUFFIX = ud] for each and every file


 thx stahta01's suggestion to use

Plugin --> Project option manipulator

to change [WX_SUFFIX = u]  to [WX_SUFFIX = ud] on all open project files looks like it will work on contrib where there are so many project files on that workspace....

but this method would of course edit all the project files as i mentioned above, making them out of sync to the 
svn-repository....


I am done for one night...
(PC Specs)
CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
Motherboard: Asus SABERTOOTH 990FX R2.0
GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
OS: Windows 7 Ultimate 64-bit SP1 (x64)

Offline eMan.Lived

  • Multiple posting newcomer
  • *
  • Posts: 21
Re: The 06 December 2014 build (10050) is out.
« Reply #25 on: January 11, 2015, 11:51:32 pm »
C::B does not remember the active project in the workspace between sessions.
[AAAA|+}

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12067
    • Travis build status
Re: The 06 December 2014 build (10050) is out.
« Reply #26 on: January 12, 2015, 01:47:05 am »
Yes, it does...
If you're closing codeblocks and not the workspace, then probably it is crashing and it is not saving the bla.workspace.layout file.

Posting the exacts steps to reproduce the problem might be helpful.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5230
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 December 2014 build (10050) is out.
« Reply #27 on: January 12, 2015, 02:03:23 am »
i got around this by editing the
Project build options --> Custom variables -->
changing  [WX_SUFFIX = u]  to [WX_SUFFIX = ud] for each and every file
Yes, the workspace don't have compiler settings, so you need to change the cbp files. Besides the WX_SUFFIX change, you may also need an extra -D__WXDEBUG__ for every cbp, see: annoying crash when debugging CC's auto-suggestion. For git(I use git-svn), this is not an issue, because you can have many branches, and synchronize with our SVN head.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline eMan.Lived

  • Multiple posting newcomer
  • *
  • Posts: 21
Re: The 06 December 2014 build (10050) is out.
« Reply #28 on: January 12, 2015, 02:11:18 am »
Yes, it does...
If you're closing codeblocks and not the workspace, then probably it is crashing and it is not saving the bla.workspace.layout file.

Posting the exacts steps to reproduce the problem might be helpful.

First, I have delete default.workspace.layout and default.workspace.

Start C::B and close it. File default.workspace.layout was created.

Start C::B again and open the project A and then the project B. At this point the project B is active.

Close C::B and answer Yes for "Workspace 'Default workspace' is modified. Do you want to save it?" prompt. File default.workspace was created.

Start C::B. At this point the project A is active not the project B.
[AAAA|+}

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12067
    • Travis build status
Re: The 06 December 2014 build (10050) is out.
« Reply #29 on: January 12, 2015, 09:09:21 am »
So when you open the default.workspace next time it contains just project A?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]