[Color Computer] Re: [Coco] C-Cubed

Lothan lothan at newsguy.com
Sun Jul 24 06:02:53 EDT 2005


I agree, which is why I included the alternative solution of putting the
logic into make instead of in the C executive. In this way, make determines
what needs to be done and it knows whether to hand the file to a local
processor or to the server processor. As you say, source file in and either
.a or .o file out. I think putting the logic in the C executive makes the
process more of a burden than it could be.

> -----Original Message-----
> From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com]
> On Behalf Of John R. Hogerhuis
> Sent: Saturday, July 23, 2005 3:06 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: RE: [Color Computer] Re: [Coco] C-Cubed
> 
> On Sat, 2005-07-23 at 14:36 -0700, Lothan wrote:
> > I think this could work, but it won't be as simple as posting a file and
> > retrieving the binary (e.g. the HTTP POST/GET model). In order for make
> > files to work, the server should accept the make file as input followed
> by
> > requests of each source and library file required to build the project.
> 
> Why complicate it? Part of the compile is on the local machine and part
> is on the server. The preprocessing happens on the local machine, so you
> really are just handing preprocessed C code them over to the server,
> along with any precompiler binary modules, and getting back .o files.
> 
> For example, GCC doesn't have 'make' built into it, why would the
> server-side of the compilation need it?
> 
> -- John.
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco






More information about the Coco mailing list