New Mac OS X (PPC/10.3) build

[afb]

I uploaded codeblocks-rev2886_macppc.zip to BerliOS,
it's built in the same manner as the previous binaries.

wxWidgets 2.6.3 (ANSI), Mac OS X 10.3, gcc 3.3 Apple
I disabled the code completion plugin (it didn't compile)

[killerbot]

I disabled the code completion plugin (it didn't compile)

what's exactly the problem/error ??

[afb]

what's exactly the problem/error ??

I got this on both Linux and Mac:

nativeparser.cpp: In member function `size_t 
   NativeParser::FindAIMatches(Parser*, std::queue<ParserComponent, 
   std::deque<ParserComponent, std::allocator<ParserComponent> > >, 
   TokenIdxSet&, int, bool, bool, bool, short int, TokenIdxSet*)':
nativeparser.cpp:1379: error: no match for `std::_Rb_tree_iterator<int, const 
   int&, const int*>& == int' operator
nativeparser.cpp:1381: error: no match for `std::_Rb_tree_iterator<int, const 
   int&, const int*>& != int' operator
nativeparser.cpp:1394: error: no match for `std::_Rb_tree_iterator<int, const 
   int&, const int*>& == int' operator

[afb]

If it helps anyone, I did not get that nativeparser.cpp error with GCC 4.0.1 (Apple)

[JThedering]

I also got this problem with GCC 4.1.1 on Linux.
I just (hopefully) fixed it in this way:
Index: nativeparser.cpp
===================================================================
--- nativeparser.cpp    (Revision 2892)
+++ nativeparser.cpp    (Arbeitskopie)
@@ -1376,9 +1376,9 @@
             TokenIdxSet::iterator itsearch;
             if (search_scope)
                 itsearch = search_scope->begin();
-            while (itsearch == 0 || itsearch != search_scope->end())
+            while (itsearch == (TokenIdxSet::iterator)0 || itsearch != search_scope->end())
             {
-                Token* parent = tree->at(itsearch != 0 ? *itsearch : parentTokenIdx);
+                Token* parent = tree->at(itsearch != (TokenIdxSet::iterator)0 ? *itsearch : parentTokenIdx);
#ifdef DEBUG_CC_AI
                 Manager::Get()->GetMessageManager()->DebugLog(_T(" : looking under '%s'"), parent ? parent->m_Name.c_str() : _T("Global namespace"));
#endif
@@ -1391,7 +1391,7 @@
                         break;
                     parent = tree->at(parent->m_ParentIndex);
                 } while (true);
-                if (itsearch == 0)
+                if (itsearch == (TokenIdxSet::iterator)0)
                     break;
                 ++itsearch;
             }

Seems that you can't use an iterator as if it was a pointer.

[afb]

I fixed it in a more roundabout way... Used the boolean that initialized it instead

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1391&group_id=5358

[afb]

I am uploading a new Mac build to berlios, revision 2890. (codeblocks-rev2890_macppc.zip)

This one fixes the "New" menu problems the 2886 had (due to wrong xrc resources),
and it enlarges the default font size from 8 points up to a more readable 10 points.

Known bugs:

• The infowindows appear under the Dock, if you have it at the bottom (default)
• The initial window appears under the menu, minimize and restore to "fix" this

[afb]

Here are the patches that were needed:

• infowindow - http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1376&group_id=5358
  
• nativeparser - http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1391&group_id=5358
• fontsize - http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1394&group_id=5358
  
• plugins libs - http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1395&group_id=5358
  

[afb]

There's a new build now: CB_20060914_rev2976_macppc.zip

This one includes all the "contrib" plugins as well as the usual.
It also has icons for the file types (.c/.h/.cpp/.d etc), as 48x48.
A Universal Binary build will follow it later, named as "macx86".

Here are the patches that were needed:
* plugins libs - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358
* contrib mac - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1424&group_id=5358
* pkg-config - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1474&group_id=5358
* 48x48 icons - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1487&group_id=5358

See http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_nightly_build_on_Mac_OS_X

[Pecan]

There's a new build now: CB_20060914_rev2976_macppc.zip

This one includes all the "contrib" plugins as well as the usual.
It also has icons for the file types (.c/.h/.cpp/.d etc), as 48x48.
A Universal Binary build will follow it later, named as "macx86".

Here are the patches that were needed:
* plugins libs - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358
* contrib mac - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1424&group_id=5358
* pkg-config - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1474&group_id=5358
* 48x48 icons - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1487&group_id=5358

See http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_nightly_build_on_Mac_OS_X

Thanks for the builds.

Could you also share with us the bugs you're getting in the contribs.
You've submitted fixes to berlios for which you have submitted no bug reports or discussion. I don't seem to need these patches to either compile or run the contribs on my mac ppc.

It's possible I've already fixed them and didn't submit a fix, or the fix just got too out of date. For awhile there, I quite submitting fixes for the latter reason.

For this particular contrib fix, however, I can do something about it if you'd indicate the reasons for your fix.

[afb]

* contrib mac - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1424&group_id=5358

You've submitted fixes to berlios for which you have submitted no bug reports or discussion. I don't seem to need these patches to either compile or run the contribs on my mac ppc.

It's possible I've already fixed them and didn't submit a fix, or the fix just got too out of date. For awhile there, I quite submitting fixes for the latter reason.

For this particular contrib fix, however, I can do something about it if you'd indicate the reasons for your fix.

I had two incidents in the contribs where it wouldn't link since it was missing symbols that seemed to only be defined in the #ifdef __WXMSW__ or #ifdef __WXGTK__ blocks, so I added stubs/dummy functions to make it link correctly when compiling for __WXMAC__ ?

I'm pretty used to this "if (Windows) else (Linux)" logic by now, so I normally do it without reflecting too much on why it is needed... :-P If it isn't needed anymore, just ignore this patch but at the time it was submitted it wouldn't link with --enable-contrib without it.

[afb]

plugins libs - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

The reason to add the WX_LIBS to the plugins was so that it would ./configure && make without giving any extra LDFLAGS, but I think this was described in detail in the comments to the patch ?

[afb]

I should also mention that the CodeCompletion plugin makes it hang indefinitely when creating or opening a project, so this was probably a mistake to include in the default installation...

There seems to be another crash when trying to save the settings, so the easiest is probably to just delete the plugin .so itself from the application bundle ("plugins/libcodecompletion.so")

Will try to report all these as bugs, if they aren't entered already.

[Pecan]

afb,

I've been compiling SVN CB using the Unicode version of wxWidgets with Mac CodeBlocks for about two months.  It's one problem after another.

No problem compiling, that runs fine. It's the executable behavior. For example, a unicode pgm will not accept clipboard input. Some source files load as if empty. I can't find an encoding that works with all the files in a project. etc, etc. 

I've decided to give it up and go back to the ansi version.

Could you tell me why you're using the ansi version of wxWidgets. Just for my education.

thanks
pecan

[afb]

I've been compiling SVN CB using the Unicode version of wxWidgets with Mac CodeBlocks for about two months. 

I'm using "ANSI" for the manual build in /usr/local, and "UNICODE" for the DarwinPorts build in /opt/local...
Mostly because those are the respective defaults, but also since that's one way to test with and compare both...

It's one problem after another.

No problem compiling, that runs fine. It's the executable behavior. For example, a unicode pgm will not accept clipboard input. Some source files load as if empty. I can't find an encoding that works with all the files in a project. etc, etc. 

The app is not working very good for me either, especially not the Intel version, but I haven't narrowed it down.

I've decided to give it up and go back to the ansi version.

Could you tell me why you're using the ansi version of wxWidgets. Just for my education.

I am using wxWidgets for the D bindings project, and we haven't finished all Unicode "porting"...
Besides, I've found the "ANSI" version to be less buggy on Mac and Win but that could be just me.