[Gs-devel] Re: dev tools for the mac port? (fwd)
giles at a3a32260.sympatico.bconnected.net
Fri Sep 29 17:35:02 PDT 2000
forwarded for the benifit of the archives.
---------- Forwarded message ----------
Date: Fri, 29 Sep 2000 17:30:33 -0700 (PDT)
From: Ralph Giles <giles at snow.ashlu.bc.ca>
To: Bernd Heller <mac-gs at aladdin.com>
Cc: Jeff Schindall <jschin at bellatlantic.net>
Subject: Re: dev tools for the mac port?
On Sat, 30 Sep 2000, Bernd Heller wrote:
> Yes, as CodeWarrior is not able to handle make files, and the
> ghostscript make files are quite complex.
> This is the only solution if you don't want to drop the original
> ghostscript makefiles, which would be a bad idea I think.
Well, I want to dump them in favor of autoconf/make on the unix side, and
MSVC doesn't support them either afaik, but I see your point.
> Unix side? Well, you can compile a carbon binary with MacOS X using
> any combination of the classic tools like make and the new Apple
> development tools, but it will not run under classic MacOS. This will
> be possible in future versions of the development tools however.
> CodeWarrior can compile carbon for classic MacOS already, but I don't
> think it is able to work together with any shell tools.
> If you are thinking about compiling from Linux or Solaris, I don't
> know if this is possible, I am not much into cross-platform
> compiling, but I guess it is not easy.
> So it would be possible to do all development in MacOS X, but it
> requires the use of carbon which raises the minimum system
> requirements to MacOS 8.1 (and PowerPC I think).
Ah, ok. Maybe I've misunderstood something: I understood carbon to be a
normalized subset of the traditional toolbox; is it possible to write an
app within that subset and compile it against the classic toolbox instead
of carbonlib? Have flexible source with a number of build options, in
Cross-platform compilation is nothing magic; IMO it's only hard because
it's an uncommon setup. gcc can certainly produce the code, but we'd need
a linker that runs on *nix which can generate MacOS executables, and
access to the headers and stub libraries to link against. It looks like
there's enough documentation to write such a thing if apple doesn't
release it, but I'm not sure it's worth going there.
Does 'gcc -o foo foo.c -lcarbon' work on MacOS X?
> >On Sun, 24 Sep 2000, jeff schindall wrote:
> >> Bernd is correct, MPW is used solely to process the makefiles. There
> >> are no Mac sources in CVS.
> >> >I can only talk for myself, but I will try to help wherever I can.
> >> >However, I have to admit that I am currently more interested in
> >> >finishing my MacGSView and porting it to MacOS X. I also want to put
> >> >together a ghostscript framework for MacOS X which enables Cocoa
> >> >apps to use gs very easily.
> >Would you like to move the MacOS port into cvs? What license is MacGSView
> I think we should really do. But it will take some time as both of us
> are very busy at the moment. Jeff is not available at all until
Ok, that sounds good. The important thing for me is to have the code all
in one place.
> Perhaps I am not understanding what you are planning, but it sounds
> like all the viewer apps have to give up their current UI to a
> certain degree, and this is not acceptable, especially as I think
> that the Mac port's UI is the most beautiful and user friendly.
> I think it is a much better idea to work on the gsdll interface,
> which lacks some features at the moment, but could export all
> functionality a viewer needs. But it has to be up to the viewer app
> how it uses and presents the functionality. Please correct me if I am
Your second idea is what we were planning. A library or component you
could feed a ps/pdf stream to and have it feed back a rendered image or
(maybe) a series of native drawing commands. The UI would be a distinct
part controlling the process and could present whatever it wanted to the
user. This includes the command-line interface you get on the unix
> P.S. Your mailer renamed me from Bernd Heller to Ben Halle (first
> line), you have a very enthusiastic spelling checker ;-)
Ouch, sorry. That was my bad memory, instead!
More information about the gs-devel