Hi,
On Sat, Apr 23, 2005 at 02:26:41PM +0200, Michael Sperber wrote:
> Lionel Elie Mamane <lionel@mamane.lu> writes:
>> We are encountering a problem in permitting scheme48 and scsh to be
>> installed at the same time on a machine.
>> The problem is the file /usr/include/scheme48.h, that both programs
>> install. This precludes multiple versions of scheme48 (where scsh
>> counts as a version of scheme48) to be installed at the same
>> time. We propose that you rename that file to a name containing the
>> scheme48 version (such as /usr/include/scheme48-1.3/scheme48.h and
>> /usr/include/scsh-0.6/scheme48.h), so that multiple versions can be
>> installed at the same time.
> I'm not sure I understand the problem correctly---different Unices
> (and different installations of the same Unix) habitually use
> different layout conventions for their software installations. I'm
> reluctant to prescribe a specific convention for Scheme 48 across
> installations.
There has been, I think, a misunderstanding. I'll try to explain
better.
As I understand things, different Unices have different path lists for
C include files, and different rules about what C headers go to which
path in the list, but the filename _after_ the standard path is
application-defined.
In GNU-configure terms, the system sets "includedir" to something the
C preprocessor will look in. For BSDs /usr/local/include, for Debian
(packages) /usr/include/, etc.
But the library being installed decides the filename that gets
appended to the value of $includedir; for the case of s48, it
currently decides to put a file "scheme48.h" there. It thus specifies
that C libraries/programs that make use of these facilities will have
a line stating:
#include <scheme48.h>
What we were suggesting was that it instead decides to put a file
"scheme48-1.3/scheme48.h" there, and thus specify that C programs
making use of the facilities will have a line stating:
#include <scheme48-1.3/scheme48.h>
Another naming scheme could be "scheme48-1.3.h" and thus
#include <scheme48-1.3.h>
We prefer the former scheme because then the version one compiles
against can be chosen by compile-time flags (-I/foo/bar/scheme48-1.3)
rather than by changing all source files.
(All names above obviously must be generalised by replacing "1.3" by
$CURRENT_SCSH_VERSION.)
This permits multiple versions of scheme48 to be installed at the same
time (where, for this purposes, scsh is a version of scheme48) and
coexist peacefully.
We were not at all suggesting you stop being "free choice of
includedir agnostic", i.e. we were not at all suggesting you prescribe
a particular choice for $includedir. You _already_ prescribe what
comes after the $includedir, we were suggesting a change in this
prescription.
> The Debian choice of putting files in certain locations is by nature
> a decision local to Debian---in what kind of context would it render
> Debian "incompatible" with other Unices?
Compilation under Debian of the same programs would need additional
(-I for gcc) flags to the compiler, in the best case.
> One obvious problem we currently have is that Scheme 48 is no
> portable way to grok the locations of the header file for use in
> Makefiles or whatever to build external libraries.
In our idea, programs that are meant for a specific version of
scheme48 would "declare" that version by the filename they include,
either in the "#include" line, or in their build system as a C
preprocessor flag (-I for gcc). Maybe that's too conservative? Maybe
then the version string in the filename could be a "API versioning"
with no coupling to the "s48 release version", e.g. something you
would increment everytime source-level compatibility is broken - just
like the soname of a library is incremented everytime _binary_
compatibility is broken.
> But possibly I just don't see the problem clearly yet---maybe you
> could elaborate if that's the case.
Did I make myself clear? I'm sometimes a bit difficult to understand :-|
--
Lionel
|