Author Topic: new wxWidget(wxSmith) project  (Read 22447 times)

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: new wxWidget(wxSmith) project
« Reply #15 on: June 23, 2007, 02:25:19 pm »
Hmm, I was just wondering - there's this _BORLANDC_ stuff inside wx_pch.h file:

I missed it. :)

So it should work correctly. And it really cleans the source. Maybe with one exception: the "// put here all your rarely-changing header files" content should be placed before _BORLANDC_ stuff to cache rarely-changing project headers too. The only problem with wxSmith is that this "wx_pch.h" is not included for newly created resources but I'll probably try to detect such file and add it automatically.

This is a good idea. Or you may keep an option to specify the header file name (similar to wx_pch.h) which wxSmith will use. That'd be an easy option to implement.

"// put here all your rarely-changing header files" has to be pulled up if we want to support PCH for BCC. ;)

But AFAIK, newer BCC (Turbo C++ Explorer 2006's compiler) supports PCH creation using a Header file. :) So that bad hack is necessary only for BCC 5.5.

Other supported GUI builder, wxFormBuilder generates it's own source which will have that pragma. So I would not clean up code for that. :)

But definitely the clean-up would be good for wxSmith and w/o any gui builder.

Regards,

Biplab
Be a part of the solution, not a part of the problem.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: new wxWidget(wxSmith) project
« Reply #16 on: June 23, 2007, 02:31:42 pm »
ok , so now we know why that __BORLANDc__ thing is needed.

Well, it's a decision then to support Borland with pch or not.

But keep the following in mind. Say the some other compilers (Digital Mars or whatever) also need special stuff for pch in the code, then we can end up with a list of such #ifdef do whatever is needed in here for that specifi compiler #endif structures, and that will make the code less easier to read.
My point of view on this is, first we should have standard compliant code, so it's as portable as can be. Pch is not part of the standard (I think), that's why I am stressing on the point to do includes correct, because then you at least have correct standard code.
CB code has decided to use the pch feature of GCC, and therefor you find things like :
Code
#include "the pch header"
#ifndef CB_PRECOMP
blablabla
#endif
more blablabla
where blablabla and more blablabl is header inclusion directives.

So, support BorlandC : yes or no. CB sources itself *only* support gcc, so in CB sources that Borland stuff is ready to go out of the door.

When you want to enable Borland pch, it is sufficient to do it in that pch header (sdk.h), and for pch support that header should be included first. And then the blablabla stuff.
I think wx pch header probably does similar thing, so also that points that it is not needed to do in our sources or wizard generated sources.

Oh, new post already before this one is ready, with interesting information :
Quote
But AFAIK, newer BCC (Turbo C++ Explorer 2006's compiler) supports PCH creation using a Header file. So that bad hack is necessary only for BCC 5.5.

Bye bye BCC5.5 ;-)

When a user is creating a bigger project starting from the wizards code, it can happen he wants to to pch stuff with his code, well that's the users choice, I feel that the code generated from our wizards should NOT take that into account. We can not, and should not, predict all possible uses or ideas a user might have in mind.

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: new wxWidget(wxSmith) project
« Reply #17 on: June 23, 2007, 02:45:11 pm »
So, support BorlandC : yes or no. CB sources itself *only* support gcc, so in CB sources that Borland stuff is ready to go out of the door.

As I wrote earlier, you can't compile C::B with BCC 5.5.1 as it fails to compile Squirrel. I have a partial makefile which I can give you in case you want to try.

Bye bye BCC5.5 ;-)

We may need to say bye bye to this little compiler. Turbo package is full of S**t. You've to install the whole IDE + .NET SDK 1.1 to get the compiler working for you. :x

Quote
When a user is creating a bigger project starting from the wizards code, it can happen he wants to to pch stuff with his code, well that's the users choice, I feel that the code generated from our wizards should NOT take that into account. We can not, and should not, predict all possible uses or ideas a user might have in mind.

It's the most probable case that the user will use his/her own header file. We're just providing a basic framework. Now it's the user who'd take the final decision. :)

Regards,

Biplab
Be a part of the solution, not a part of the problem.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: new wxWidget(wxSmith) project
« Reply #18 on: June 23, 2007, 03:04:05 pm »
Quote
Turbo package is full of S**t. You've to install the whole IDE + .NET SDK 1.1 to get the compiler working for you.

Darn right, I hope one day, they will provide just the compiler tools.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: new wxWidget(wxSmith) project
« Reply #19 on: June 23, 2007, 04:32:31 pm »
One thing also bothers me abotu this wx_pch.h file. There's code:

Code
#ifndef WX_PRECOMP
#include <wx/wx.h>
#endif

which I think is wrong because valid source using pch should look like this:

Code
#include "wx_pch.h"

#ifndef WX_PRECOMP
// Include headers that are inside pch, may be even #include <wx/wx.h>
#endif
// Include headers that are not inside pch

So actually the code I've pointed out from wx_pch.h should be put into sources (actually currently such non-pch source is in both wx_pch.h and source files). So the content of wx_pch.h proposed by me is:

