Author Topic: Scripted wizards  (Read 11418 times)

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Scripted wizards
« Reply #15 on: October 10, 2006, 02:23:33 pm »
Make sure you post any bugs you find, as the usage of both systems (concurrently) hasn't been tested ;)
Will do so. :)

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #16 on: October 10, 2006, 03:20:30 pm »
i'm really amazed about the fact, that nobody is arguing pro the CB versatile Project & Target build system.

in my opinion it is one of the killer-arguments, why to use CB.
Project & Target setup is so easy and at the same time so powerful compared to all other free- / open-source IDE's.

instead of pushing and explaining this powerful tool to new users,
there are only ideas to "hide" it behind a Debug and a Release Target in every project ?

i'm reallly amazed about  :P

sethjackson

  • Guest
Re: Scripted wizards
« Reply #17 on: October 13, 2006, 07:32:49 pm »
Well I like the wizards, BUT I don't like the Debug, Release target in every project. I generally just tell C::B to create one release target (which I rename to default). Then I have to go turn off the optimization switches and stuff....

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: Scripted wizards
« Reply #18 on: October 13, 2006, 07:38:57 pm »
Well I like the wizards, BUT I don't like the Debug, Release target [...]
What I personally don't get from this discussion: The Debug/Release target page is only a template. You can have any page there and you can setup a project with a scripted wizard as you like. You are not limited by the scripted wizard to release/target, only if you use a wizard that is limited to this kind of targets. Seth: You should know that...?!
My suggestion is instead of again and again discussing this topic why not trying to implement what is required for the individual?
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #19 on: October 13, 2006, 08:02:04 pm »
Well I like the wizards, BUT I don't like the Debug, Release target [...]
What I personally don't get from this discussion: The Debug/Release target page is only a template. You can have any page there and you can setup a project with a scripted wizard as you like. You are not limited by the scripted wizard to release/target, only if you use a wizard that is limited to this kind of targets. Seth: You should know that...?!
My suggestion is instead of again and again discussing this topic why not trying to implement what is required for the individual?
With regards, Morten.

basically you are right,

but when there are default wizzards supplied by every CB installation,
it should be allowed to discuss about, if the actual implementation is useful or not.
if everybody, who doesn't like a specific issue, changes it for his own installation it is of course ok,
but i would like to discuss how the "official" CB wizzards should be designed.

since it is a question of philosophy, it can't hurt if we get a few opinions, isn't it ?

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Scripted wizards
« Reply #20 on: October 13, 2006, 08:36:08 pm »
but i would like to discuss how the "official" CB wizzards should be designed.

since it is a question of philosophy, it can't hurt if we get a few opinions, isn't it ?

Yep, it's the same I intended to say above:
Besides, no-one is stopping you to create a wizard with just one page, effectively simulating the dialog you 're suggesting ;).
Of course nothing stops no-one, but we have to discuss things first, right? If not, one could do a wizard in one way and another person in other way. And consistency would be lost.

This means, we know we can modify everything, since this is opensource, but we're talking about making better defaults for everyone.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: Scripted wizards
« Reply #21 on: October 13, 2006, 08:49:09 pm »
since it is a question of philosophy, it can't hurt if we get a few opinions, isn't it ?
I didn't mean to offend here - I really wasn't sure if anybody is aware of the fact that indeed this is not a limitation of the scripted wizard plugin, but only the wizards itself as they are now. I surely didn't mean to suppress a discussion here (of course not) - but this will be endless if we don't come up with a sample implementation. And we had that discussion already...
So really: I only meant to clarify the facts and that's it. I fully respect and support a discussion of how things could be done better.
With regards, Morten.

Edit: And to add another opinion: For me at work (where round about 10 people using C::B) the Release/Debug philosophy has paid off as it is what we use most. In *my* humble option this is a good default. But I'm not pushing anything here.
« Last Edit: October 13, 2006, 08:52:32 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #22 on: October 13, 2006, 09:33:12 pm »
I didn't mean to offend here - I really wasn't sure if anybody is aware of the fact that indeed this is not a limitation of the scripted wizard plugin ...

surprisingly we now about that fact already

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #23 on: October 13, 2006, 09:38:34 pm »
...For me at work (where round about 10 people using C::B) the Release/Debug philosophy has paid off as it is what we use most. In *my* humble option this is a good default.

and how do you organize a simple project which consists e.g. of
1 - wxScintilla
2 - your custom dll with all your old goodies
3 - your wx app

with the Release/Debug approach ?

