#1 make clean & config.cache; multiple plat

open
nobody
None
1
2001-09-17
2001-03-13
No

An email discussion, the main thing is what Mike says
at the end:

What *definitely* would be worthwhile would be to
specify separate installation directories for the
platform-dependent and for the
platform-independent parts of scsh, and to omit
installing the platform-independent stuff.

-bri

From: Steven Jenkins <sjenkins@ms.com>
To: shriram@cs.rice.edu
Cc: scsh-bugs@martigny.ai.mit.edu
Subject: Re: make clean & config.cache; multiple
platform support
Date: Tue, 18 Mar 1997 17:24:33 -0500

The answer, of course, is 'autoconf'. heh, heh.

There are some problems here: different platforms
will produce
different bin/scsh, include/scheme48.h, and lib
files. For example,
now that the prescheme compiler source is available,
I've built
a 64-bit image, which will mean that many of the above
will change.
Even with the 32-bit systems lib/scsh will change from
platform to
platform (I believe -- I know the C code is different,
and I think
many of the magic numbers also change, cf the
networking problems on
IRIX & Solaris).

So what you/we would really like is an install
script 'smart' enough
to put in blah/.platform trees, then do something
appropriate (as in AFS's
@sys mechanism) to resolve the platform dependencies,
figure it all out,
etc. Perhaps you (Shriram) or Olin should get a
summer undergrad to do
it as a summer project? (toss in a few buzzwords
like 'agent', 'distributed',
etc and it might even get funding)..sorry, couldn't
resist the jab. But
seriously, a re-write of autoconf (in scsh, of course)
to add the
smarts to do this would not be out of the question.
You would just need
to hammer out the specs you wanted:

1) Make the 'multiple platform installation' a
configure option
2) Make a ruleset for common vs platform specific files
3) Have 'shadow' dirs for each src tree
4) Have 'shadow' dirs for what is not shared
5) Have some sanity-checking script make sure you
somehow resolve the
shadows to your 'real' directory. eg, in AFS, you
might have

src -> .src/@sys
where @sys is handled by AFS. Under non-AFS,
though...well, that's why
you pay a summer student to hammer it out :)
One 'obvious' mechanism
would be the configure script itself -- look at the
config.sub script
for ideas, or the wrapper script for mzscheme from PLT
at Rice.

>Also, perhaps I'm just using the configuration and
installation
>process poorly, but is there a better way of settings
things up for
>multiple platforms? I ran
>
> ./configure --prefix=/home/shriram/.Packages/scsh \ > --exec-
prefix=/home/shriram/.Packages/scsh/.bin/sparc-solaris
>
>
> ./configure --prefix=/home/shriram/.Packages/scsh \ > --exec-
prefix=/home/shriram/.Packages/scsh/.bin/i386-freebsd
>
>and ended up with
>
>- bin/scsh files which were indeed different;
>- identical include/scheme48.h files, but I'm willing
to concede these
> could be distinct, so they should be kept separate;
>- a bunch of stuff in lib/scsh/, of which:
> - cig/, libscshvm.a, scsh.image, scshvm need to be
different;
> - everything else looks completely identical.
>
>In short, there's a lot of duplicated stuff here.
Maybe I'm just not
>configuring properly. Could you include instructions
in the
>distribution to help with this? The generic GNU
INSTALL file falls a
>bit short of what one would hope for.
>
>Thanks for Scsh!
>
>Keepin' the faith,
>'shriram

Steven L. Jenkins

From: Assar Westerlund <assar@sics.se>
Sender: assar@sics.se
To: shriram@cs.rice.edu
Cc: scsh-bugs@martigny.ai.mit.edu
Subject: Re: make clean & config.cache; multiple
platform support
Date: 19 Mar 1997 01:21:31 +0100

Shriram Krishnamurthi <shriram@cs.rice.edu> writes:
> > You should be able to build in two different
directories from the same
> > source directory, but I haven't tried it lately.
>
> I didn't say you couldn't. I was complaining about
duplicates in the
> material that gets installed. It is indeed possible
to build on
> different platforms -- as my message said, I
succeeded in doing so.

Yes, but building in different directories solves the
problem of
removing (or not) `config.cache'.

According to the GNU standards (the only standard that
I know of
regarding this stuff), `make clean' should not remove
config.cache,
but `make distclean' should.

Regarding sharing of common files between different
architectures, I
think that we should move the architecture-independent
files from
`lib' to `share' and only let `bin' and `lib' be
architecture-dependent. The only remaining question
is `include'?

/assar

From: sperber@informatik.uni-tuebingen.de (Michael
Sperber [Mr. Preprocessor])
Sender: sperber@informatik.uni-tuebingen.de
To: scsh@martigny.ai.mit.edu
Subject: Re: make clean & config.cache; multiple
platform support
Date: 20 Mar 1997 11:55:49 +0100

>>>>> "Steven" == Steven Jenkins <sjenkins@ms.com>
writes:

Steven> [ ... ]

Steven> So what you/we would really like is an install
script 'smart' enough
Steven> to put in blah/.platform trees, then do
something appropriate (as in AF\ S's
Steven> @sys mechanism) to resolve the platform
dependencies, figure it all out\ ,
Steven> etc.

I personally think that multi-platform installation is
something that
should be addressed outside of a specific software
package.
Multi-platform software installations (i.e.
collections of software
packages) are typically large, so you probably want to
address this
problem uniformly across packages. So I'm not so sure
this project is
worthwhile until a more general solution across
packages is in place.

AFS's @sys does *not* handle the issue well, since it
does not model
upwards/downwards compatibility. (I.e. you install
something under
SunOS under /afs/.../@sys with compiled-in paths.
Running it under
Solaris doesn't work anymore because the meaning of
@sys has changed.)
We had to abandon using @sys completely because of
that.

We have a more flexible scheme in place which works
independently of
installation specifics of a particular package.
(Running under AFS,
but actually completely independent of it.) I'll be
happy to describe
it if anyone's interested.

What *definitely* would be worthwhile would be to
specify separate
installation directories for the platform-dependent
and for the
platform-independent parts of scsh, and to omit
installing the
platform-independent stuff.

Cheers =8-} Mike

Discussion

    • labels: 314687 -->
    • assigned_to: sperber --> nobody
     
  • Logged In: YES
    user_id=17553

    This is not a bug but a feature request.