suggesstions for eclipse build process

[Christian Lynbech]

Here follows a patch with a proposal for some changes to how eclipse
is built and installed.

The background is that I want to use eclipse as my window manager and
I therefore would like a bigger separation between the building of
eclipse and its installation and subsequent use. I have more than once
killed off my window manager by forgetting about these issues and made
an absentminded clean in the build directory, which I feel is not
desirable.

The patch models things as I like it, but this may of course not match
well into how others use eclipse. This should be seen as a proposal
pointing out the direction I suggest we move in, not as the final word
on how this can be. I will also be happy to work other things into the
proposal if need be. I have only really tested this with the mode
where you generate an image to install.

The patch does not cover the `configure' file since this is just
generated from `configure.in' but I have attached the one that
autoconf generates on my system.

I think the patch should be pretty starightforward but do not hesitate
to ask if you do not understand what is going on or what I was
thinking when I wrote this or that peice of it.

There are (at least) two non-essential things in the patch. 

In `system.lisp' I have changed the require from :clx to :cmucl-clx as
the CLX package is named on a debian system. If :clx is widely used as
well, it probably should remain as it is.

As for the installation, I have added a copying of the lisp binary
into the installation directory as well. Since we have a full
standalone core (if that is what you choose) one should not be
dependant on the lisp installation of the system. This bit whe I
upgraded CMUCL on my system and I could no longer run eclipse because
the core was generated under a different version than the lisp
executable. But I will understand if somebody thinks this to be
slightly controversial (with ACL you would probably want to use
`generate-application' which does essentially the same).

The configure script has been changed a bit wrt options. Rather than
having --enable-compile-into-core do everything including decide the
installatiion place for the core file, there is now a number of
options dealing with this:

The option --enable-compile-into-core now only determines whether or
not we to produce a core file. The --with-core option is renamed to
--with-initcore to underline what it does and there is to new options,
--with-corename and --with-coredest, which separates the determination
of the name of the core file and where it is to be installed
(defaulting to eclipse.core and ${libdir} respectively).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-building
Type: application/octet-stream
Size: 10277 bytes
Desc: patches to eclipse build process
URL: <https://mailman.common-lisp.net/pipermail/eclipse-devel/attachments/20030210/7601b1ad/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure
Type: application/octet-stream
Size: 36386 bytes
Desc: sample generation of configure script
URL: <https://mailman.common-lisp.net/pipermail/eclipse-devel/attachments/20030210/7601b1ad/attachment-0001.obj>
-------------- next part --------------


------------------------+-----------------------------------------------------
Christian Lynbech       | email: christian at defun.dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic at hal.com (Michael A. Petonic)