Code
#ifndef WX_PCH_H_INCLUDED
#define WX_PCH_H_INCLUDED

// basic wxWidgets headers
#include <wx/wxprec.h>

#ifdef WX_PRECOMP
// put here all your rarely-changing header files
#endif // WX_PRECOMP

#ifdef __BORLANDC__
#pragma hdrstop
#endif

#endif // WX_PCH_H_INCLUDED

That may speed-up non-pch builds since in most cases not all <wx/wx.h> is included but only those headers that are really required. And from what I've seen, currently it's done by some trick like:

Code
#ifdef WX_PRECOMP
#include "wx_pch.h"
#endif

So the #ifdef..#endif guard is not needed at all since wx_pch.h won't do anything when pch-s are not enabled


BYO

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: new wxWidget(wxSmith) project
« Reply #20 on: June 23, 2007, 05:28:02 pm »
That would be a nice change. :)

I'll update the Non-wxSmith generated sources without <wx/wx.h> header. I believe that would make the PCH file smaller and the build be faster, too.
Be a part of the solution, not a part of the problem.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: new wxWidget(wxSmith) project
« Reply #21 on: June 23, 2007, 05:45:21 pm »
That would be a nice change. :)

I'll update the Non-wxSmith generated sources without <wx/wx.h> header. I believe that would make the PCH file smaller and the build be faster, too.

I've already updated the wxSmith-only files. So there's only this wx_pch.h left to update (it's shared so I don't know if you also wanted to update this one), I'll leave this to you since there may still be some problems with non-wxSmith projects after pch change.

And it looks like wx projects start having beter and cleaner shape and even though, the PCH compatibility is granted :) Of course they still can be better but even now I like the result :D

BYO

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: new wxWidget(wxSmith) project
« Reply #22 on: June 24, 2007, 10:19:31 am »
I think we have a little problem.

On linux there's no wx_pch.h, or I am not finding it.

I replace it by  :
Quote
#include "wx/wxprec.h"
and then it compiles again.
I didn't change anything in svn. What do you guys think ??

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: new wxWidget(wxSmith) project
« Reply #23 on: June 24, 2007, 10:35:34 am »
I think we have a little problem.

On linux there's no wx_pch.h, or I am not finding it.

I replace it by  :
Quote
#include "wx/wxprec.h"
and then it compiles again.

We need to check the wizard in Linux, too. :)

Including "wx/wxprec.h" would kill the benefits and cleanliness that you and Byo have proposed. But for a temporary fix, it can be used. :D
« Last Edit: June 24, 2007, 10:40:07 am by Biplab »
Be a part of the solution, not a part of the problem.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: new wxWidget(wxSmith) project
« Reply #24 on: June 24, 2007, 11:27:06 pm »
I think we have a little problem.

On linux there's no wx_pch.h, or I am not finding it.

I replace it by  :
Quote
#include "wx/wxprec.h"
and then it compiles again.

We need to check the wizard in Linux, too. :)

Including "wx/wxprec.h" would kill the benefits and cleanliness that you and Byo have proposed. But for a temporary fix, it can be used. :D

For unix-based wizard there's "wxWidgets Library Settings" with two options:
- Use default wxWidgets configuration
- Use Advanced Options

In the first mode all extra options (including pch) are disabled. But "Create Empty Project" and "Create and use precompiled header (PCH)" should also be enabled since it should be possible to create both empty and pch-enabled project even when default wx settings are used.

Including "wx/wxprec.h" is only a workaround and won't create real pch-s. That's because .gch file is not created (it's possible to create such file but it will require adding .gch file to system files which probably is not a best choice). So the pch option for unix is really required :)

BYO

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: new wxWidget(wxSmith) project
« Reply #25 on: June 25, 2007, 07:48:12 am »
are you saying linux builds have to use pch ?
Well my suse boxes are by default non pch, so for example even my linux CB builds are non pch.
I guess I could turn it on somewhere, but not for me, I'll stick to standard way ;-)

Now back to the real problem : linux : no wx_pch.h !!

But looking at the contents of wx/wxprec.h, I feel that's the header to include. If pch is turned on, it brings all those headers, if not pch it remains nearly empty no bringing any headers, so this behavior looks ok for me. Am I missing something ?
« Last Edit: June 25, 2007, 07:49:52 am by killerbot »

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: new wxWidget(wxSmith) project
« Reply #26 on: June 25, 2007, 08:06:44 am »
For unix-based wizard there's "wxWidgets Library Settings" with two options:
- Use default wxWidgets configuration
- Use Advanced Options

In the first mode all extra options (including pch) are disabled. But "Create Empty Project" and "Create and use precompiled header (PCH)" should also be enabled since it should be possible to create both empty and pch-enabled project even when default wx settings are used.

It's a nice catch. This is a drawback of the present wizard. Thanks for pointing it. :)

I'll update this today.

are you saying linux builds have to use pch ?

No No, Byo's not meaning that. What he's saying is that the option to select PCH is turned off by default. And if you don't want to use Advanced settings to enable pch, then you may need to do it in that way. :)
Be a part of the solution, not a part of the problem.