User forums > Embedded development
Question on cbSystemView - an SVD plugin
BlueHazzard:
The best way to build codeblocks for this purpose is to build it with codeblocks ;)
On my changes i update only the project files but not the make files, so if i have changed something in codeblocks it will probably break the make build system.
To build codeblocks, with codeblocks on linux open your codeblocks, and open the codeblocks_wx30_unix project file or workspace file.
You should be able to simply hit build and all should work.
Prior to starting the first time you have to run the "update30" script in the codeblocks source folder. This will copy all needed images and plugins ecc. This has only to be done one time.
If you want to run the new codeblocks outside codeblocks you have to run first the update30 script and then you can start codeblocks from the output30 folder with the run.sh script
--- Quote ---Struggling to get this working. Have built the required branch and plugin. I did need to comment out a line referencing cbEVT_DEBUGGER_CONTINUED, which makes me think the build isn't quite right, but I have set up the cb global to the correct directory on the special branch, so not sure where I have made a mistake.
--- End quote ---
are you building this branch: https://github.com/bluehazzard/codeblocks_sf/tree/debugger/pull_candidate/memory_range_watch/1 ?
If so build logs are needed to help you...
--- Quote ---Get loads of errors on C::B startup once pluging installed, mostly unable to insert items in to a task bar, then it all dies.
--- End quote ---
This is probably because you have not run the update script... Or you messed the wxWidgets library versions..
jimbo:
--- Quote from: BlueHazzard on September 27, 2018, 06:16:51 pm ---The best way to build codeblocks for this purpose is to build it with codeblocks ;)
On my changes i update only the project files but not the make files, so if i have changed something in codeblocks it will probably break the make build system.
To build codeblocks, with codeblocks on linux open your codeblocks, and open the codeblocks_wx30_unix project file or workspace file.
You should be able to simply hit build and all should work.
Prior to starting the first time you have to run the "update30" script in the codeblocks source folder. This will copy all needed images and plugins ecc. This has only to be done one time.
If you want to run the new codeblocks outside codeblocks you have to run first the update30 script and then you can start codeblocks from the output30 folder with the run.sh script
--- Quote ---Struggling to get this working. Have built the required branch and plugin. I did need to comment out a line referencing cbEVT_DEBUGGER_CONTINUED, which makes me think the build isn't quite right, but I have set up the cb global to the correct directory on the special branch, so not sure where I have made a mistake.
--- End quote ---
are you building this branch: https://github.com/bluehazzard/codeblocks_sf/tree/debugger/pull_candidate/memory_range_watch/1 ?
If so build logs are needed to help you...
--- Quote ---Get loads of errors on C::B startup once pluging installed, mostly unable to insert items in to a task bar, then it all dies.
--- End quote ---
This is probably because you have not run the update script... Or you messed the wxWidgets library versions..
--- End quote ---
Cool, thanks for the detailed info. Will give it a go now!
jimbo:
OK, finally got time to get back on this.
Been looking at the changes made to underlying CB code to implement this plugin, and just need a quick understanding of what is needed. AIUI, there are two sets of changes, one to provide memory watch ranges, and one that provides some sort of event/message from debugger to the plugin. I presume this second is so the plugin can be informed that something has changed and it therefor needs to update its display? However, also AIUI, this event system change is not going to be accepted, whilst the memory range stuff is likely to be?
From my POV, for an interim solution, a button on the plugin to refresh the GUI would be fine until whatever new 'event' system is in place, so would this be a feasible approach? It requires the memory range changes, which just need to be code reviewed, plus a minor change to the plugin to add abutton for refresh instead of having it happen automatically?
I'll have a go at pulling in the patches for the memory watch stuff, then play around with the plugin button stuff, to see if this does the job, but any comments in the meantime welcomed.
Edit: patches 0004 to 0010 applied OK, 0011 won't apply, so just sorting that out.
jimbo:
Keep getting seg faults with this plugin as it stands, running from a recent nightly.
Problem is that now Codeblocks segs faults on startup, and I need to know how to disable this plugin from running , so what does Codeblocks do when you install a plugin? Does it move it to a new location, and have some sort of database files to refenrece? Or similar? Where are these config files so I can manually edit and disble the plugin so I can get codeblocks to restart. Been googling and grepping tmy filesystem looking for stuff, but not found anything.
Note I am using a home build codeblocks, running it from src/src/.lib, which could well be part of the problem.
Running Lubuntu.
oBFusCATed:
Find the .so file for the plugin and remove it. This is the most straight forward way. Probably try if running in safe mode work. --help for the exact flag.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version