Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
DarwinPorts Packages (Mac OS X)
afb:
Once things stabilize, we'll be able to build nightly for DarwinPorts
and then package it up as a single .pkg installer for the end user...
This will not replace the current "double-click" application bundle,
but will be an easy way to try Code::Blocks under wxMac/wxGTK:
There will be four .dmg disk images with Installer.app packages:
* wxMac.mpkg (including all of the requirement packages)
* codeblocks+macosx.pkg (Code::Blocks for Mac OS X/Carbon)
* wxGTK.mpkg (including all of the requirement packages)
* codeblocks+puredarwin.pkg (Code::Blocks for Darwin/X11)
Probably not all will be binary, but the source code will be there.
(three major os/arch targets: Panther PPC, Tiger PPC, Tiger X86)
Not that building from the command-line is hard, but it is scary: :-)
sudo port install codeblocks (but compilation does take a while)
See the Wiki for details...
takeshimiya:
--- Quote from: afb on November 01, 2006, 10:16:05 am ---There will be four .dmg disk images with Installer.app packages:
* wxMac.mpkg (including all of the requirement packages)
* codeblocks+macosx.pkg (Code::Blocks for Mac OS X/Carbon)
* wxGTK.mpkg (including all of the requirement packages)
* codeblocks+puredarwin.pkg (Code::Blocks for Darwin/X11)[/list]
Probably not all will be binary, but the source code will be there.
(three major os/arch targets: Panther PPC, Tiger PPC, Tiger X86)
--- End quote ---
I'm not sure I understand, can't the Darwin Ports compiled version be packaged as a "double-click" application bundle?
I personally don't like installers of any kind, but if this is going to be source-only I see some advantage, although I find "sudo port install codeblocks" easier for compiling it; as if something goes wrong (as usually) I don't think you can type and fix things inside the Installer.
Also I don't think anyone will be interested (except for curiosity, or maybe C::B developers) in the wxGTK version.
In short, I find the easiest ways to use C::B are:
- Nightly/Weekly builds in a dmg, of wxMac/Carbon, Universal builds of course, with wxWidgets and all deps bundled.
Intended for users.
- sudo port install codeblocks.
Intended for developers, bleeding edge users, and contributors.
- svn update & compile C::B from .cbp projects.
Same as above.
What do you think?
afb:
--- Quote from: takeshi miya on November 01, 2006, 10:36:56 am ---I'm not sure I understand, can't the Darwin Ports compiled version be packaged as a "double-click" application bundle?
--- End quote ---
Yes, and that is exactly what I did :-)
--- Code: ---sudo port mpkg wxMac
sudo port pkg codeblocks
--- End code ---
--- Quote ---I personally don't like installers of any kind, but if this is going to be source-only I see some advantage, although I find "sudo port install codeblocks" easier for compiling it; as if something goes wrong (as usually) I don't think you can type and fix things inside the Installer.
--- End quote ---
Just think of it as "ports" vs "packages", to borrow some terms from FreeBSD.
It is also possible to package up as RPM and use Yum, but that's just too weird...
--- Quote ---Also I don't think anyone will be interested (except for curiosity, or maybe C::B developers) in the wxGTK version.
--- End quote ---
As long as the wxMac version is broken, it is good to have.
Kinda like OpenOffice.org, if you know what I mean... :-)
--- Quote ---In short, I find the easiest ways to use C::B are:
- Nightly/Weekly builds in a dmg, of wxMac/Carbon, Universal builds of course, with wxWidgets and all deps bundled.
Intended for users.
- sudo port install codeblocks.
Intended for developers, bleeding edge users, and contributors.
- svn update & compile C::B from .cbp projects.
Same as above.
What do you think?
--- End quote ---
There is no conflict, this just adds a third/fourth option.
You should end up with the exact same as port install ?
Just without all the waiting for the compile to finish first...
edit: There's also always the painful / "from scratch" method:
- svn update & compile C::B from Terminal
takeshimiya:
--- Quote from: afb on November 01, 2006, 10:42:03 am ---As long as the wxMac version is broken, it is good to have.
Kinda like OpenOffice.org, if you know what I mean... :-)
--- End quote ---
Yes
--- Quote from: afb on November 01, 2006, 10:42:03 am ---There is no conflict, this just adds a third fourth option.
You should end up with the exact same as port install ?
--- End quote ---
Yes,
--- Quote from: afb on November 01, 2006, 10:42:03 am ---Just without all the waiting for the compile to finish first...
--- End quote ---
it's just that I see little point on it (no problem if you have time to mantain), because I either use a binary (dmg bundle), or I compile at hand CB.
I see the point of having wxMac.mpkg because Darwin, err MacPorts is source-based, and compiling all the deps takes time.
On the codeblocks+macosx.pkg not, because most C::B devs would rather prefer to use the project files to compile it itself.
I think this can wait, as other things have more priority:
-make wxExecute work on Carbon/Intel,
-make C::B compile with 2.7.x, a long list of bugs have been fixed (and Mac is top priority for 2.8 too, because of the apple's inclusion of wx in Leopard)
-maintain officially the .cbp's in svn (Pecan?)
-apply the mac-related patches that aren't still applied if any
afb:
--- Quote ---it's just that I see little point on it (no problem if you have time to mantain), because I either use a binary (dmg bundle), or I compile at hand CB.
--- End quote ---
Me too, but these are much easier to maintain (once setup).
In theory I can even have them run off a nightly cron job...
--- Quote ---I see the point of having wxMac.mpkg because Darwin, err MacPorts is source-based, and compiling all the deps takes time.
--- End quote ---
The "mpkg" was because it held all those "pkg" inside of it.
So it was wxMac, and *every* little requirement for it too...
--- Quote ---On the codeblocks+macosx.pkg not, because most C::B devs would rather prefer to use the project files to compile it itself.
--- End quote ---
This is the one thing I have left to try myself, actually.
--- Quote ---I think this can wait, as other things have more priority:
-make wxExecute work on Carbon/Intel,
--- End quote ---
This Intel bug is gone in wx 2.7.x, by the way.
--- Quote ----make C::B compile with 2.7.x, a long list of bugs have been fixed (and Mac is top priority for 2.8 too, because of the apple's inclusion of wx in Leopard)
--- End quote ---
I still don't know why they are rushing wx 2.8 out, rather than have Apple use wx 2.7 for Leopard just like they used wx 2.5 for Tiger. But that's just me.
--- Quote ----maintain officially the .cbp's in svn (Pecan?)
--- End quote ---
Haven't tried the offical .cbp, but I probably should.
--- Quote ----apply the mac-related patches that aren't still applied if any
--- End quote ---
This is one is probably mine... (most of the patches are)
Navigation
[0] Message Index
[#] Next page
Go to full version