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)
[/list]
- 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)
I'm not sure I understand, can't the Darwin Ports compiled version be packaged as a "double-click" application bundle?
sudo port mpkg wxMac
sudo port pkg codeblocks
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?
As long as the wxMac version is broken, it is good to have.Yes
Kinda like OpenOffice.org, if you know what I mean... :-)
There is no conflict, this just adds a third fourth option.Yes,
You should end up with the exact same as port install ?
Just without all the waiting for the compile to finish first...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.
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:This Intel bug is gone in wx 2.7.x, by the way.
-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
If it's not only theory, then :DQuoteit'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.
Me too, but these are much easier to maintain (once setup).
In theory I can even have them run off a nightly cron job...
Understood, "all the deps takes time" is for that; I see the point in this case, and also there will not be much releases of this meta package as the dependencies will not change too often. :)QuoteI see the point of having wxMac.mpkg because Darwin, err MacPorts is source-based, and compiling all the deps takes time.
The "mpkg" was because it held all those "pkg" inside of it.
So it was wxMac, and *every* little requirement for it too...
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.
Note that I'm talking about *_mac.cbp being included in svnQuote-maintain officially the .cbp's in svn (Pecan?)
Haven't tried the offical .cbp, but I probably should.
Understood, "all the deps takes time" is for that; I see the point in this case, and also there will not be much releases of this meta package as the dependencies will not change too often. :)
I think they want a stable-quality release (more or less),
This is why it is probably better of as a separate package, as it saves bandwidth and disk space.Yes, that's better in the packages case
I think DP also does it as separate x86/ppc builds ?Please educate me, DP/MP is not only a source-based repository (as in gentoo) and Fink, a binary-based (as in debian binaries)?
For the "nightly build", it will bundle everything every time and do a universal build with both arches. It's the Apple way :-) (bandwidth and disk are cheap)Yes :lol:
I guess renaming the Beta as "1.0" is better for marketing ?Yes it's just a matter of names and it pays very important in marketing. 8)
It seems to have worked for Mac OS X 10.0, for instance... :-)
Well, whatever works for them... wx 2.7 and wx 2.8 are the
same API and generation anyway, so it's just a matter of names.
I think DP also does it as separate x86/ppc builds ?Please educate me, DP/MP is not only a source-based repository (as in gentoo) and Fink, a binary-based (as in debian binaries)?
I'm new to this
Well, whatever works for them... wx 2.7 and wx 2.8 are theYes it's just a matter of names and it pays very important in marketing.
same API and generation anyway, so it's just a matter of names.
Just look around this very forum and search for "we better wait for 2.8 stable releases" in the case of wx, or in the case of C::B itself look for "has development of C::B died?", "I'm using RC2".
These are examples that people, most of the time no matter what, looks first for the latest stable release, be it wx 2.8, CB RC2, or any other piece of software.
/Applications/DarwinPorts/CodeBlocks.command