Code::Blocks Forums

User forums => Help => Topic started by: bnilsson on July 15, 2006, 04:22:30 pm

Title: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 15, 2006, 04:22:30 pm
Hi!

When will we get Code::Blocks for Mac OS X?

Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: BigAngryDog on July 15, 2006, 04:39:18 pm
I've been a Windows user for a long time. However, the way I see it, the long term future of Windows in no longer guaranteed.

Therefore, giving effort to supporting C::B on Mac OS X in the future would be good thing.

I am currently writing code on HP-UX - using the VI editor! My guess is that C::B would be widely adopted within industry if it were to be supported on HP-UX/Solaris.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: MortenMacFly on July 15, 2006, 05:22:19 pm
My guess is that C::B would be widely adopted within industry if it were to be supported on HP-UX/Solaris.
I'd fully agree on that point. In industry and research such systems are really common. And admins of those often stick with vi because there is no other (better) solution. Unfortunately I have no login to any of the HP-UX/Solaris servers at work, otherwise I'd try to compile C::B there "immediately". However: I wonder if wxWidgets is supported on these platforms... I should have a look...
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: MortenMacFly on July 15, 2006, 05:26:36 pm
When will we get Code::Blocks for Mac OS X?
Sorry, that I haven't answered this is my previous post.
AFAIK the core devs don't have MAC's, otherwise I'd say it would already be possible. A MAC isn't something you just buy, this is a matter of money. So it's hard to develop for a platform you don't have. If people like to have support for the MAC, there is a possibility to donate money for C::B which would certainly help to buy a MAC... ;-)
With regards, Morten.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 15, 2006, 06:07:44 pm
A Mac-mini is not all that expensive, it starts at $600.
And it runs native WinXP as well (fast), so it would not have to be dedicated to this project only.


Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: MortenMacFly on July 15, 2006, 07:13:11 pm
A Mac-mini is not all that expensive, it starts at $600.
I didn't mean to say a MAC is expensive. All I wanted to point out is that unfortunately the devs don't have a MAC (currently) which makes developement for MAC difficult. I would love to see a MAC version, too. IMHO this would be the first serious IDE which is available for Windows, Linux and MAC then. There are some trials running (search the forum for MAC support) but this isn't very robust yet.
With regards, Morten.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on July 16, 2006, 12:00:32 am
For the time being, the only builds for MacOS have to be supplied by the community. The same goes for any compatibility fixes, sorry.

While we attempt to write code that has a chance to compile without too much pain, we really cannot tell, as we have no Apple machines around.

Buying a Macintosh is not an option at this time, however donations to the Code::Blocks project are always welcome. :)
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: fooman on July 16, 2006, 12:45:21 am
Wow, C:B devs and everyone involved should be thanked and praised as Gods... especially if they can get a multi-platform IDE on all 3 major systems.

Seriously, that'd blow my mind.  Where else can you find that?!
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Seronis on July 16, 2006, 04:35:00 am
A friend of mine for many years is the CIS teacher at the local joint JrHigh / HighSchool.  The school insists on ONLY having Macs for student use.  I believe they only have one Win98 computer in the entire building and thats for library use only.  She asks me nearly every year if i've found any software to help her programming class to get a real world experience, namely something that is uniform on Mac and additionally either Win or Linux.  If C::B ever becomes OSX compatible (or if someone can give me fine grain instructions on how to set it up on a mac, i have little mac experience) you would have a couple thousand students experimenting on occasion with CB and wxWidgets.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 16, 2006, 05:23:37 am
There is a usable older version of CodeBlocks for the Mac at