do you use different projects for for 1,2,3 and a workspace to hold them ?
do you have 3 times more effort to set all needed settings than if you would use one project with targets 1,2,3
which is easily expandable too ?


Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: Scripted wizards
« Reply #24 on: October 13, 2006, 11:34:43 pm »
and how do you organize a simple project which consists e.g. of
1 - wxScintilla
2 - your custom dll with all your old goodies
3 - your wx app
In fact I have such a project. I organise these 3 points as projects. Each of these projects has a release and debug target and a virtual "all" that includes both. Maybe I don't get what you try to explain...?! :shock:
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5177
Re: Scripted wizards
« Reply #25 on: October 14, 2006, 12:59:22 am »
just a shorty :

To be honest, one needs debug and release builds, for the simple reason that the final product should be a release build (== optimized), but then you can't debug, so you also need a debug build. Maybe think of it as debug/release configuration. So templates that setup these kind of configurations are good. And I am not just talking pc application, this also applies for embedded application, there (even more) you want optimized builds.

I think the example raised somewhere above of a project file with 3 targets:
 - component
 - test code
 - the app,
is not so nice in terms of I reusage of projects. I want people to reuse my component, and together with the source I provide them with a project file to build it (so they don't need to worry about defines, and other settings), but in that distribution my testcode and my app should be out. Well my component could be used in many apps (again think for example tinyxml) so why would "my"app by "the" app, far from it. From that point o view I provide debug build(configuration) (for people who like to debug it, in case they think there might be a problem on the inside), and the normal (preferred) usage would be the release configuration. And for dependent projects you can have a chain of debug's and a chain of release's. It's a nice "near"-standard. otherwise chaining for dependency will be less straight forward.

I don't say the other approach is not good, it is, otherwise we wouldn't have this exchange of ideas, but I feel it's not the best default. For sure in the pc world and definetely in the embedded world, debug/release configurations is what you need. Development and later on bugfixing requires the debug configuration, and the performance of the product requires the optimized (release) build (for example on a ti dsp, it's in speed 2 to 3 times faster in optimized build compared to debug build).

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #26 on: October 14, 2006, 08:46:38 am »
@killerbot
i second every word regarding the need for Debug- and Release- (and even other test-) builds.

but for the last time i want to say, that it is much less effort, if you organize them as projects
(Debug-Project, Release-Ansi-Project, Release-Optimized-Speed-Project, ...) instead as targets in each project.

building of the whole app is much more easy, and Creation of a new Build can simply be done by
copying the project file to  a new name and edit the project-wide settings
(with the Debug/Release/...-Targets approach you have to edit every single projectfile)

edit:
brgds, tiwag
« Last Edit: October 16, 2006, 08:16:17 am by tiwag »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5177
Re: Scripted wizards
« Reply #27 on: October 14, 2006, 10:54:10 am »
Quote
but for the last time i want to say, that it is much less effort, if you organize them as projects
(Debug-Project, Release-Ansi-Project, Release-Optimized-Speed-Project, ...) instead as targets in each project.

little drawback : add a new file to the project --> modifying 3 projects, otherwise 1, and disritbuting severl project files instead of 1

Main thing : CB allows both, so we can have wizards for both kind of flavours, we just need to well document them, simple huh ... ;-)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Scripted wizards
« Reply #28 on: October 14, 2006, 12:20:37 pm »
I think tiwag is right in most of what he said, even though I am of course aware that it is in vain anyway.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: Scripted wizards
« Reply #29 on: October 14, 2006, 02:08:05 pm »
I'd like to give an example where this does not apply:
At work we have several cross-platform applications (processes) that communicate with each other (via IPC) on different hardware platforms.
Thus all of these applications have it's own project, some of them share source files. Now each of these projects has several targets: Release and Debug; for Windows/Linux/QNX and another two for hardware-in-the-loop and software-in-the-loop simulations. This makes sense because the targets differ in the compiler (all compilers work on Windows but produce platform code), in the type of library to link against (platform, release, debug...) and in the defines applied for compilation.
As we have 2 major target platforms that have different hardware (one has less than the other), Thus we have 2 workspaces that include the projects (applications) for this specific platform. Virtual targets control the overall build process - thus, is it debug/release, do we want to build all applications in the workspace for one platform only (e.g. QNX) etc.
Now maybe I fail to understand but I believe that this is a good concept of project management for *our* case - at least it has proven to work very well. Maybe someone can tell me how to do this project- and not target-wise...?!

In the end: I think it is *very* good, that C::B supports both philisophies as I see that both have their pros and cons depending on what you are developing. For me the release/debug starting point is very good, because then I can just copy a target and adjust the parameters (defines, libs) for another platform but still have only one project per application running on all targets.

I have started to work on a concept for a "target wizard" though but I'd like to ask another question: Are you aware that currently it is possible to create an empty project using a wizard and then add only targets (that can be fully specified) to this project using another wizard? Would it be helpful to have a wizard that combines both to a single wizard?

Ps.: tiwag: In the end I don't like if someone calls others an i****t. I really try to think before I decide on how to setup projects and again: This setup have proven to work very well. We shouldn't come to a level here were we shout at each other.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