Author Topic: SVN 2835: Missing subdirectory "resources" under "src/plugins/contrib/cb_koders"  (Read 15063 times)

vesselin_peev

  • Guest
Under GNU/Linux, the missing directory causes bootstrapping to fail and the configure script not to be created (not tested under Windows). By creating the subdirectory manually, the problem goes away. There may be also other problems caused by the inexistence of the directory.
« Last Edit: August 11, 2006, 02:38:26 pm by vesselin_peev »

vesselin_peev

  • Guest
It turns out that there should probably be a makefile and some files in this "resources" subdirectory, because making of the entire CodeBlocks fails with:

make[5]: Entering directory `/home/test/codeblocks_build/trunk/src/plugins/contrib/cb_koders/resources'
make[5]: *** No rule to make target `all'.  Stop.

vesselin_peev

  • Guest
This problem is still present in 2836. Can someone at least confirm it?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
You should be patient my friend. It's only ~4 hours since your first post. You know, we 're not all day in front of our computer screen ;).
Plus, you 're talking about HEAD. Its state is not guaranteed to work at all times. It usually is fine but there are cases (like this) where it might not be in a "buildable" state. In such cases, show some patience...
Be patient!
This bug will be fixed soon...

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
You should be patient my friend. It's only ~4 hours since your first post. You know, we 're not all day in front of our computer screen ;).
Right - I or myself have a family to take care of from time to time... ;-)
Anyway - I'm working on it by now, give me some more minutes...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

vesselin_peev

  • Guest
Dear Mandrav and MortenMacFly:

I'm sorry that I wrote my second post so it could be interpreted as impatient. I should have written it otherwise. I am completely aware of the possible brittleness of the HEAD branch, and didn't want to come off as impatient at all -- in all honesty! I can assure you that the only thing that made me write the second post was not my expectation that the core project developers should fix any problem at my command, but rather that because this is a forum with significant and constant visitorship, some kind regular user would confirm the problem AND that *perhaps*, only *perhaps*, the problem would get fixed. I was even thinking I'm making you a favour because when problems are reported and acknowledged early, they are usually easily fixed. I am sorry for the misunderstanding caused -- again I say I should have stated things otherwise.
« Last Edit: August 11, 2006, 07:42:09 pm by vesselin_peev »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
No worries mate :)
Be patient!
This bug will be fixed soon...

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
No worries mate :)
Right! As long as you see a ;-) instead of :? or even :evil: everything is :D. (:lol: :mrgreen:)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

vesselin_peev

  • Guest
Yes, I saw the ;) but I still had to apologise and straighten out the misunderstanding I've caused.

CodeBlocks is open source -- no one can demand that you fix problems and improve things, unless not fixing and improving is dangerous to others -- but I don't think the IDE has the potential to be dangerous in this shape and form, except to some "honest" software companies producing IDEs as well :).
« Last Edit: August 11, 2006, 08:40:39 pm by vesselin_peev »

vesselin_peev

  • Guest
I see you've fixed the problem. There was still a problem that kodersdialog.cpp wouldn't compile. I found that the line
Code
#include "sdk.h"
should be added at the top (that's the best header to include so precompiled headers work correctly, I think). Please review and commit.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
I found that the line
Code
#include "sdk.h"
should be added at the top [...]
Thanks for this information. Anway: Adding sdk.h at this point is not a good solution. The kodersdialog has nothing to do with the C::B SDK. I know why this works (the sdk.h file simply includes a bunch of wxWidgets headers) but again: This is not a good solution. I can find out why on monday (then I have access to a linux machine again) so it will have to wait for now (it and compiles nicely on windows so far...).
With best regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5493
The fact we put the include sdk.h there, is to support precompiled headers.
You could also directly use the wx precompiled header for this. Note that the sdk.h has a bigger list then the native wx one. :evil:

As it is again now, sureley the including of wx/string.h is missing !!
It might come in through the including of wx/wxprec.h in the kodersdialog.h

As for as I have been told, you should NOT include thoe precomiled driven headers in a header file

So
1) the including of wx/wxprec.h needs to be removed from the header
  I don't know it that was generated by wxSmith or not, if it is we should talk to byo. He's already aware of the not needed header includings generated in the dialog header, and told m that would be fixed in the new wxSmith. Therefor I would suggest @Morton, you put back back the forward declarations and the includes in the cpp file (see point 3), so that when the switch no new wxSmith will be made, that the code is already ok, and we just need to move the wxSmith block (from .h to .cpp)
2) wx/string.h include should be added (I will do that again)
3) Choose if you want to work with precompiled headers or not :
if not then it should be like this :
Code
#include <wx/button.h>
#include <wx/choice.h>
#include <wx/intl.h>
#include <wx/settings.h>
#include <wx/sizer.h>
#include <wx/stattext.h>
#include <wx/string.h>
#include <wx/textctrl.h>

#include "kodersdialog.h"
if yes, then it should be like this :
Code
#include "sdk.h"
#ifndef CB_PRECOMP
#include <wx/button.h>
#include <wx/choice.h>
#include <wx/intl.h>
#include <wx/settings.h>
#include <wx/sizer.h>
#include <wx/stattext.h>
#include <wx/string.h>
#include <wx/textctrl.h>
#endif

#include "kodersdialog.h"

Note that the result of including a precompiled header in the case when no precompiled directive is given to the project(compiler) is(should be) a no-op. So you include just nothing. So in this case, who will bring in wx/string.h. We might be lucky someone else included it, but that's no guarantee.

@Morton,
I will add the include wx/string.h . I leave the rest up to you, it's your call to either support or not support precompiled headers.

