[Gs-devel] Re: dev tools for the mac port? (fwd)

[Ralph Giles]

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
other words?

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
> >under?
> 
> 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 
> mid-October.

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

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

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

 -r