macports and Xcode

Emmanuel Hainry milosh at macports.org
Sat Oct 11 05:50:00 PDT 2008


Citando Jay Levitt :
> Anders F Björklund wrote:
> > nox wrote:
> > 
> >>> One reason could be to keep MacPorts fully "self-contained",
> >>> and to cut down on the amount of "outside" dependencies... ?
> >>> Currently there is a big grey zone of what's ok to use from
> >>> system (GCC, X11, etc) and what is not (Perl, Python, etc)
> > 
> >> I really don't want to have to build or use a bootstrapped GCC, X11  
> >> and all to have a self-contained
> >> MacPorts installation.
> > 
> > Right, and some people don't want to build or use a bootstrapped
> > Perl or Python or Ruby (or even Apache or MySQL or PHP packages)

Yep, having debian's and macports python and perl seems superfluous to
me. (substitute debian by apple for most of you, and add pkgsrc, fink or
portage for some of you).

> > 
> > So it's all about trade-offs... But I agree with you, and the only
> > reason I could see for bootstrapping cctools/gcc or Xquartz would
> > be to make sure that it builds from the available open source code
> > instead of just using the binaries. Otherwise not worth the hassle.
> 
> Another factor (though I think we're just discussing philosphy, not 
> immediate plans): Every port maintainer and core developer uses Xcode. 

Such a statement had to have an exception: I no longer use Xcode as my
powerbook is now dead. I use the build tools provided by my linux
distribution. Note that it becomes difficult as MacPorts trunk believes
I don't have gcc installed just because my gcc is not the same version
as Apple's.

> We already see lots of problems when a package doesn't work on 10.5
> because the port maintainer didn't upgrade - or when it stops working
> on 10.4 because he did.

We see lots of problems caused by users who don't follow the
installation instructions...

And those problems would be solved if macports did not rely on third
party tools (gcc, tcl, x11 which have or have had bugs in the past and
apple's versions are not without those bugs).
 
> Adding a new build system, if it ever becomes a Good Idea, ought to be 
> coupled with some type of continuous-integration "build farm" so that 
> platform-specific bugs don't get (further) introduced.

The build-farm is, I hope still, on macports' todo list. As are binary
packages. The gcc ports are available, but a burden to build. So it may
become possible in a not so far future.


Emmanuel


More information about the macports-users mailing list