PS : will finish up my header including topic this weekend ;-)
« Last Edit: August 12, 2006, 10:50:28 am by killerbot »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5493
I see you've fixed the problem. There was still a problem that kodersdialog.cpp wouldn't compile. I found that the line
Code
#include "sdk.h"
should be added at the top (that's the best header to include so precompiled headers work correctly, I think). Please review and commit.

could you try again with the latest revision, and tell me what the compiler gives as error output ?

vesselin_peev

  • Guest
Here it is (SVN 2839):

Quote
In file included from kodersdialog.cpp:3:
kodersdialog.h:20: error: expected class-name before '{' token
kodersdialog.h:23: error: expected `)' before '*' token
kodersdialog.h:45: error: `wxCommandEvent' has not been declared
kodersdialog.h:45: error: ISO C++ forbids declaration of `event' with no type
kodersdialog.h:49: error: ISO C++ forbids declaration of `wxBoxSizer' with no type
kodersdialog.h:49: error: expected `;' before '*' token
kodersdialog.h:50: error: ISO C++ forbids declaration of `wxBoxSizer' with no type
kodersdialog.h:50: error: expected `;' before '*' token
kodersdialog.h:51: error: ISO C++ forbids declaration of `wxStaticText' with notype
kodersdialog.h:51: error: expected `;' before '*' token
kodersdialog.h:52: error: ISO C++ forbids declaration of `wxBoxSizer' with no type
kodersdialog.h:52: error: expected `;' before '*' token
kodersdialog.h:53: error: ISO C++ forbids declaration of `wxTextCtrl' with no type
kodersdialog.h:53: error: expected `;' before '*' token
kodersdialog.h:54: error: ISO C++ forbids declaration of `wxButton' with no type
kodersdialog.h:54: error: expected `;' before '*' token
kodersdialog.h:55: error: ISO C++ forbids declaration of `wxBoxSizer' with no type
kodersdialog.h:55: error: expected `;' before '*' token
kodersdialog.h:56: error: ISO C++ forbids declaration of `wxStaticText' with notype
kodersdialog.h:56: error: expected `;' before '*' token
kodersdialog.h:57: error: ISO C++ forbids declaration of `wxChoice' with no type
kodersdialog.h:57: error: expected `;' before '*' token
kodersdialog.h:58: error: ISO C++ forbids declaration of `wxChoice' with no type
kodersdialog.h:58: error: expected `;' before '*' token
kodersdialog.h:64: error: ISO C++ forbids declaration of `DECLARE_EVENT_TABLE' with no type
kodersdialog.h:64: error: expected `;' before '}' token
kodersdialog.h:64: error: expected `;' before '}' token
kodersdialog.cpp:5: error: `wxDialog' has not been declared
kodersdialog.cpp:7: error: expected constructor, destructor, or type conversionbefore "EVT_BUTTON"
kodersdialog.cpp:7: error: expected `,' or `;' before "EVT_BUTTON"
kodersdialog.cpp: In member function `wxString KodersDialog::GetSearch() const':
kodersdialog.cpp:107: error: `_' undeclared (first use this function)
kodersdialog.cpp:107: error: (Each undeclared identifier is reported only once for each function it appears in.)
kodersdialog.cpp:109: error: `txtSearch' undeclared (first use this function)
kodersdialog.cpp: In member function `wxString KodersDialog::GetLanguage() const':
kodersdialog.cpp:117: error: `_' undeclared (first use this function)
kodersdialog.cpp:119: error: `choLanguages' undeclared (first use this function)
kodersdialog.cpp: In member function `wxString KodersDialog::GetLicense() const':
kodersdialog.cpp:127: error: `_' undeclared (first use this function)
kodersdialog.cpp:129: error: `choLicenses' undeclared (first use this function)
kodersdialog.cpp: At global scope:
kodersdialog.cpp:135: error: variable or field `OnBtnSearchClick' declared void
kodersdialog.cpp:135: error: `int KodersDialog::OnBtnSearchClick' is not a static member of `class KodersDialog'
kodersdialog.cpp:135: error: `wxCommandEvent' was not declared in this scope
kodersdialog.cpp:135: error: `event' was not declared in this scope
kodersdialog.cpp:136: error: expected `,' or `;' before '{' token
make[4]: *** [kodersdialog.lo] Error 1

It's clear that the #include <wx/wxprec.h> does not bring in any of the headers including the wxBoxSizer, wxStaticText, etc, because WX_PRECOMP is not defined when compiling kodersdialog.cpp. Rather than putting the define in the makefile (you will want to do that certainly, if you want to use wxWidgets' own precompilation logic), for the test only I put #define WX_PRECOMP before the former line, and indeed, things build fine then.

I think that if you want the best flexibility things should be made to work fine in the 3 scenarios: when WX_PRECOMP and CB_PRECOMP is defined, when only one of them is defined, and when neither is defined. This is the ideal aim, right?

Also, may I ask what is the reason you support no precompilation and hassle with it? Codeblocks isn't to be build with an old compiler of the 3.x series (and probably cannot be?)? Borland, Microsoft and modern GCC compilers all support precompilation. Or is it because of better debuggability of the build process?

As Killerbot says and from what I know and how I use precompiler headers in my own projects, indeed only C/C++ source files should include headers driving precompilation (at the top), not regular header files.
« Last Edit: August 12, 2006, 03:08:09 pm by vesselin_peev »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5493
could you try again, the ifndef CB_PRECOMP should not be around the include section in the header of kodersdialog.h (in the case like it is now and we put those includes in the header) -> rev 2840

We do offer pch, but this new plug-in does not (correctly) at the moment (as described above).
With and without pch is offered, even if your compiler offers pch, it's nice to be able not to use it. yeah yeah, i am not a pch fan ;-)