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]

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)

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]

I'm not sure I understand, can't the Darwin Ports compiled version be packaged as a "double-click" application bundle?

Yes, and that is exactly what I did :-)

Code

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.

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...

Also I don't think anyone will be interested (except for curiosity, or maybe C::B developers) in the wxGTK version.

As long as the wxMac version is broken, it is good to have.
Kinda like OpenOffice.org, if you know what I mean... :-)

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?

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]

As long as the wxMac version is broken, it is good to have.
Kinda like OpenOffice.org, if you know what I mean... :-)

Yes

There is no conflict, this just adds a third fourth option.
You should end up with the exact same as port install ?

Yes,

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.

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]

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.

Me too, but these are much easier to maintain (once setup).
In theory I can even have them run off a nightly cron job...

I 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...

On the codeblocks+macosx.pkg not, because most C::B devs would rather prefer to use the project files to compile it itself.

This is the one thing I have left to try myself, actually.

I think this can wait, as other things have more priority:
-make wxExecute work on Carbon/Intel,

This Intel bug is gone in wx 2.7.x, by the way.

-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)

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.

-maintain officially the .cbp's in svn (Pecan?)

Haven't tried the offical .cbp, but I probably should.

-apply the mac-related patches that aren't still applied if any

This is one is probably mine... (most of the patches are)

[takeshimiya]

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.

Me too, but these are much easier to maintain (once setup).
In theory I can even have them run off a nightly cron job...

If it's not only theory, then

I 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...

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 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.

I think they want a stable-quality release (more or less),

"the pick-up date for Apple will be about Nov 13th, so that should be a
2.8 RC, counting back I'd welcome 10 days for bug fixing, so for me
Friday 3rd would be the latest day for spinning a 2.7.X, otherwise I
don't think I can have the quality we'd need

Thanks,
Stefan"

-maintain officially the .cbp's in svn (Pecan?)

Haven't tried the offical .cbp, but I probably should.

Note that I'm talking about *_mac.cbp being included in svn

[afb]

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.

This is why it is probably better of as a separate package, as it saves bandwidth and disk space. I think DP also does it as separate x86/ppc builds ?

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)

I think they want a stable-quality release (more or less),

I guess renaming the Beta as "1.0" is better for marketing ?
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.

[takeshimiya]

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)?
I'm new to this

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 ?
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.

Yes it's just a matter of names and it pays very important in marketing.
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, Mac OS X 10.0, or any other piece of software.

[afb]

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

It is, similar to Gentoo and FreeBSD Ports. I just meant that I don't think they support building "fat" binaries yet, but that you can only build for either architecture (x86 or ppc)

For the actual Portfile, I think the MacPorts reorganization seems to have killed most of the development... I got tired of waiting, so I set up my local build area instead.  :-x

If and when they get their act together again, it might go into the main repository.

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.

Yes it's just a matter of names and it pays very important in marketing.

But it doesn't matter on the technical level. Having an official
binary distribution of wxWidgets is much more useful to me
than having a "2.8.0" release - so I did a framework/package...

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.

I am one of those. I like releases, whether alpha, beta or RC or final...

I think that Code::Blocks should release something some day soon.

[afb]

The new codeblocks for wxGTK features a startup script,
that will start up X11.app and then launch Code::Blocks.

Code

/Applications/DarwinPorts/CodeBlocks.command

This will make it more similar to the wxMac version...
(i.e. you have something to double-click to launch it)