Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: oBFusCATed on September 02, 2012, 02:32:59 pm
-
BTW: Is there any reason for this code to be part of the sdk and not part of the application in src?
For me this (having gui code in the sdk) is one serious problem, which we have to fix in the future.
So if these two files can be move in src/src I'll be happy:)
-
BTW: Is there any reason for this code to be part of the sdk and not part of the application in src?
For me this (having gui code in the sdk) is one serious problem, which we have to fix in the future.
So if these two files can be move in src/src I'll be happy:)
Right now, those dialogs get used by code snippets, but I suspect it would be better for CodeSnippets to have their own. I think it will be difficult to remove all of the dialogs from the SDK because some should be accessible to plugins. Find/replace might be a good candidate though.
Still not loving the find/replace dialog after my latest changes. The multi line option creates a bit of a mess. Not sure why it is necessary because you can do virtually the same in a more robust way in a single line of regexp. I will play with the layout some more...
Furthermore, the modeless operation of thread search and incremental search plugins seem to be a better model. I think this is the way to go. I will experiment with porting all the good bits of those plugins across.
-
I think it will be difficult to remove all of the dialogs from the SDK because some should be accessible to plugins.
Examples?
-
Examples?
Well you never know - that's why the dialogs are part of the SDK, isn't it? Plugins might use it and I could think of use-cases for many dialogs. For example: a language (like Fortran) specific find dialog. For such it would be nice if you could simple derive from the existing class and change what's needed. I wonder what's so bad about it.
-
...reminds me on something else I noticed with the ThreadSearch dialog: I regularly become warnings that ThreadSearch tries to find in binary files, like icons. This is rather annoying and makes me use the "normal" find dialog more often.
-
For such it would be nice if you could simple derive from the existing class and change what's needed.
For a class to be derivable, it should be designed with this in mind and I doubt this is the case for most of them.
I wonder what's so bad about it.
Because we can't have a console-only executable on linux, which can be used for building cb projects.
...reminds me on something else I noticed with the ThreadSearch dialog: I regularly become warnings that ThreadSearch tries to find in binary files, like icons. This is rather annoying and makes me use the "normal" find dialog more often.
Fix your file mask and you won't get such problems.
-
Because we can't have a console-only executable on linux, which can be used for building cb projects.
I think a more clever way would be to re-factor the build system and compiler plugin so it offers a way to be bundled into a console version. You don't need any UI/other plugin if you want to compile from console.
Fix your file mask and you won't get such problems.
My file mask is: "*.cpp;*.c;*.h". Something else is wrong - it might be related that I search the whole workspace. It seem to happen only then.
Edit: Concerning: "You don't need any UI/other plugin if you want to compile from console" - maybe you do: the EnvVars plugin.
-
I think a more clever way would be to re-factor the build system and compiler plugin
BTW: What I did in one of my own applications that is similar:
- all classes accessing files are based on non-GUI components (and are also part of a SDK)
- for the UI version of the software I have a gateway class that "connects" low-level stuff to high-level UI events/commands.
- for the non-UI version I use this specific part of the SDK decoupled and wrapped with a command line interface around it.
In a similar fashion the build system could be designed.
Also, for these things I wonder why people don't simply use i.e. the Makefile generator available for Code::Blocks. OK - it won't be scriptable and alike, but would you need it for such special cases?
-
Also, for these things I wonder why people don't simply use i.e. the Makefile generator available for Code::Blocks. OK - it won't be scriptable and alike, but would you need it for such special cases?
Because we advertise it as working, try codeblocks --help :)
-
Because we can't have a console-only executable on linux, which can be used for building cb projects.
I think a more clever way would be to re-factor the build system and compiler plugin so it offers a way to be bundled into a console version. You don't need any UI/other plugin if you want to compile from console.
Fix your file mask and you won't get such problems.
My file mask is: "*.cpp;*.c;*.h". Something else is wrong - it might be related that I search the whole workspace. It seem to happen only then.
As far as I know, the filemask is not used in this case, all project/workspace files are used.
The filemask is only used when searching in a given directory.
EDIT:
That's why the possibility to ignore some errors was added in the config-dialog, we might add one to ignore e.g. binary file-errors.
This should be easy to implement. I can do this.
Edit: Concerning: "You don't need any UI/other plugin if you want to compile from console" - maybe you do: the EnvVars plugin.
In this case a user should either use cb_share_config to export the envvars or set the needed vars in a shell-script and run C::B from inside it.
-
Also, for these things I wonder why people don't simply use i.e. the Makefile generator available for Code::Blocks. OK - it won't be scriptable and alike, but would you need it for such special cases?
Because we advertise it as working, try codeblocks --help :)
using CB from within CI is great and powerfull, no need for makefiles, the console branch for that matter, and when the next step is there that it can also run plugins, then you could have a target that runs a valgrind sessions, a cppcheck, a doxygen, and so on ...
-
Because we advertise it as working, try codeblocks --help :)
Yes, but we don't advertise its working w/o UI. And batch build is working just great - I do it nearly every day. Its really fast and has a lot advantages in contrast to Makefiles. What I meant is if you really need a build w/o UI you could do it with the Makefile generator. Jens did a trial in the console branch - this could be a starter for what I had in mind (or maybe a solution already).
I know it would be nice to have the build system decoupled - but I think the effort of re-factoring the whole SDK - especially removing all UI parts to achieve this - is just too much if there are other way easier possibilities. Just my 2 cents...
-
Yes, but we don't advertise its working w/o UI. And batch build is working just great - I do it nearly every day. Its really fast and has a lot advantages in contrast to Makefiles. What I meant is if you really need a build w/o UI you could do it with the Makefile generator. Jens did a trial in the console branch - this could be a starter for what I had in mind (or maybe a solution already).
Yes, but you're a windows user and the ui is built-in. On linux you can have pure systems without ui, there it is not working.
I know it would be nice to have the build system decoupled - but I think the effort of re-factoring the whole SDK - especially removing all UI parts to achieve this - is just too much if there are other way easier possibilities. Just my 2 cents...
We will see in the future. Anyway having less gui in the SDK will always be good.
-
Yes, but you're a windows user and the ui is built-in. On linux you can have pure systems without ui, there it is not working.
I know, but the batch build feature was never intended to be used without UI, just for batching C::B in a UI capable environment.
However - I indeed have a question: I don't use Linux regularly as you know - so what is the use-case actually that you need to compile projects on a OS without UI? From my limited point of view it only makes sense to compile console projects under such OS'es as everything else won't work. And this works just fine with a Makefile export. Why would you want to compile more complex projects (i.e. UI capable ones) on such OS'es where you cannot test what you've compiled and need a UI capable OS then anyways? ??? This isn't clear to me.
-
It's very useful for build-robots for example.
-
jenkins is running in such a way that it does not have an X-server in its profile ==> non gui version required then
-
jenkins is running in such a way that it does not have an X-server in its profile ==> non gui version required then
OK - but Jenkins (and probably others, too) seems to be available for UI platforms, too (including Windows):
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins#InstallingJenkins-WindowsInstallation
So why make it extra-hard? For me it still looks one is creating a problem here where actually there isn't... ???
-
So why make it extra-hard? For me it still looks one is creating a problem here where actually there isn't... ???
To make myself more clear: Do we really want to do such major re-factoring just to support those 5-10 guys in the world that insist to use C::B with a non-UI OS? Or are these so many that it becomes relevant to us?
Jens' approach with minimal (?) effort using #defines seems enough for me.
-
I am not taking the "how it is done" into account at this time.
Having CB as a build system is extremely good, since it can easily cope with different compilers, so when doing multi platform code (win/linux/embedded ports), CB is so much easier.
I have a project for my library, and per "platform" 2 targets (debug versus release build). And building the CB project ==> all is build. When keeping this in makefiles (and let's assume the generated ones, so I don't have to manage dependencies/includes twice) it becomes more complicated and more possibilities for errors.
On the other hand, the cbp makefile gen plug-in :
- is great
- is not part of contrib (we should add it)
- should be run automatically
Meaning you need to run CB in headless mode in order to have it run the makefile gen plug-in. :-(
And the use cases I already mentioned above, having a dedicated target that is the invocation of :
- doxygen
- valgrind
- cppcheck
- cccc
- ...
will be another super feature (@Jens : when do you think you will have the cppcheck invocation ready ;-) )
So on the feature level, I think this is a really powerful feature.
On the how, the best would be that core code is completely separated from the user interface code (a good design strategy anyway [maintenance, testability, ..)) , but ifdef can be a first step.
What do you think ?
-
To make myself more clear: Do we really want to do such major re-factoring just to support those 5-10 guys in the world that insist to use C::B with a non-UI OS? Or are these so many that it becomes relevant to us?
I want to do it, because this is how I feel it should be done and because I feel this will make the SDK better.
Solving the non-ui issue will be a bonus. We will see if I have the time and motivation to do it :)
Jens' approach with minimal (?) effort using #defines seems enough for me.
Probably his approach is just a hard to maintain hack, I've not looked at it, putting defines all over the place will always be harder to maintain, then writing the code in a better way.
p.s. can you extract these last post in another topic, as they are pretty much off topic here.
-
I want to do it, because this is how I feel it should be done and because I feel this will make the SDK better.
Solving the non-ui issue will be a bonus. We will see if I have the time and motivation to do it :)
OK with me, as long as you don't break C::B completely. ;-)
p.s. can you extract these last post in another topic, as they are pretty much off topic here.
Done.
BTW: In case you wonder why all messages are edited: It seems our forum software cannot change the topic's name if you split by selected messages. (In contrast to when you split "from, including all following" - there it works. ::))