SDK refactoring for non UI builds

[killerbot]

jenkins is running in such a way that it does not have an X-server in its profile ==> non gui version required then

[MortenMacFly]

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... ???

[MortenMacFly]

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.

[killerbot]

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 ?

[oBFusCATed]

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.

[MortenMacFly]

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. :)