[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: compiler h include read bug after si::save-system

From: Camm Maguire
Subject: [Gcl-devel] Re: compiler h include read bug after si::save-system
Date: 06 Nov 2005 21:20:36 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


You are absolutely right that the -Isystem-dir../h is unnecessary when
using the *cmpinclude-string*.  The issue is that at present, GCL can
compile in two slightly different C formats, governed by the ;system-p
switch.  when this is set, and external cmpinclude.h file must be
found, init filenames are unique, and the data (appended to the .o
file) is output in human readable form as opposed to the faster 'fasd'
and smaller form.  I left the -I in in all cases as I thought it did
no harm when :system-p was not set -- is this not true?

In any case, there is absolutely no reason that I can see why these
three features must be tied together thus.  Init names should probably
be unique at all times, though it makes for a very long function
identifier. Likewise, fasd format should be on by default and turned
off with the compiler::*fasd-data* variable.  And external
cmpinclude.h file references should be toggled by (let
((compiler::*cmpinclude-string* nil)) ...)

One issue is that now there are three (at least) externally shiped
programs using the :system-p flag for 1) building on machines without
native object relocation, and 2) profiling.  I believe all that is
needed for these functions is the unique init name, yet I'm a little
hesitant to mess with this too much as it took a lot of effort to get
here.  I'm likely being too timid -- I'll see if I can get this done
as it really should work.  We can toggle th -I with the
*cmpinclude-string* if you think that would be good, though I don't
see why it causes any problems.

There are a few other annoyances in this regard.  gcltksrv,
gcl_coolectfn.o, etc. all are referred to via *system-directory*.
There are ways around these as well, just nees a bit of thought.  How
would you integrate portability with autoloading?  pargcl and xgcl are
in the queue in regard to the latter.

Take care,

Robert Boyer <address@hidden> writes:

> >From time to time, people have wished for the portability of their GCL save
> images.
> I realize that this is bit much to ask for in view of varying c compilers,
> operating system releases, etc.  But I think that there may be some confusion
> in the current implementation that is blocking some minimal portability in
> some cases.
> The problem that I wish to point to is the use of si::*system-directory* in
> the function compile::compiler-command.  Isn't the whole point of
> *cmpinclude-string* that it provides the necessary, huge include string?  So
> why does the compiler-command still have a -Isystem-dir../h when
> *cmpinclude-string* is a string?
> Or to put it in prosaic terms, when I do an si::save-system and give the
> resulting image to another user, I would hope that image would suffice for
> him to get some computing done, but it does not if compiling is going to
> happen.  If he does a compile-file, he still must have access to the original
> system-directory, the h file has still got to be there, and it has got to be
> readable by him.  Which creates a potential for very annoying, and I think
> unnecessary, access/protection problems.  Back in Interlisp-10 days, we used
> to ship saved images around to various Tenex systems without any trouble at
> all.  In fact, the standard for normal distribution of Interlisp-10 among
> Tenex users on the ARPANET was just one single, giant executable file.  Boy
> was that nice and convenient!  The shift to shipping around multiple files,
> even two, is a nightmare and a pitfall for the ignoramus.
> I realize that this must be a very touchy issue, performance wise.  Writing
> out the giant include string just might be a terrible waste of time most of
> the time.  What to do?  One possibility is to give si::save-system some sort
> of argument, or establish some variable that can be set, so that images made
> in certain conditions do the time-consuming printing out of the h file,
> whereas others just point gcc to the existing file.
> Thanks,
> Bob

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]