http://prdownload.berlios.de/codeblocks/codeblocks-rev2411_macppc.zip
 (http://prdownload.berlios.de/codeblocks/codeblocks-rev2411_macppc.zip)

built by contributor afb. It's in bundle (.app) form. It does not include any contribs or scripting, but  works.

I'm currently working on the contribs, and a .cbp to include the squirrel scripting environment.

This version is not ready for prime time. But it's there, and can be used to even compile the current svn. (as soon as I update the cbp)
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Game_Ender on July 16, 2006, 07:09:43 am
I just want to make sure I understand everything fully.  No one except Afb has been able to get CB to build using automake scripts.  So the current solution for building CB on mac is to use that old binary to build the current SVN which has most of the current Mac patches applied with a CodeBlocks-Mac.cbp (You know we really should switch to one project file with build scripts changing things based on platform)?

I will give it a small try to build a universal CB with the autotools using darwin ports and an Intel iMac.  I only have access to a mac at work, but we too would benefit from a cross platform IDE like Code::Blocks.  If I am feeling quite into I might try and leverage my Xcode knowledge and port the Code::Blocks project file over, its what most open source project on Mac use.  That would be after my summer class finishes.

About the project file:  Does anyone else think its kind of odd that a cross platform IDE can't use a single project file for all platforms?
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 16, 2006, 02:22:30 pm
I just want to make sure I understand everything fully.  No one except Afb has been able to get CB to build using automake scripts.  So the current solution for building CB on mac is to use that old binary to build the current SVN which has most of the current Mac patches applied with a CodeBlocks-Mac.cbp

That is correct AFAIK. There is no evidence that  anyone else (besides afb) has successfully built CodeBlocks on the MAC with autotools.
 
Quote
About the project file:  Does anyone else think its kind of odd that a cross platform IDE can't use a single project file for all platforms?

After having built two separate, vastly differing project files for the MAC (10.3 vs 10.4), then having to restructure each for squirrel, I can understand why there are separate .cbp's. It would be a tangled web having only one .cbp. I'd hate thinking about maintaining it.

Quote
...If I am feeling quite into I might try and leverage my Xcode knowledge and port the Code::Blocks project file over...

If you build using wxMac2.6.x unicode, it crashes in strconv.cpp attempting to call a pure virtual function. Fix it by changing MB2WC and WC2MB to the global functions wxMB2WC and wxWC2MB. It's  most likely an awful typo.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: sethjackson on July 16, 2006, 03:01:05 pm
About the project file:  Does anyone else think its kind of odd that a cross platform IDE can't use a single project file for all platforms?

Yes. However I think Pecan may be right. It could get to be a mess to maintain. :P
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Game_Ender on July 16, 2006, 06:33:00 pm
If you build using wxMac2.6.x unicode, it crashes in strconv.cpp attempting to call a pure virtual function. Fix it by changing MB2WC and WC2MB to the global functions wxMB2WC and wxWC2MB. It's  most likely an awful typo.

Thanks for the advice, I have only built a non-monolithic, universal, ansi build or wxMac 2.6.x.  If I run into trouble on the unicode build I will try.

[Offtopic: About turning CB into a cross-platfrom developement platform]

About the project file:  Can't things like a common set of build scripts help us out here?  You just make a script for each platform specific thing you have to do and it just change options based on platform.  Of course that sounds nice in practice, but it almost makes CB's nice UI for picking build option useless.

If I find the time I will give a comparative look to the standard and unix cbp files and see how the big differences are.  If it turns out that it is too difficult I think we need to come up with some way to make it easy. 

Maybe a CB::Config (like autotools but for Code::Blocks) that does a platform specific configuration on project loading and of course it would be driven by scripts too.  It could do things like set variables (WX_LIBS) for example to right thing on each platform.  That is where the scripts could come, if there script bindings had the ability to search through directories and file on disk you could have a script that runs and sets the value of WX_LIBS.  I realize this is similar to autotools, but autoconf scripts look like black magic to me and be able to whip up something in the C/C++ like squriell would be easier.  We could of course store these on the wiki or maybe in the same way plugins will be distributed in the future.

Or possibly a way for each target to have multiple platform specific versions.  Currently settings our inherited like so Compiler->Project->Target.  We might add a 4th layer Compiler->Project->Target->Platform.  The could work in conjuction to the above CB:Config pluggin.

EDIT: Either we do that or find some way to go back and forth between cmake files and cbp project files.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on July 16, 2006, 07:05:35 pm
Quote
About the project file:  Does anyone else think its kind of odd that a cross platform IDE can't use a single project file for all platforms?
No, not at all.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Game_Ender on July 16, 2006, 08:15:24 pm
No, not at all.
I think its obivious the CB dev teams doesn't think its too odd, after all that is how Code::Blocks is developed.

That makes sense if you you take the approach Project File = Makefile, to put it in unix terms.  I am hoping that a system can be developed where we get Project File = autoconf + automake scripts.  Although that is probably to large a goal for the Code::Blocks core, so something like the plugin I sketched out above would probably be a better idea.  Of course the whole idea maybe overly complex but autotools are popular for a reason.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 16, 2006, 11:50:19 pm
I was able to generate the configuration files by installing the latest autoconf, automake, and libtool using darwinports and by modifying bootstrap file somewhat
./configure generated the Makefiles as it should.
However, it failed in the make process.
What version of wxwidgets is required?
My wxwidgets is installed using darwinports, it is version 2.6.3.
The first error was in that wxUSleep was not declared.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on July 17, 2006, 12:38:25 am
This error is not Macintosh specific. It is a bug in the Code::Blocks sources which is normally not visible (and which nobody cares about), as it is hidden in some #ifdef construct. Strange that you see it though, that part of code should only be evaluated for wx 2.4.

Replace wxUSleep with wxUsleep.

Actually, this should have been removed many months ago. We talked about removing it alltogether (since we don't support wx 2.4 anyway) but then we somehow forgot about it.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on July 17, 2006, 12:50:14 am
Ah, never mind... I removed it. Just run svn update.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 17, 2006, 10:16:30 am
Thanks, wxUsleep helped.

Now to the next:
In file included from ../../../src/src/wxDockit/include/wx/gripper.h:19,
                 from src/generic/barholder.cpp:13:
../../../src/src/wxDockit/include/wx/gdi.h:64:6: error: #error "Your platform does not currently support wxGdi"

Is there anything that can be done about this?
I did not specify any options when installing wxwidgets using darwinports.
Any good links for svn, since I don't have it?


Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on July 17, 2006, 10:49:11 am
Quote
In file included from ../../../src/src/wxDockit/include/wx/gripper.h:19
Hmm... that's a strange one, we don't reference wxDockit at all any more (we use wxAUI).
Unless wxprec.h includes it (which I don't know), I have no idea how this would be included at all. Global search does not find any of gripper.h, barholder.h, or gdi.h in the entire source tree of Code::Blocks.

Maybe you could try and recompile wxWidgets from source? It almost looks like something *inside* your wxWidgets install is not consistent?

Quote
Any good links for svn, since I don't have it?
http://subversion.tigris.org
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 17, 2006, 12:17:32 pm
In the released source kit for BC (codeblocks-1.0rc2) there is definetely a wxDockit and a gripper.h inside it:
.//src/src/wxDockit/include/wx/gripper.h
Are you referring to a development version?

Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 17, 2006, 12:58:24 pm
In the released source kit for BC (codeblocks-1.0rc2) there is definetely a wxDockit and a gripper.h inside it:
.//src/src/wxDockit/include/wx/gripper.h
Are you referring to a development version?



You really do not want to waste your time on CB 1.0rc2.
Building from SVN will reward you in both short and long run.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on July 17, 2006, 01:32:20 pm
In the released source kit for BC...
This will never work.
Get Subversion (http://subversion.tigris.org) and run svn checkout svn://svn.berlios.de/codeblocks/trunk from a console. Then try what happens if you run ./bootstrap and configure
Title: wxWidgets With Code::Blocks
Post by: Angel Portal on July 17, 2006, 01:47:13 pm
I installed the wxWidgtes in the c:\ directory.
How do I configure the Code::Blocks to use the Library.
I did what it was explained in the IDE but it is not
enouth.

Angel Portal
angelp@correios.net.br
Title: Re: wxWidgets With Code::Blocks
Post by: sethjackson on July 17, 2006, 01:54:46 pm
I installed the wxWidgtes in the c:\ directory.
How do I configure the Code::Blocks to use the Library.
I did what it was explained in the IDE but it is not
enouth.

Angel Portal
angelp@correios.net.br

Please do not hijack threads like this......

EDIT:

Cross-posting (http://forums.codeblocks.org/index.php?topic=3577.0) isn't so good either....
Title: Re: wxWidgets With Code::Blocks
Post by: Angel Portal on July 17, 2006, 02:03:51 pm
I Posted By mistake.
It it was not done by proposal.
Best Regards

Please do not hijack threads like this......

EDIT:

Cross-posting (http://forums.codeblocks.org/index.php?topic=3577.0) isn't so good either....
Title: Re: wxWidgets With Code::Blocks
Post by: sethjackson on July 17, 2006, 02:04:48 pm
I Posted By mistake.
It it was not done by proposal.
Best Regards

Please do not hijack threads like this......

EDIT:

Cross-posting (http://forums.codeblocks.org/index.php?topic=3577.0) isn't so good either....

K. See my reply to your other post. ;)
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 17, 2006, 02:39:33 pm
I realize I have not presented my platform:
PoweMac G5 dual 2.3GHz
Mac OS X 10.4.7
wxwidgets 2.6.3 / darwinports

I did svn checkout of CB, a re-install of wxwidgets, bootstrap, configure and make.
This time I did not get very far in make:

./infowindow.h:52: error: expected class-name before '{' token
make[2]: *** [sdk.h.gch] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

and if I just remove by // : public wxPopupWindow
to test and condinue make I get another halt at 

./src/propgrid/propgrid.cpp: In member function 'virtual bool wxPropertyGrid::SetFont(const wxFont&)':
./src/propgrid/propgrid.cpp:5904: error: 'res' was not declared in this scope

I see no reason to continue at this point.
Any hints would be appreciated.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 17, 2006, 03:14:50 pm
And my gcc version:
gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5341)

Is this thread the proper one for trying to build CB for OS X on a Mac by 'remote support'?
Or is it just a waste of time (mine and everybody else's) before a core developer gets his/her hands on a Mac?
I am happy to give it some time if you can bear with me, but I guess it will be slow.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 17, 2006, 05:17:30 pm
I realize I have not presented my platform:
PoweMac G5 dual 2.3GHz
Mac OS X 10.4.7
wxwidgets 2.6.3 / darwinports

I did svn checkout of CB, a re-install of wxwidgets, bootstrap, configure and make.
This time I did not get very far in make:

./infowindow.h:52: error: expected class-name before '{' token
make[2]: *** [sdk.h.gch] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

and if I just remove by // : public wxPopupWindow
to test and condinue make I get another halt at 

./src/propgrid/propgrid.cpp: In member function 'virtual bool wxPropertyGrid::SetFont(const wxFont&)':
./src/propgrid/propgrid.cpp:5904: error: 'res' was not declared in this scope

I see no reason to continue at this point.
Any hints would be appreciated.


wxWidgets for Mac has no support for wxPopupWindow. Here is a workaround.
Replace infowindow.h and infowindow.cpp with the following.

infowindow.h
Code
/*
* Objects of type InfoWindow are autonomous and must therefore always be instantiated using operator new.
* In addition to this, InfoWindow does not have any non-static public class members.
*
* Since a (technically 100% correct) statement like
*   new InfoWindow("foo", "bar");
* is unintuitive, confusing or even objective to some people, this class uses a variation of the "Named Constructor Idiom".
*
* InfoWindow::Display("foo", "bar");
* does the exact same thing as the above statement but looks a lot nicer.
*/

#ifndef INFOWINDOW_H
#define INFOWINDOW_H
//#define __WXMAC__
//-----------------------------------------------------------------------------
#if (defined(__WXMAC__) || defined(_TEST_NO_INFOWINDOW_))
//-----------------------------------------------------------------------------
// There is no wxPopupWindows for wxMac. Use wxMessageBox instead.

class InfoWindow : public wxWindow
{
    public:

    InfoWindow(const wxString& title, const wxString& message, unsigned int delay, unsigned int hysteresis)
        {       ::wxMessageBox(message, title, wxOK, NULL, -1, -1);
                Destroy();
        }
    ~InfoWindow() {;}

    static void Display(const wxString& title, const wxString& message, unsigned int delay = 5000, unsigned int hysteresis = 1)
      { new InfoWindow(title, message, delay, hysteresis);}


};
#endif //(_WXMAC_)

//-----------------------------------------------------------------------------
#if (!defined(__WXMAC__) && !defined(_TEST_NO_INFOWINDOW_))
//-----------------------------------------------------------------------------
#include <wx/event.h>
#include <wx/timer.h>
#include <wx/string.h>
#include <wx/popupwin.h>
#undef new
#include <list>
#include <algorithm>

class Stacker
{
    std::list<int> widths;

    public:

    int StackMe(int mySize)
    {
        mySize += 3;
        int pos = 0;

        if(!widths.empty())
            pos = *(std::max_element(widths.begin(), widths.end()));

        widths.push_back(pos + mySize);
        return pos + mySize;
    };

    void ReleaseMe(int myPos)
    {
        std::list<int>::iterator it = std::find(widths.begin(), widths.end(), myPos);
        if(it != widths.end())
            widths.erase(it);
    };
};

class InfoWindow : public wxPopupWindow
{
    wxTimer *m_timer;
    int left;
    int top;
    int hMin;
    int pos;
    unsigned int status;
    unsigned int m_delay;
    unsigned int ks;
    static Stacker stacker;
    static int screenWidth;
    static int screenHeight;

    InfoWindow(const wxString& title, const wxString& message, unsigned int delay, unsigned int hysteresis);
    virtual ~InfoWindow();
    void OnTimer(wxTimerEvent& e);
    void OnMove(wxMouseEvent& e);
    void OnClick(wxMouseEvent& e);
    DECLARE_EVENT_TABLE()

    public:

    static void Display(const wxString& title, const wxString& message, unsigned int delay = 5000, unsigned int hysteresis = 1)
        {new InfoWindow(title, message, delay, hysteresis);};
};

#endif //!defined( _WX_MAC_)
#endif

Replace infowindow.cpp with the following:
Code
#include "sdk_precomp.h"

// --------------------------------------------------------------------------
#if (!defined(__WXMAC__) && !defined(_TEST_NO_INFOWINDOW_))
// --------------------------------------------------------------------------

#ifndef CB_PRECOMP
    #include <wx/stattext.h>
    #include <wx/sizer.h>
    #include <wx/settings.h>
    #include "infowindow.h"
    #include "manager.h"
#endif

BEGIN_EVENT_TABLE(InfoWindow, wxPopupWindow)
EVT_TIMER(-1, InfoWindow::OnTimer)
EVT_MOTION(InfoWindow::OnMove)
EVT_LEFT_DOWN(InfoWindow::OnClick)
EVT_RIGHT_DOWN(InfoWindow::OnClick)
END_EVENT_TABLE()

const wxColour titleBackground(96,96,96); // dark grey
const wxColour textBackground(255,255,160); // yellowish


const char *iBitmap[] = {
"20 20 38 1",
"  c #606060",
". c gray38",
"X c #646464",
"o c #656565",
"O c gray40",
"+ c gray45",
"@ c gray50",
"# c blue",
"$ c #0808FF",
"% c #0A0AFF",
"& c #0B0BFF",
"* c #2121FF",
"= c #2828FF",
"- c #3838FF",
"; c #4545FF",
": c #4646FF",
"> c #5656FF",
", c #5959FF",
"< c gray51",
"1 c #8E8E8E",
"2 c gray59",
"3 c #9191A7",
"4 c #8888EF",
"5 c #8080F7",
"6 c #8282F7",
"7 c #8787FE",
"8 c #8A8AFE",
"9 c #9696FE",
"0 c #9797FF",
"q c #ABABFF",
"w c #CDCDFF",
"e c #D5D5FF",
"r c #E4E4F9",
"t c gray96",
"y c #F6F6F6",
"u c gray97",
"i c #F8F8F8",
"p c gray100",
"     X+<1221<+O     ",
"   X+35,=&&=,63+X   ",
"  X@4:########:4@X  ",
" X@5*#&>0ww0,&#*5@X ",
" +4*#-qppppppq:#*4+ ",
"X3:#:eppp##pppe:#:3X",
"+6#&qpppp##ppppq&#6+",
"<,#,ppppp##ppppp,#,@",
"1=#9ppppp##ppppp0#=1",
"2&#wppppp##pppppw#&2",
"i&#wppppp##pppppw#&u",
"i=#9ppppp##ppppp0#=u",
"u,#>pppppppppppp>#,y",
"y8#&qpppp##ppppq$#8y",
"yr:#:eppp##pppe:#:rt",
"yy9*#:qppppppq:#*9yt",
"yyy7*#$>0ww0>&#*7ytt",
"ttyy9:########:9yytt",
"ttttyr8,=&&=,8ryyttt",
"ttttyyyyiuuuuyyyyttt"
};


Stacker InfoWindow::stacker;

// in wxGTK this initialization raises an assertion (makes sense too)
// so initialize them to -1 and we 'll set them up correctly in InfoWindow's ctor the first time
int InfoWindow::screenWidth = -1;//wxSystemSettings::GetMetric(wxSYS_SCREEN_X);
int InfoWindow::screenHeight = -1;//wxSystemSettings::GetMetric(wxSYS_SCREEN_Y);

namespace // anonumous
{
    // while in windows world, sleep(1) takes anywhere between 20-50 milliseconds,
    // in linux sleep(1) means sleep 1 millisecond.
    // so we need conditional compilation here in order for the scrolling effect to be
    // visible under non-windows platforms :)
#ifdef __WXMSW__
    static const int scroll_millis = 1;
#else
    static const int scroll_millis = 5;
#endif
} // anonumous namespace

class ForwardingTextControl : public wxStaticText
{
    void OnEvent(wxMouseEvent& e){e.ResumePropagation(10); e.Skip();};
    DECLARE_EVENT_TABLE();
    public:
    ForwardingTextControl(wxWindow* parent, wxWindowID id, const wxString& label, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0) : wxStaticText(parent, id, label, pos, size, style){};
};

BEGIN_EVENT_TABLE(ForwardingTextControl, wxStaticText)
EVT_MOUSE_EVENTS(ForwardingTextControl::OnEvent)
END_EVENT_TABLE()


InfoWindow::InfoWindow(const wxString& title, const wxString& message, unsigned int delay, unsigned int hysteresis)
            : wxPopupWindow(Manager::Get()->GetAppWindow(), wxSIMPLE_BORDER | wxWS_EX_TRANSIENT | wxCLIP_CHILDREN),
              m_timer(new wxTimer(this, 0)), status(0), m_delay(delay), ks(2)
    {
        wxBoxSizer *bs = new wxBoxSizer(wxVERTICAL);

        wxWindow* o = 0;
#ifdef __WXGTK__
        wxBoxSizer *pbs = new wxBoxSizer(wxVERTICAL);
        wxPanel* pnl = new wxPanel(this, -1, wxDefaultPosition, wxDefaultSize, wxALIGN_CENTRE);
        pnl->SetBackgroundColour(titleBackground);
        ForwardingTextControl *titleC = new ForwardingTextControl(pnl, -1, title, wxDefaultPosition, wxDefaultSize, wxALIGN_CENTRE);
        pbs->Add(titleC, 0, wxALL|wxALIGN_CENTER, 5);
        pnl->SetSizer(pbs);
        pbs->SetSizeHints(pnl);
        o = pnl;
#else
        ForwardingTextControl *titleC = new ForwardingTextControl(this, -1, title, wxDefaultPosition, wxDefaultSize, wxALIGN_CENTRE);
        titleC->SetBackgroundColour(titleBackground);
        o = titleC;
#endif
        titleC->SetForegroundColour(*wxWHITE);
        titleC->SetFont(wxFont(11, wxSWISS, wxNORMAL, wxBOLD));
        bs->Add(o, 0, wxGROW|wxALIGN_CENTER_VERTICAL, 5);

        ForwardingTextControl *text = new ForwardingTextControl(this, -1, message, wxDefaultPosition, wxDefaultSize, 0);
        text->SetBackgroundColour(textBackground);
        bs->Add(text, 0, wxALIGN_CENTER|wxALL, 12);
        SetBackgroundColour(textBackground);
        SetSizer(bs);
        bs->SetSizeHints(this);
        Layout();

#ifndef __WXGTK__
        // since we used a panel, no more bitmap :(
        new wxStaticBitmap(this, -1, wxBitmap(iBitmap), wxPoint(4, o->GetRect().GetBottom() - 9));
#endif
        wxCoord w, h;
        GetClientSize(&w, &h);

        pos = stacker.StackMe(w);

        // setup variables first time we enter here
        if (screenWidth == -1)
            screenWidth = wxSystemSettings::GetMetric(wxSYS_SCREEN_X);
        if (screenHeight == -1)
            screenHeight = wxSystemSettings::GetMetric(wxSYS_SCREEN_Y);

        left = screenWidth - pos;
        hMin = screenHeight - h;
        top = screenHeight;

        Move(left, top);

        Show();
        m_timer->Start(hysteresis, false);
    };


InfoWindow::~InfoWindow()
    {
        delete m_timer;
        stacker.ReleaseMe(pos);
    };

void InfoWindow::OnTimer(wxTimerEvent& e)
{
    switch(status)
    {
    case 0:
        status = 1;
        m_timer->Start(scroll_millis, false);
        break;
    case 1:
        top -= 2;
        Move(left, top);
        if(top <= hMin)
        {
            status = 2;
            m_timer->Start(m_delay, true);
        }
        break;
    case 2:
        status = 3;
        m_timer->Start(scroll_millis, false);
        break;
    case 3:
        top += ks;
        Move(left, top);
        if(top > screenHeight)
        {
            Hide();
            Destroy();
        }
        break;
    };
};

void InfoWindow::OnMove(wxMouseEvent& e)
{
    if(status == 2)
        m_timer->Start(m_delay, true);
}

void InfoWindow::OnClick(wxMouseEvent& e)
{
    ks = 6;
    status = 3;
    m_timer->Start(scroll_millis, false);
}

// --------------------------------------------------------------------------
#endif //!defined(__WXMAC__)
// --------------------------------------------------------------------------


I have not tested this extensively, but I have forced it to execute on both windows and OS X 10.3.

I will make a patch as soon as I'm certain it works on all platforms.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on July 17, 2006, 05:58:22 pm
Quote
wxWidgets for Mac has no support for wxPopupWindow. Here is a workaround.
The purpose of InfoWindow was to remove many of those annoying, intrusive dialog boxes. The idea was that even if you show messages of low importance that way ("the project was created"), it does not prevent the user from doing his work. On the downside, because InfoWindow is a lot less disturbing, we now have even more of them than before. Reverting to message boxes will probably make life on Macintosh a pain :?
The reason for using wxPopupWindow in the first place was that there is no obvious way (at least not obvious to me) to open a window that doesn't immediately hijack the focus and move the top-level window back. wxPopupWindow, on the other hand side (although not documented) is perfectly unintrusive.
Do you think it would be a good idea to try to find a hack that generates a "normal" thin-border toplevel window which gives back focus to the main window as soon as it gets it? There must be a way to accomplish this, since for example the popups shown by a wxChoice or wxComboBox are implemented using wxPopupWindow under GTK and Windows. Obviously, there must be a way to do this on MacOS, too.

Quote
Or is it just a waste of time (mine and everybody else's) before a core developer gets his/her hands on a Mac?
Well, let's put it that way: my estimate of the likelihood for this to happen during the next half year is zero.

To my knowledge, none of the other core devs has access to a Mac. I am a former Mac user decided to never spend one Euro on overpriced underpowered Apple hardware again, so that concludes myself, anyway ;)
Yiannis might possibly buy a machine from the project's donations one distant day in the future. However, to date, the donations do not even cover the web hosting for the forums, so that idea is way out of sight.
Thus... unless a core dev happens to change jobs and happens to find a Mac over there, or some crazy rich Texan donates a Mac, the chances are dim, very dim... :(

(http://www.tvsquad.com/media/2006/03/texan.jpg)
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 17, 2006, 06:25:07 pm
Quote
wxWidgets for Mac has no support for wxPopupWindow...
The purpose of InfoWindow was to remove many of those annoying, intrusive dialog boxes.
<snip>
Do you think it would be a good idea to try to find a hack that generates a "normal" thin-border toplevel window which gives back focus to the main window as soon as it gets it? There must be a way to accomplish this, since for example the popups shown by a wxChoice or wxComboBox are implemented using wxPopupWindow under GTK and Windows. Obviously, there must be a way to do this on MacOS, too.

Yes, a hack is needed. And thank you for the hints re: wxComboBox and wxChoice.
The only reason I "hacked back" to messageBox was to get the new squirrel code working on the Mac and create new project xml's and patches.

I had already put the "infoMessage" support on the todo list.

I do, however, think that there are going to be many developers using CB on the Mac someday. Probably sooner than later looking at the interest stirred up on the forum. (Especially in schools)

Being an old Mac poo'er myself I was given the iMac and challenged to make CB work on it. With the promise that there would be a MacnTel in the future if I succeeded. So here I am..

Note: there is a wxBounty on making wxPopupWindow work on the Mac. Anyone interested?

Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 17, 2006, 06:25:58 pm
Pecan,

Thanks for the advice, I applied the workaround to infowindow.
I also made a change to wxPropertyGrid::SetFont, and moved the last return statement on line 5904 to a place inside the #if !defined(__WXMAC__) statement since it was undeclared in this context.

Now it compiles ok, but it does not link to wxwidgets, it concludes all wx symbols to be unresolved:
/usr/bin/ld: Undefined symbols:
wxStringBase::npos
wxStringBase::InitWith(wchar_t const*, unsigned long, unsigned long)
wxThread::TestDestroy()
wxThread::~wxThread()
...and more.

My wxWidgets is installed at /opt/local/lib:
ls -la /opt/local/lib/libwx*
-rwxr-xr-x   2 root  admin  7245824 Jul 17 13:48 /opt/local/lib/libwx_macu-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       26 Jul 17 13:56 /opt/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       22 Jul 17 13:56 /opt/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
-rwxr-xr-x   2 root  admin    93992 Jul 17 13:52 /opt/local/lib/libwx_macu_animate-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       34 Jul 17 13:56 /opt/local/lib/libwx_macu_animate-2.6.0.dylib -> libwx_macu_animate-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       30 Jul 17 13:56 /opt/local/lib/libwx_macu_animate-2.6.dylib -> libwx_macu_animate-2.6.0.dylib
-rwxr-xr-x   2 root  admin   524160 Jul 17 13:52 /opt/local/lib/libwx_macu_deprecated-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       37 Jul 17 13:56 /opt/local/lib/libwx_macu_deprecated-2.6.0.dylib -> libwx_macu_deprecated-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       33 Jul 17 13:56 /opt/local/lib/libwx_macu_deprecated-2.6.dylib -> libwx_macu_deprecated-2.6.0.dylib
-rwxr-xr-x   2 root  admin   471244 Jul 17 13:49 /opt/local/lib/libwx_macu_fl-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       29 Jul 17 13:56 /opt/local/lib/libwx_macu_fl-2.6.0.dylib -> libwx_macu_fl-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       25 Jul 17 13:56 /opt/local/lib/libwx_macu_fl-2.6.dylib -> libwx_macu_fl-2.6.0.dylib
-rwxr-xr-x   2 root  admin   259340 Jul 17 13:49 /opt/local/lib/libwx_macu_gizmos-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       33 Jul 17 13:56 /opt/local/lib/libwx_macu_gizmos-2.6.0.dylib -> libwx_macu_gizmos-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       29 Jul 17 13:56 /opt/local/lib/libwx_macu_gizmos-2.6.dylib -> libwx_macu_gizmos-2.6.0.dylib
-rwxr-xr-x   2 root  admin    44872 Jul 17 13:49 /opt/local/lib/libwx_macu_gizmos_xrc-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       37 Jul 17 13:56 /opt/local/lib/libwx_macu_gizmos_xrc-2.6.0.dylib -> libwx_macu_gizmos_xrc-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       33 Jul 17 13:56 /opt/local/lib/libwx_macu_gizmos_xrc-2.6.dylib -> libwx_macu_gizmos_xrc-2.6.0.dylib
-rwxr-xr-x   2 root  admin    73348 Jul 17 13:48 /opt/local/lib/libwx_macu_gl-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       29 Jul 17 13:56 /opt/local/lib/libwx_macu_gl-2.6.0.dylib -> libwx_macu_gl-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       25 Jul 17 13:56 /opt/local/lib/libwx_macu_gl-2.6.dylib -> libwx_macu_gl-2.6.0.dylib
-rwxr-xr-x   2 root  admin   474980 Jul 17 13:50 /opt/local/lib/libwx_macu_ogl-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       30 Jul 17 13:56 /opt/local/lib/libwx_macu_ogl-2.6.0.dylib -> libwx_macu_ogl-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       26 Jul 17 13:56 /opt/local/lib/libwx_macu_ogl-2.6.dylib -> libwx_macu_ogl-2.6.0.dylib
-rwxr-xr-x   2 root  admin   148260 Jul 17 13:50 /opt/local/lib/libwx_macu_plot-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       31 Jul 17 13:56 /opt/local/lib/libwx_macu_plot-2.6.0.dylib -> libwx_macu_plot-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       27 Jul 17 13:56 /opt/local/lib/libwx_macu_plot-2.6.dylib -> libwx_macu_plot-2.6.0.dylib
-rwxr-xr-x   2 root  admin  1189712 Jul 17 13:51 /opt/local/lib/libwx_macu_stc-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       30 Jul 17 13:56 /opt/local/lib/libwx_macu_stc-2.6.0.dylib -> libwx_macu_stc-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       26 Jul 17 13:56 /opt/local/lib/libwx_macu_stc-2.6.dylib -> libwx_macu_stc-2.6.0.dylib
-rwxr-xr-x   2 root  admin    99268 Jul 17 13:51 /opt/local/lib/libwx_macu_svg-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       30 Jul 17 13:56 /opt/local/lib/libwx_macu_svg-2.6.0.dylib -> libwx_macu_svg-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       26 Jul 17 13:56 /opt/local/lib/libwx_macu_svg-2.6.dylib -> libwx_macu_svg-2.6.0.dylib

What is the expected path for wxWidgets?

Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 17, 2006, 06:42:39 pm
Pecan,

Thanks for the advice, I applied the workaround to infowindow.
I also made a change to wxPropertyGrid::SetFont, and moved the last return statement on line 5904 to a place inside the #if !defined(__WXMAC__) statement since it was undeclared in this context.

Now it compiles ok, but it does not link to wxwidgets, it concludes all wx symbols to be unresolved:
/usr/bin/ld: Undefined symbols:
wxStringBase::npos
wxStringBase::InitWith(wchar_t const*, unsigned long, unsigned long)
wxThread::TestDestroy()
wxThread::~wxThread()
...and more.

My wxWidgets is installed at /opt/local/lib:
ls -la /opt/local/lib/libwx*
-rwxr-xr-x   2 root  admin  7245824 Jul 17 13:48 /opt/local/lib/libwx_macu-2.6.0.3.1.dylib
lrwxr-xr-x   1 root  admin       26 Jul 17 13:56 /opt/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
<snip>
lrwxr-xr-x   1 root  admin       26 Jul 17 13:56 /opt/local/lib/libwx_macu_svg-2.6.dylib -> libwx_macu_svg-2.6.0.dylib

What is the expected path for wxWidgets?


1) you're using unicode. Is codeblocks compiled as unicode? or ansi?
2) what does your "wx-config --cflags" and "wx-config --libs" produce?

So far, I believe I'm the only one using unicode. It has a bug that'll byte you hard.
Do a search on this forum for strconv.cpp

Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 17, 2006, 06:51:01 pm
Pecan,

I did not specify any directives except ./configure --enable-contrib
as described in BUILD.

[Tiger:~] bnilsson% wx-config --cflags
-I/opt/local/lib/wx/include/mac-unicode-release-2.6 -I/opt/local/include/wx-2.6 -D__WXMAC__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA
[Tiger:~] bnilsson% wx-config --libs
-L/opt/local/lib  -L/opt/local/lib -L/opt/local/lib -framework QuickTime -framework IOKit -framework Carbon -framework Cocoa -framework System  -lwx_macu-2.6
[Tiger:~] bnilsson%
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 17, 2006, 07:06:34 pm
Pecan,

I did not specify any directives except ./configure --enable-contrib
as described in BUILD.

[Tiger:~] bnilsson% wx-config --cflags
-I/opt/local/lib/wx/include/mac-unicode-release-2.6 -I/opt/local/include/wx-2.6 -D__WXMAC__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA
[Tiger:~] bnilsson% wx-config --libs
-L/opt/local/lib  -L/opt/local/lib -L/opt/local/lib -framework QuickTime -framework IOKit -framework Carbon -framework Cocoa -framework System  -lwx_macu-2.6
[Tiger:~] bnilsson%

I suspect somehow you ended up with an ansi CB build.

Can you do a "./configure --help" and see if you can specify the way CB is built. Eg, you might need "./configure --enable-shared --enable-monolithic --enable-unicode" or some such verbage in order to match CB to your wx libs.

I've never been able to make the autotools work on my 10.3, so I'm not much help here.
The trick is to generate CB to match the wx libs.

Also look at your config.log and config.status to see what it thought it was doing.


Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 17, 2006, 07:13:21 pm
I did not specify any directives except ./configure --enable-contrib
as described in BUILD.

Have you seen this? It might help.

http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X
 (http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X)

Also, check out:

http://forums.codeblocks.org/index.php?topic=2420.0
 (http://forums.codeblocks.org/index.php?topic=2420.0)
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 17, 2006, 08:50:56 pm
Pecan,
Well, the link http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X just about describes what I am trying to do, pretty straight forward.

And about the link to the application, I have seens it.
Actually, you answered my question about a problem I had with it,
After unpacking, starting, and Ok on the compiler detection, I get a window "Scripting Error" Error compiling script, Error code -17(INVALID CONFIGURATION) any you answered that Angelscript wasn't supported yet.
I was hoping a new build would solve the issue, maybe.

I begin to think that my darwinports wxwidgets installation may me the problem.
In /opt/local/lib I see only wx-dylibs. Does wxwidgets never use static libraries?
I will try manual installation from wxMac or similar and try again.

Correct me if I am wrong, but it seems you (and many others) have succeded in building C::B on OS X?
If so, why do we have this problem?
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Game_Ender on July 17, 2006, 11:55:33 pm
Correct me if I am wrong, but it seems you (and many others) have succeded in building C::B on OS X?
If so, why do we have this problem?

There are only a few people who have compiled on Mac OS X and pecan doesn't do it on 10.4 he does it on 10.3.x if I remember correctly.

EDIT: By defualt ./configure does not configure in unicode mode.  You have to use --enable-unicode.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 18, 2006, 12:41:05 am
<snip>
...I get a window "Scripting Error" Error compiling script, Error code -17(INVALID CONFIGURATION) any you answered that Angelscript wasn't supported yet.

AngelScript is no longer used. I thought you were using SVN.
Anyway, getting the error in the first place is a feather in your hat.

Quote
In /opt/local/lib I see only wx-dylibs. Does wxwidgets never use static libraries?

CB only uses dynamic libraries. You can build and use static monolithic libs for your own projects. That is the suggested method for distributing your own Mac apps.

Quote
I will try manual installation from wxMac or similar and try again.

Correct me if I am wrong, but it seems you (and many others) have succeded in building C::B on OS X?
If so, why do we have this problem?

I have never succeeded building wxMac263 on 10.4. So I couldn't build CodeBlocks. I think using a non-default Mac SDK will solve this problem. I suspect wxMac requires SDK3.3, but don't quote me. It's on the todo list. 

I am very successful with Codeblocks on 10.3. No problems. I'm currently trying to find the glitches in wxMac Unicode and keep up with the core developers' changes.

Once I get unicode wx/CB stable, I'll tackle 10.4
 
All of us would be interested in your autotool experience.
Could you do a "1,2,3 steps to success" report?
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 18, 2006, 09:22:50 am
I will report whatever success I might have.
Still I am problem whithe last stage in make, lots of unrecognized wx symbols.
However, I will be away for vacation now for 3 weeks, so I will be silent for a while.

Thanks for all your interest ans support, i'll be back.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 19, 2006, 09:25:23 am
A temporary report on autotools before I leave:

The bootstrap script requires the following versions of autotools etc.
#  - autoconf 2.50+
#  - automake 1.7+
#  - libtool 1.4+
which is not what Apple darwin has as installed. I have 10.4.7 and the latest Xcode tools, so this is a bit surprising, or I missed something.

Install darwinports (http://www.darwinports.org)
and do
port install autoconf
port install automake
port install libtool (which is accessed by the name of glibtool and glibtoolize)

All of these are installed at /opt/local/bin.

I don't want to interfere with the system I do not touch the native versions. and I also skip changing the path order for now.
Instead I change the 'bootstrap' file, see bootstrap.txt:



So I run the bootstrap script:

[Tiger:OpenSource/CBtest/trunk] bnilsson% ./bootstrap
You should add the contents of `/opt/local/share/aclocal/libtool.m4' to `aclocal.m4'.
/opt/local/share/aclocal/xmms.m4:17: warning: underquoted definition of XMMS_TEST_VERSION
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/opt/local/share/aclocal/xmms.m4:62: warning: underquoted definition of AM_PATH_XMMS
/opt/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG
/opt/local/share/aclocal/libmikmod.m4:11: warning: underquoted definition of AM_PATH_LIBMIKMOD
/opt/local/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
/opt/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
/opt/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE
configure.in: installing `./install-sh'
configure.in: installing `./missing'
src/plugins/astyle/Makefile.am: installing `./depcomp'

I cannot judge wether the warnings are serious.
At the top I get an order to do something about aclocal.m4, so I do as I'm told:

[Tiger:OpenSource/CBtest/trunk] bnilsson% cat aclocal.m4 /opt/local/share/aclocal/libtool.m4 > aclocal.m4

[Tiger:OpenSource/CBtest/trunk] bnilsson%

Run it again:

[Tiger:OpenSource/CBtest/trunk] bnilsson% ./bootstrap
/opt/local/share/aclocal/xmms.m4:17: warning: underquoted definition of XMMS_TEST_VERSION
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/opt/local/share/aclocal/xmms.m4:62: warning: underquoted definition of AM_PATH_XMMS
/opt/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG
/opt/local/share/aclocal/libmikmod.m4:11: warning: underquoted definition of AM_PATH_LIBMIKMOD
/opt/local/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
/opt/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
/opt/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE
[Tiger:OpenSource/CBtest/trunk] bnilsson%

Now configure and Makefile are created.
configure and make behaves as expected.
Well, not quite, since make never succeeds since it does not link properly to wxwidgets, lots of unresolved wx symbols.
I cannot tell wether this is another problem or if it actually is because of a problem in the autotools.

Bye for now.

Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on July 19, 2006, 09:36:46 am
Sorry, it seems I am not able to upload bootstrap.txt, upload folder is full.
And I get 404 error no access when I try to introduce it into the text body.
So it has to wait to next time, see you then.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on July 19, 2006, 12:42:01 pm
Sorry, it seems I am not able to upload bootstrap.txt, upload folder is full.
And I get 404 error no access when I try to introduce it into the text body.
So it has to wait to next time, see you then.


Thanks, and have a nice vacation.

Because the forum file area fills up frequently, many of us have found it best to upload to http://savefile.com/ (http://savefile.com/) and reference the files via url in a forum message.

thanks again
pecan
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: RAZZ on August 02, 2006, 04:21:29 am
Um, how much mac would a core dev need, to make this happen? Would, say, an old G3 be ok?
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: killerbot on August 02, 2006, 09:09:21 am
an a good MacOS with decent gcc ...
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on August 02, 2006, 02:32:58 pm
Um, how much mac would a core dev need, to make this happen? Would, say, an old G3 be ok?

I'm running codeblocks on a imacg3 with 500 meg (OS X 10.3).

I have also run it under 10.4 with the 10.3 wxWidgets, but was unsuccessful at compiling widgets 2.6.3 with 10.4 . I'll get back to that someday. It probably just needs to compile with the SDK3.3 .

I used to run it in 128 meg also. But debugging became tedious because of the swapping.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on August 02, 2006, 08:22:58 pm
Um, how much mac would a core dev need, to make this happen? Would, say, an old G3 be ok?
I guess that should do just fine, after all we're not intending to exclusively do the mainstream Code::Blocks development on that machine. If it takes a few minutes more to compile, that's something one would have to live with - the important thing is that it works at all!
We presently don't have the possibility to compile or test anything for MacOS at all, since we neither have the machine, nor the OS for that, which is not a lot ;)
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: takeshimiya on August 03, 2006, 01:53:48 am
We presently don't have the possibility to compile or test anything for MacOS at all, since we neither have the machine, nor the OS for that, which is not a lot ;)
Well, we currently have the possibility to compile in MacOS.
I've talked with Andreas (the author of AngelScript), and so he started to use the SourceForge.net Compile Farm.
Thanks to it, support for 64 bits is almost done now in AS. :)

Using the SourceForge.net Compile Farm we'll have access to a wide range of platforms, including:
-32-bit x86 Architecture (lot's of linux and variants),
-AMD 64-bit (Opteron) Architecture.
-DEC Alpha (ev67) Architecture.
-PowerPC Architecture (Apple Mac G4).
-Sparc (UltraSPARC-II) Architecture.
-IBM Power5 Architecture.

Here's how to use it: http://sourceforge.net/docs/compile_farm
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on August 03, 2006, 09:50:26 am
Well, we currently have the possibility to compile in MacOS.
I've talked with Andreas (the author of AngelScript), and so he started to use the SourceForge.net Compile Farm.
Except that the compile farm does not work for our purpose, Takeshi.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: takeshimiya on August 03, 2006, 10:43:56 am
Well, we currently have the possibility to compile in MacOS.
I've talked with Andreas (the author of AngelScript), and so he started to use the SourceForge.net Compile Farm.
Except that the compile farm does not work for our purpose, Takeshi.
Well, you said "We presently don't have the possibility to compile or test anything for MacOS at all"
which isn't true: we can compile there.
As far as testing goes... I guess only automated unit testing (for both GUI and non-GUI code) can be used.
The chance to being able to compile on a remote MacOS anyday should not be underappreciated.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: tiwag on August 03, 2006, 11:24:45 am
isn't it possible to install a Mac OS X  on a VMware.
if i would have an OS X i could test this.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: takeshimiya on August 03, 2006, 11:32:45 am
isn't it possible to install a Mac OS X  on a VMware.
if i would have an OS X i could test this.

It is possible, but not legal  :)
It is even possible to dual boot in any x86 with SSE2/SSE3, but it's not legal either.  :P

In any case, for educational purposes, you can read more at the "OSx86 Project Wiki".
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: thomas on August 03, 2006, 11:38:17 am
isn't it possible to install a Mac OS X  on a VMware.
if i would have an OS X i could test this.
I guess that would be:
Custom --> Other --> Other 64-Bit Unknown  :lol:

Apart from being unsure if it would work at all, the problem is where to get Mac OS X from (legally). The Darwin kernel may be one thing, but I think the bit that's called "Mac OS" is really pretty darn proprietary.
I've read that there are "hacks" to make Mac OS work on normal PCs, too (but I did not find anything really useful). Also, I strongly believe that applying such a hack is still considered vile illegal even if you own a legal copy of Mac OS.

If there is a way to get Mac OS X legally installed in a normal partition on a normal 64-bit PC, then please point me to it, I'll do it tomorrow.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: takeshimiya on August 03, 2006, 12:00:31 pm
If there is a way to get Mac OS X legally installed in a normal partition on a normal 64-bit PC, then please point me to it, I'll do it tomorrow.
There is a way to get Mac OS X installed in a normal partition on a normal Athlon 64, with the MacOSX 10.4 kernel (not the opensource one, darwin).
I can confirm everything works like a charm (I have seen that configuration in person). :)

The problem? It is not legal, at least yet.
For a great debate about this read here:
http://www.osx86project.org/index.php?option=com_content&task=view&id=222&Itemid=2

Even dual-booting with Windows and Linux at the same time works perfectly.
In any case for anyone wanting to learn more, they have all the info you may need at their Wiki.


Just something to note: the other way around it's perfectly legal, meaning, if you own an iMac, and a copy of Windows, you can multi-boot MacOSX, Windows, Linux, BSD, etc. and it's completely legal. :)
http://www.apple.com/macosx/bootcamp/
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on August 07, 2006, 11:25:53 pm
Pecan,

Now I'm back from vacation.
Here is the reference to the bootstrap file:

http://www.savefile.com/files/4010034

Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: bnilsson on August 07, 2006, 11:31:33 pm
Pecan,

savefiles seems to have a problem, so I try an attachment again.



[attachment deleted by admin]
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: Pecan on August 09, 2006, 05:20:02 pm
Pecan,

savefiles seems to have a problem, so I try an attachment again.


Re: http://forums.codeblocks.org/index.php?topic=3562.msg28385#msg28385 (http://forums.codeblocks.org/index.php?topic=3562.msg28385#msg28385)
I'm sorry to say I don't understand autotools and have been unsuccessful using them. Maybe someone more knowledgable can help.
Title: Re: When will we get Code::Blocks for Mac OS X?
Post by: afb on August 23, 2006, 04:21:10 pm
A new Mac binary for 10.3/PPC has been posted on BerliOS.
Updating the wiki info, and building a Universal Binary too.