Release now?

Release now?

[Mikael Djurfeldt]

When Rob has added the GMP support there's only the signal handling
left of the major changes intended for the 1.8 release, right?

I think it would be a good idea to aim for release of 1.8 after these
two components have been added.  This since people have asked for
shorter intervals between releases.

What do you say?

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Dale P. Smith]

On Mon, 24 Feb 2003 13:37:33 +0100
Mikael Djurfeldt <mdj@kvast.blakulla.net> wrote:

> When Rob has added the GMP support there's only the signal handling
> left of the major changes intended for the 1.8 release, right?
> 
> I think it would be a good idea to aim for release of 1.8 after these
> two components have been added.  This since people have asked for
> shorter intervals between releases.
> 
> What do you say?

Well!

1.6.3 isn't in Debian unstable yet.  Doesn't 1.8 remove the gh_*
interface?  Shouldn't there be some time for extension and application
writers to move to 1.6 before 1.8?

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x239               |


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Mikael Djurfeldt]

"Dale P. Smith" <dsmith@altustech.com> writes:

> Doesn't 1.8 remove the gh_* interface?

I propose that it doesn't do more than what has been achieved after
the GMP and signal handling has been added.  The major additions will
then be: GMP, POSIX threads and resizing hash tables.

> Shouldn't there be some time for extension and application writers
> to move to 1.6 before 1.8?

If we release 1.8 now, the non-deprecated API will have had only
cosmetic changes, so it wouldn't be a significant extra burden for
those who have adapted to the non-deprecated API of 1.6.

Besides, the signal handling will likely take some time to complete.
If we then initiate the release process, chances are that the release
won't happen until summer, so 1.6 will have at least half a year of
"life".  So, "now" means "in half a year".  But if we don't start to
plan for it now, it will be longer...

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

I'm all for shorter intervals between releases, but it would be good
to make sure that packages expecting 1.6 can work with 1.8 (modulo
insisting on a specific version when it isn't necessary, which is easy
to patch).  It sounds like this is indeed the case.

The 1.4->1.6 transition has been awkward - NetBSD pkgsrc now has a
'guile14' pkg installed in /usr/pkg/guile/1.4/ as well guile (1.6)
installed in /usr/pkg.  Unless one can say there is absolutely no good
reason for a program to need an older version, it has to be doable for
a package system to support both.  And supporting both means having
both fully installed so you can link against either - not just run old
binaries.  NetBSD seems to have achieved this with the dual-prefix
approach and the buildlink2 scheme (which tightly controls a pkg's
build environment).

IMHO, the dual-prefix approach points out that depending on
LD_LIBRARY_PATH is potentially troublesome.  This works out ok with -R
on NetBSD:

fnord gdt 35 ~ > ldd /usr/pkg/guile/1.4/bin/guile
/usr/pkg/guile/1.4/bin/guile:
         -lltdl.3 => /usr/pkg/lib/libltdl.so.3
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lguile.10 => /usr/pkg/guile/1.4/lib/libguile.so.10
         -lc.12 => /usr/lib/libc.so.12

fnord gdt 36 ~ > ldd /usr/pkg/bin/guile
/usr/pkg/bin/guile:
         -lcrypt.0 => /usr/lib/libcrypt.so.0
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lguile-ltdl.1 => /usr/pkg/lib/libguile-ltdl.so.1
         -lguile.15 => /usr/pkg/lib/libguile.so.15
         -lc.12 => /usr/lib/libc.so.12

And, given that the libguilereadline lib has different names, readline
works on both guile versions.  So, I consider this a success story -
thanks to ebayasi, wiz and mycroft for working on NetBSD guile pkgsrc.

All that said, I'm hoping that NetBSD and others can just update the
1.6 version of guile to 1.8, and not have to have 1.6 installed under
/usr/pkg/guile/1.6.  It's really cool that guile is starting to be
included in more pkgsrc builds (e.g. gnumeric), where it had
previously been avoided!

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> When Rob has added the GMP support there's only the signal handling
> left of the major changes intended for the 1.8 release, right?

Well, the GMP support isn't in the tree yet.  I'm actually trying to
evaluate it and was planning to send a message to guile-devel about it
today.  Stay tuned.

Although I agree that shorter release periods might be a good idea,
I'd be more likely to shoot for say once or twice a year for major
releases unless we have good reason to do otherwise.  Of course I'm
not sure this contradicts what you're suggesting.

However I do feel that trying to release in the next month or two
would be a little early.  Guile 1.6 isn't even in Debian yet, although
I warned the other relevant maintainers last week that I'd be moving
it from the staging area to unstable at the start of this week
(i.e. I'll be uploading to unstable shortly).  Once it does go into
unstable, if history is any guide, it'll still be a while before all
the relevant maintainers have even finished shifting over and
uploading new packages.  If we can afford it, I'd tend to argue in
favor of at least some period of stability, to let this version
"settle".

This concern by itself wouldn't necessarily be enough to argue in
favor of waiting a while, but I'd also like to wait until we get the
performance of 1.7 to be more comparable to 1.6.  I believe the recent
macro system cleanups have cost us quite a bit of performance, and
while I still think they're absolutely the right thing to do, I'd like
to get them completely finished (where do we stand?  do we still have
"execution-time" expansions?), and then work on performance a bit.
I've been spending quite a bit of time over the past few weeks trying
to figure out what possibilities might be available to us wrt to
performance going forward, once we have macroexpansion separated from
evaluation, including an interesting discussion with one of the gcc
maintainers :>

As an example of the performance issue, the following test just takes
400000 pre-generated random bignum pairs and applies a given operator
to each of the pairs, ignoring the result.  Note that this is a
quick-hack benchmark-wise, and so feel free to criticize it as such :>

  The core code:

    (define (bench-random-int-op op)
      (let loop ((x-vals random-x-values)
                 (y-vals random-y-values))
        (if (pair? x-vals)
            (begin
              (op (car x-vals)
                  (car y-vals))
              (loop (cdr x-vals)
                    (cdr y-vals))))))

  The results:

  $ ./run-benchmark guile-1.6 ./guile-1.7 foo.scm
  starting trials
  ("bench-random-op +" "guile-1.6" ((user . 199) (sys . 0) (gc . 89)))
  ("bench-random-op -" "guile-1.6" ((user . 178) (sys . 0) (gc . 57)))
  ("bench-random-op *" "guile-1.6" ((user . 220) (sys . 0) (gc . 101)))
  ("bench-random-op /" "guile-1.6" ((user . 264) (sys . 0) (gc . 118)))
  ("bench-random-op gcd" "guile-1.6" ((user . 123) (sys . 0) (gc . 43)))
  ("bench-random-op lcm" "guile-1.6" ((user . 278) (sys . 0) (gc . 119)))
  starting trials
  ("bench-random-op +" "./guile-1.7" ((user . 341) (sys . 1) (gc . 61)))
  ("bench-random-op -" "./guile-1.7" ((user . 315) (sys . 0) (gc . 60)))
  ("bench-random-op *" "./guile-1.7" ((user . 352) (sys . 0) (gc . 55)))
  ("bench-random-op /" "./guile-1.7" ((user . 382) (sys . 0) (gc . 54)))
  ("bench-random-op gcd" "./guile-1.7" ((user . 267) (sys . 0) (gc . 56)))
  ("bench-random-op lcm" "./guile-1.7" ((user . 374) (sys . 0) (gc . 54)))

Also, with respect to a comment you made to Dale later on:

> If we then initiate the release process, chances are that the
> release won't happen until summer, so 1.6 will have at least half a
> year of "life".  So, "now" means "in half a year".  But if we don't
> start to plan for it now, it will be longer...

Though I can definitely see why you'd be concerned about this, I'm
hoping to handle the next release somewhat differently than the last
one.  I believe I unintentionally branched too early last time, and
that contributed quite a bit to the delay.  This time I don't want to
branch until *much* later in the process.  I'd like for us to all work
to get things to a state where we think we're just about ready to
release and then branch.  I believe that will let us move much more
quickly.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Marius Vollmer]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> When Rob has added the GMP support there's only the signal handling
> left of the major changes intended for the 1.8 release, right?

There is also the issue of having good replacements for all of gh_.

Also, the deprecation mechanism should be made more user-oriented and
be controlled with a macro like _GNU_SOURCE.

Also also, I promised rms to keep backwards compatability for a long
time (and I do agree that it is important).  That means that the
things that are deprecated in 1.6 and have already been removed from
1.8 need to be added back.  I understand that this is an unwelcome
mass of uninteresting work and I'm willing to do it myself, of course,
eventually... :-/

> I think it would be a good idea to aim for release of 1.8 after these
> two components have been added.  This since people have asked for
> shorter intervals between releases.
> 
> What do you say?

We should first complete the points mentioned for 1.8 in tasks/TODO.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

> I'm all for shorter intervals between releases, but it would be good
> to make sure that packages expecting 1.6 can work with 1.8 (modulo
> insisting on a specific version when it isn't necessary, which is easy
> to patch).

Yes, we definitely need to be able to have two versions of Guile
installed with the same prefix and have them be usable for running
programs.  However, I don't think we need to make special arrangements
for being able to compile against two versions of Guile at the same
time.  Having to use different prefices for the two versions seems
acceptable to me.

Would pkg-config address this issue?  I.e. could one say `guile-config
--use-version 1.6 link` (or something similar) with the effect that
the right '-L' and '-R' options are spit out?


However, a more serious problem exists for external modules of Scheme
code that want to use a specific version of Guile.  For this, I think
we should add versions to our module system.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

For NetBSD pkgsrc, a normal case is for people to build everything
from source.  So it is necessary to have multiple versions installed
such that someone could compile against either, since some programs
(e.g Gnucash 1.6.8) require the old version of guile.  NetBSD pkgsrc
has solved this by putting one in a special prefix.

  Would pkg-config address this issue?  I.e. could one say `guile-config
  --use-version 1.6 link` (or something similar) with the effect that
  the right '-L' and '-R' options are spit out?

pkg-config might well be nice, and arguably guile should provide a
pkg-config file, even if we continue to have guile-config.  I am not
clear whether pkg-config is a 'gnome thing', and whether it is ok to
require people who want to link against gruile to install pkg-config.
I find it to be a solution to a general problem and not huge (gzipped
binary package < 50 KB on NetBSD/i386).

But, running 'pkg-config --use-version 1.6' should be no different
than guile16-config, except that it's easier to write configure.in
fragments.  It does mean we get to sidestep the issue about which
guile-config is 'primary' and which has a version number.  But I'm not
sure that's a huge issue - the latest can be primary and the others
have the number.

  However, a more serious problem exists for external modules of Scheme
  code that want to use a specific version of Guile.  For this, I think
  we should add versions to our module system.

The NetBSD pkgsrc approach means that when one compiles guile-gtk, for
instance, one could put the 1.4-linked version in /usr/pkg/guile/1.4
and the 1.6 version in /usr/pkg.  Do you really mean pure Scheme code,
or stuff with dynlibs?  I would think that pure Scheme code could
feature-test and cope - is this really an issue?  (I have not heard of
gnucash having problems with this.)

But, this all points out the really serious extended consequences of
not maintaining _compile-time_ backwards compatibility.  I'm not
(personally) at all worried about running old binaries with newer
guile libraries.  The issue is whether programs that compile against
guile can just work when the system's base guile version is upgraded.
We've seen a lot of pain (and non-upgrading of guile in major
distributions) recently.

So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good,
and there probably needs to be some schedule for removing deprecated
features.  Something like 1-2 years after 75% of some set of
distributions have 1.6 in their base pkg/ports/rpm/deb system, perhaps
with some survey of the guile-using packages.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Andreas Rottmann]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> I'm all for shorter intervals between releases, but it would be good
>> to make sure that packages expecting 1.6 can work with 1.8 (modulo
>> insisting on a specific version when it isn't necessary, which is easy
>> to patch).
>
> Yes, we definitely need to be able to have two versions of Guile
> installed with the same prefix and have them be usable for running
> programs.  However, I don't think we need to make special arrangements
> for being able to compile against two versions of Guile at the same
> time.  Having to use different prefices for the two versions seems
> acceptable to me.
>
> Would pkg-config address this issue?  I.e. could one say `guile-config
> --use-version 1.6 link` (or something similar) with the effect that
> the right '-L' and '-R' options are spit out?
>
If you talk of pkg-config[0], you could easily have this by simply
installing two .pc files (named for example, guile-1.6.pc and
guile-1.8.pc) in $(prefix)/lib/pkgconfig. You'd then call `pkg-config
--libs guile-1.6' to get the right -L and -R options...

Regards, Andy

[0] http://www.freedesktop.org/software/pkgconfig/
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> But, running 'pkg-config --use-version 1.6' should be no different
> than guile16-config, except that it's easier to write configure.in
> fragments.  It does mean we get to sidestep the issue about which
> guile-config is 'primary' and which has a version number.  But I'm
> not sure that's a huge issue - the latest can be primary and the
> others have the number.

Or you can do something like Debian's update-alternatives -- have a
priority system, but allow for the local maintainer to override...

FWIW, as far as I can tell, the only way we can allow compilation for
multiple versions of guile is if we don't put the libs into /usr/lib
with the other libraries.  Either that, or we have to put our major
version number into the library name.

In fact we wouldn't be able to put *any* libguile.so into /usr/lib,
otherwise *any* other package's foo-config script that put a
-L/usr/lib on the gcc command line could cause us to get the wrong
one, even if the gcc command line also contained the output of an
invocation of guile-X.Y-config somewhere.

Another consideration (and perhaps everyone is still aware of) is that
of -rpath.  There are many who are opposed to it, and without it, you
don't really have any way to put guile's libs anywhere but /usr/lib or
similar...

Hmm, now that I think about it, I wonder if systems could handle just
having the .so links off in a subdir, i.e. put libguile.so in
/usr/lib/guile/VERSION, but put the actual libguile libs in /usr/lib.
This might avoid the need for an -rpath, LD_LIBRARY_PATH, or any
changes to ld.so.conf, but still allow specifying a particular guile
with -L/usr/lib/guile/VERSION.  Hmm...  Thoughts?

> The NetBSD pkgsrc approach means that when one compiles guile-gtk,
> for instance, one could put the 1.4-linked version in
> /usr/pkg/guile/1.4 and the 1.6 version in /usr/pkg.  Do you really
> mean pure Scheme code, or stuff with dynlibs?  I would think that
> pure Scheme code could feature-test and cope - is this really an
> issue?

Personally I feel like it is.  To me it seems like just as much an
issue as it is for binary shared libraries.  A module presents an
interface, and that interface may change over time.  So the client
should have some way to ask for a particular "version" of that
interface i.e. (use-modules (postgresql-fancy #:interface 3)).  Of
course, others may differ and feel like we should just leave this up
to the author and client to come up with their own scheme,
i.e. checking version number, defined?, etc.  Though note that I'm not
sure we've settled the future of some of the features like defined?.

I'd tend to lean towards having a standard strategy like #:interface
or maybe #:version for people to use.  They can always ignore it and
invent their own custom strategies using (use-modules (foo)) if they
want.  I'm open to being convinced otherwise, though.

> But, this all points out the really serious extended consequences of
> not maintaining _compile-time_ backwards compatibility.  I'm not
> (personally) at all worried about running old binaries with newer
> guile libraries.  The issue is whether programs that compile against
> guile can just work when the system's base guile version is
> upgraded.

Perhaps I'm misunderstanding.  If the soname hasn't changed, then you
should be fine.  If it has, then you have to recompile...  Also,
unless we can *prove* that nothing has changed in a way that would
break backward compatibility, we have to change the soname with each
major release.

Also I guess we need to be clear what the C lib sonames mean.  Do they
also reflect the indirect "API" available from ice-9 via scm_c_eval?
For example, if we had a function in ice-9 called (get-blarg) that
returned `(,foo . ,bar), and we change it so that it returns `(,bar
. ,foo), then do we have to change the libguile version number since
since C code could access this via scm_c_eval?  Perhaps, perhaps not,
but I think we should figure this out and make a clear statement in
the docs.

> We've seen a lot of pain (and non-upgrading of guile in major
> distributions) recently.

As far as I can tell, this is always going to be true to some extent,
though we should do our best to minimize it.  I've seen it happen for
perl and python regularly, and I'd expect our situation to be worse
(and it is) because of our unique requirement that users be able to
link directly to our libraries from C, and that of course leads to
libs linked to libs linked to guile and the whole "indirect linkage to
two versions of libguile" problem.

> So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good,

If you mean drop-in as in "just requires a recompile of things linked
against it", then I suspect that's quite possible.  If you mean
"doesn't even require recompile", then I at least somewhat doubt it.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

  I'd tend to lean towards having a standard strategy like #:interface
  or maybe #:version for people to use.  They can always ignore it and
  invent their own custom strategies using (use-modules (foo)) if they
  want.  I'm open to being convinced otherwise, though.

This makes sense.  But, I'd lean hard to trying not to change such
interfaces by adding new names and deprecating old procedures over time.
Also, I'm not sure this is causing us pain, and I somewhat lean in the
direction of only favoring complex mechanisms to avoid actual or
near-term expected pain.

  FWIW, as far as I can tell, the only way we can allow compilation for
  multiple versions of guile is if we don't put the libs into /usr/lib
  with the other libraries.  Either that, or we have to put our major
  version number into the library name.

NetBSD's buildlink2 mechanism conses up a special tree to use for
builds, and only puts the libs that are needed there.  I don't know
how this works for locating the right stuff at run-time, but it does
rely heavily on -rpath.

  In fact we wouldn't be able to put *any* libguile.so into /usr/lib,
  otherwise *any* other package's foo-config script that put a
  -L/usr/lib on the gcc command line could cause us to get the wrong
  one, even if the gcc command line also contained the output of an
  invocation of guile-X.Y-config somewhere.

I think this is a general problem of needing the specific -L/-R before
the general locations.

  Another consideration (and perhaps everyone is still aware of) is that
  of -rpath.  There are many who are opposed to it, and without it, you
  don't really have any way to put guile's libs anywhere but /usr/lib or
  similar...

If someone is unwilling to use -rpath and unwilling to use
LD_LIBRARY_PATH, then yes, guile's libs need to be in /usr/lib.  guile
can be built with --prefix=/usr, so this is supported.  This makes it
hard to have two versions unless all libs have versions in the names.
I'm not sure how hard it would be to make /usr/lib/libguile16.so.15
and /usr/lib/libguile14.so.10 instead - and I'm not sure what it would
hurt.  (An example is glib 1.2 and 2.0.)

  Perhaps I'm misunderstanding.  If the soname hasn't changed, then you
  should be fine.  If it has, then you have to recompile...  Also,
  unless we can *prove* that nothing has changed in a way that would
  break backward compatibility, we have to change the soname with each
  major release.

I would advocate bumping the .so # when there is a known incompatible
change, but I see the playing it safe path as reasonable too.

But I wasn't talking about this - I meant compatibility at the
source/build level, not dynamically linking the new .so into an old
binary.  The real pain has happened because one couldn't in general
take a program that built against guile 1.4 and just replace guile
with 1.6 and rebuild it from scratch.  Gnucash 1.6.8 is specified to
only work with 1.4, for example.  If everything could be built against
1.6, even if it did have to be recompiled (e.g. some functions are now
macros that invoke compatibility calls) that would mean everything
needed to be rebuilt, but that's just cpu time, not package pain, at
least in the NetBSD pkgsrc view.  One would just to to
/usr/pkgsrc/lang/guile and type 'make update', and it would
recursively delete and rebuild all that depended on guile.  But
because some programs can't (or are thought not to be able) to build
with new guile, it was necessary to simultaneously support both.

  Also I guess we need to be clear what the C lib sonames mean.  Do they
  also reflect the indirect "API" available from ice-9 via scm_c_eval?
  For example, if we had a function in ice-9 called (get-blarg) that
  returned `(,foo . ,bar), and we change it so that it returns `(,bar
  . ,foo), then do we have to change the libguile version number since
  since C code could access this via scm_c_eval?  Perhaps, perhaps not,
  but I think we should figure this out and make a clear statement in
  the docs.

A very good point.  If we don't take the more strict view, then there
needs to be an interface version accessible via a standard  API.

Or, perhaps we need to say "Don't do that."  Add a new call, and then
deprecate the old one, but don't change documented behavior lightly.

  As far as I can tell, this is always going to be true to some extent,
  though we should do our best to minimize it.  I've seen it happen for
  perl and python regularly, and I'd expect our situation to be worse
  (and it is) because of our unique requirement that users be able to
  link directly to our libraries from C, and that of course leads to
  libs linked to libs linked to guile and the whole "indirect linkage to
  two versions of libguile" problem.
                 
  > So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good,

  If you mean drop-in as in "just requires a recompile of things linked
  against it", then I suspect that's quite possible.  If you mean
  "doesn't even require recompile", then I at least somewhat doubt it.

I meant just requiring a recompile.  But, if the old so is present,
with a different major verison, the old stuff should continue to work.

Thanks for thinking about this - I think it is critical to promoting
guile acceptance and use.

    Greg Troxel <gdt@ir.bbn.com>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> This makes sense.  But, I'd lean hard to trying not to change such
> interfaces by adding new names and deprecating old procedures over time.
> Also, I'm not sure this is causing us pain, and I somewhat lean in the
> direction of only favoring complex mechanisms to avoid actual or
> near-term expected pain.

I think I tend to look at it as setting up infrastructure now that
encourages people to do things that may save anguish later, but I can
also see your point.

Though I did have the semi-amusing idea of trying to make guile nearly
all modules (which I think I've mentioned before), i.e.

  #!/usr/bin/guile-strap -s \
  !#
  (use-modules (ice-9 core #:interface 6))
  ...

I think it's probably simpler and more obviously useful to just
standardize our naming convention.  I'm inclined to change the
unstable tree to install guile as guile-X.Y from now on, along with
all the other tools, and have an easily bypassable inst-hook (or
similar) that sets up the default links:

  cd ${bindir} && ln -sf guile-X.Y guile

I might also try to make another install target that didn't set up the
links, perhaps "make install-no-convenience-links" or whatever.

This would allow people to reliably start writing #!/usr/bin/guile-1.6
scripts, or maybe more portably

  #!/bin/sh
  exec guile-1.6 "$@"

> If someone is unwilling to use -rpath and unwilling to use
> LD_LIBRARY_PATH, then yes, guile's libs need to be in /usr/lib.  guile
> can be built with --prefix=/usr, so this is supported.  This makes it
> hard to have two versions unless all libs have versions in the names.
> I'm not sure how hard it would be to make /usr/lib/libguile16.so.15
> and /usr/lib/libguile14.so.10 instead - and I'm not sure what it would
> hurt.  (An example is glib 1.2 and 2.0.)

What do you think about my other suggestion?  i.e.

  - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir})
  - put the libguile.so development symlinks (i.e. the ones -l uses)
    in /usr/lib/guile/VERSION
  - put the headers in /usr/include/guile/VERSION
  - require the use of guile-config and arrange for guile-config to
    spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION
    when appropriate

So far this seems to me like it might solve the "allow multiple
development versions to be installed" problem without requiring
-rpath, LD_LIBRARY_PATH, or ld.so.conf modifications, but I haven't
been thinking about it for long yet.  If this *would* work, I can
implement it in CVS, and adjust Debian accordingly...

Basically gcc -lguile would find the libguile.so in
/usr/lib/guile/VERSION/ via the -L argument from guile-X.Y-config, and
would use that to embed the right SONAME into the app or lib being
built.  Then at runtime, the linker would find the newest suitable
version, say libguile.so.12.0.1 in /usr/lib/.

> But I wasn't talking about this - I meant compatibility at the
> source/build level, not dynamically linking the new .so into an old
> binary.  The real pain has happened because one couldn't in general
> take a program that built against guile 1.4 and just replace guile
> with 1.6 and rebuild it from scratch.

I won't argue that the 1.4 -> 1.6 transition was possibly somewhat
jarring.  While I still feel like many of those changes were
worthwhile and will serve us well going forward, I think that we're
likely to do that less often going forward.  As Marius has mentioned,
we'll be restoring a number of things in CVS that had already been
removed in preparation for 1.8.

> Thanks for thinking about this - I think it is critical to promoting
> guile acceptance and use.

You and I both :>

Though guile's particular objectives do provide some fairly
"challenging" constraints on the possible solutions.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

   What do you think about my other suggestion?  i.e.

     - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir})
     - put the libguile.so development symlinks (i.e. the ones -l uses)
       in /usr/lib/guile/VERSION
     - put the headers in /usr/include/guile/VERSION
     - require the use of guile-config and arrange for guile-config to
       spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION
       when appropriate

I suppose /usr/share/guile/VERSION already exists, and /usr/bin/guile
(and guile-config) can be named with versions as well.

It strikes me as inelegant to link against a library in one place and
then expect ld.so to find it someplace else.
I think your plan is workable, but in my view the 'put the other
version in a different prefix' plan feels cleaner.  But, it requires
rpath or DT_RPATH, which seems to be ok in most places except debian.
(It is certainly heavily used in NetBSD, which puts third party stuff
in /usr/pkg and does not have /usr/pkg/lib in the default search path.)

At this point, for NetBSD I'm happy with NetBSD's current solution.  I
would be perfectly content for your plan to be a ./configure-time
option, as it seems to be among the best suggestions to date for a
no-rpath environment.  I suppose if guile-config/pkg-config spits out
the right -I and -L paths then this would be ok for other systems.
But having a library compile-linked from one place and run-linked from
another seems to be asking for trouble, and I would prefer not to see
that complexity and associated unintended consequences imposed on
everyone because Debian chooses not to use -rpath.  (I realize libtool
does this for running uninstalled code, but I think that's different.)

All that said, I have to ask myself: what's wrong with putting
the guile version number in the soname and all other files,
glib-style?  This makes names bigger, but seems less likely to create
hard-to-find bugs.  This could also be a ./configure-time option,
perhaps used only when installing a secondary version.  Or, on systems
that say dependency libs have to be updateable without reinstalling
dependent programs, this should perhaps be used all the time.

In December you wrote to debian-devel:

  One solution might be to just require all guile add-on libs to be
  placed in /usr/lib/guile/X.Y and then require the use of -rpath or
  similar, but I suspect that's a non-starter.  Another might be to make
  it guile policy to encode the name of the guile version into the lib
  name, i.e. libguile1.6-gwrap-glib, but that's pretty ugly and it's not
  very scalable.

I think it is important to keep separate notions of scalability
imposed by such a naming scheme and the scalability of the underlying
reality.  Here, the reality is messy, and the naming scheme means that
various combinations can coexist peacefully.  It enables having 12
versions at once, but that is the underlying reality, unless some are
prohibited.  Of course, not having a mechanism has the effect of
prohibiting this.

  Why wouldn't such a rationale also justify
  libguile1.6-gwrap-glib1.2-crypt1-c6,so?

It justifies only libguile1.6-gwrap-glib1.2.  The key point that I've
been trying to get across (which our discussion has clarified in my
mind) is that there are two separate kinds of version changes.  One is
the traditional shlib major version bump.  But generally, that merely
means programs must recompile, and make an occasional small change.
The other kind is that interfaces have changed so significantly that
it isn't reasonable to tell people "Just recompile and fix your
program.  From now on only the new version is available and if you
can't cope you are just going to lose."

The "just cope" is what happens when libc has a major version change.
The work to cope is not too bad, and it isn't viewed as reasonable to
provide a way around it.  I'm hoping that guile 1.6->1.8 will be like
this.

Other changes, like glib 1.2 to 2.0, are so far reaching that the
maintainers feel the need to support having them both installed.  Part
of the reality is that the more important a library is, the more
effort the library can impose on users with changes.  With guile, we
want people to use guile more than they feel the need, so the amount
of pain we can impose is small.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

pkg-config support for guile

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

Here is a patch against guile-1.6.1 to add pkg-config support.  This
is noninvasive - it doesn't require pkg-config to be installed to
build guile, or even to run the autogen.sh.  pkg-config haters, should
there be any, will just see a small turd in
$(prefix)/lib/pkgconfig/guile.pc.  The file won't be useful without
pkg-config installed, of course, but this gives users a choice of
configuration means.

I have not tested building programs using pkgconfig instead of
guile-config, but they give almost the same output (pkgconfig moves
all the -L to the front, and allows one to ask for -L separate from -l).

        Greg Troxel <gdt@ir.bbn.com>


[-- Attachment #2: pkgconfig support for guile 1.6 --]
[-- Type: text/plain, Size: 1631 bytes --]

Index: Makefile.am
===================================================================
RCS file: /QUIST-CVS/guile/Makefile.am,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 Makefile.am
--- Makefile.am	2002/12/07 22:41:28	1.1.1.3
+++ Makefile.am	2003/02/27 14:36:25
@@ -29,7 +29,7 @@
 include_HEADERS = libguile.h
 
 EXTRA_DIST = HACKING GUILE-VERSION ANON-CVS SNAPSHOTS \
-	     $(ACLOCAL) BUGS README-PACKAGING
+	     $(ACLOCAL) BUGS README-PACKAGING guile.pc.in
 
 TESTS = check-guile
 
@@ -37,5 +37,8 @@
 
 # The rule will cd to $(top_srcdir).
 ACLOCAL = ./guile-aclocal.sh
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = guile.pc
 
 # Makefile.am ends here
Index: configure.in
===================================================================
RCS file: /QUIST-CVS/guile/configure.in,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 configure.in
--- configure.in	2002/12/08 01:48:52	1.1.1.3
+++ configure.in	2003/02/27 14:37:37
@@ -745,6 +745,8 @@
 AC_CONFIG_FILES([libguile/guile-snarf-docs],
                 [chmod +x libguile/guile-snarf-docs])
 
+AC_CONFIG_FILES([guile.pc])
+
 AC_OUTPUT
 
 dnl Local Variables:
Index: guile.pc.in
===================================================================
RCS file: guile.pc.in
diff -N guile.pc.in
--- /dev/null	Thu Feb 27 03:35:16 2003
+++ guile.pc.in	Thu Feb 27 09:37:37 2003
@@ -0,0 +1,12 @@
+# pkgconfig file for guile
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: guile
+Version: 1.6
+Description: guile extension language
+Requires:
+Libs: -L${libdir} -lguile -lguile-ltdl @LDFLAGS@ @LIBS@
+Cflags: -I${includedir}

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> But having a library compile-linked from one place and run-linked from
> another seems to be asking for trouble, and I would prefer not to see
> that complexity and associated unintended consequences imposed on
> everyone because Debian chooses not to use -rpath.  (I realize libtool
> does this for running uninstalled code, but I think that's different.)

I'm somewhat tempted to try it in HEAD, and then get as many people as
possible to attempt a build/install.  If it works on a bunch of
platforms, and if we can't think of any reason why it shouldn't work
in general, this might be a way to have one approach that works
everywhere.

> I think it is important to keep separate notions of scalability
> imposed by such a naming scheme and the scalability of the
> underlying reality.  Here, the reality is messy, and the naming
> scheme means that various combinations can coexist peacefully.  It
> enables having 12 versions at once, but that is the underlying
> reality, unless some are prohibited.  Of course, not having a
> mechanism has the effect of prohibiting this.

To me, it seems like the -L/usr/lib/guile/VERSION solution would allow
the same result, but without the library naming issues.  You'd have:

  /usr/lib/libguile.so.9*
  /usr/lib/libguile.so.12*
  /usr/lib/libguile.so.14*

  /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1
  /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4
  /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2

Just to be sure I understand, is your objection to this primarily a
concern with it being an untested approach?  I just want to make sure
we're on the same page.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

  To me, it seems like the -L/usr/lib/guile/VERSION solution would allow
  the same result, but without the library naming issues.  You'd have:

    /usr/lib/libguile.so.9*
    /usr/lib/libguile.so.12*
    /usr/lib/libguile.so.14*

    /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1
    /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4
    /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2

  Just to be sure I understand, is your objection to this primarily a
  concern with it being an untested approach?  I just want to make sure
  we're on the same page.

No, we're not.  My objection, deep down, is a philosophical discomfort
with linking against a library in one place and expecting the run-time
linker to find it someplace else.  This just seems to be Wrong and
tempting fate.  Maybe I just need to get over this - it is probably a
remnant from early exposure to systems that stored the whole path, or
SunOS where -R was the default automatically from -L.

I think I also have an objection to doing things to accomodate people
who refuse to use -rpath, since to me the resulting pseudo-requirement
to put all libraries in /usr/lib (or use LD_LIBRARY_PATH) is totally
unreasonable.

Your proposal does seem likely to impose fairly little pain and save a
lot.  I would like to make sure that one can have different pkg-config
files and select the right one, since IMHO pkg-config will replace
guile-config eventually.

There is a large transition question, though - guile 1.6 already has
libraries in a particular place.  For 1.8 to have a new place is
probably fine, but this would be disruptive to those who have already
found a satisfactory solution.  Hence my notion of having the
version-named midfix be optional, so Debian can use it and NetBSD can
keep using separate prefixes.

Also, we might consider having a different prefix rather than a
'midfix', which seems awkward.  With /usr/lib/guile/1.4, guile/1.4
gets appended to $(libdir).  The alternative of /usr/guile/1.4/lib,
where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me.

This latter scheme is in fact what NetBSD does, except that -rpath is
used to find the libguile.so at run time from /usr/pkg/guile/1.4/lib,
and it isn't present in /usr/lib/libguile.so.

So, setting the prefix, and some optional glue code to symlink in the
libs (and guile-config with versions) to the 'real' $(prefix)/lib
would probably buy us the best of both worlds.  And, there would be a
harmonized solution between NetBSD and Debian, modulo the 'use -R
v.s. make symlinks in /usr/lib' difference.  To me, that bodes well
for it working elsewhere.

(With 20/20 hindsight, guile really should have got this right long
ago, but I didn't contribute code/solution then, so I have no
absolutely no right to complain.)

Summarizing:

  If the installed locations of guile 1.6 changes, I object because it
  will cause work for people who have already coped.

  I prefer the different prefix rather than a midfix.  A configure
  option to add a midfix seems ok, but given that we already have
  --prefix, it seems like more work.

  If the default behavior includes either midfixes or extra symlinks,
  I object, because it is imposing what some may view as uncleanliness
  on everyone because some decline to use -R.

  Differing prefixes and a ./configure option to symlink into another
  prefix is a clean solution which can be used in varying
  environments, enabling each to win while preserving their sense of
  the right way to do things.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> There is a large transition question, though - guile 1.6 already has
> libraries in a particular place.  For 1.8 to have a new place is
> probably fine, but this would be disruptive to those who have already
> found a satisfactory solution.  Hence my notion of having the
> version-named midfix be optional, so Debian can use it and NetBSD can
> keep using separate prefixes.

Though at least for end-users compiling using guile-config, I'd hope
the transition would be rather painless.

> Also, we might consider having a different prefix rather than a
> 'midfix', which seems awkward.  With /usr/lib/guile/1.4, guile/1.4
> gets appended to $(libdir).  The alternative of /usr/guile/1.4/lib,
> where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me.

I don't really think that's feasible, at least not as the default.  At
least for most of the linux distributions (and I'd guess solaris,
etc.) that would be in contravention of the FHS (and predecessors),
and I would guess also the LSB.

> Summarizing:
>
>   If the installed locations of guile 1.6 changes, I object because it
>   will cause work for people who have already coped.

Hmm, but I'm only talking about changing the location of one file (a
symlink) on the lib side, per library, i.e. libguile.so, which would
affect packagers, but shouldn't affect anyone using guile-config.

Also we're going to *have* to change the install location of the
headers, i.e. /usr/include/guile/VERSION/, at least for normal
autoconf style installs, i.e. FHS compliant installs since using
/usr/include/libguile.h doesn't allow multiple dev versions to be
installed.

>   I prefer the different prefix rather than a midfix.  A configure
>   option to add a midfix seems ok, but given that we already have
>   --prefix, it seems like more work.

I don't really think this is likely to be acceptable as a default.  If
you've ever seen the mass objections from *many* unix camps to
attempts to violate the FHS-style /usr/lib/*, /usr/include/* approach,
you know what I mean.  I can understand -- there are good reasons for
many of the choices made in the FHS.

That doesn't mean we shouldn't have a way to support other
approaches.  In gnucash we had --enable-opt-style-install.  I don't
think I'd want to name the option that now, but it arranged for things
to be /etc/gnucash/blarg by default, but to be able to be
/opt/gnucash/etc/blarg when requested.  It was somewhat a pain to
arrange and maintain, but it can be done.

>   If the default behavior includes either midfixes or extra symlinks,
>   I object, because it is imposing what some may view as uncleanliness
>   on everyone because some decline to use -R.

I think we may just have to agree to disagree here.  From the user's
perspective, the -L approach should be transparent, and from anyone
else's perspective, it should be trivial to either support a
--configure option that changes that default, or just let them "mv
guilelibdir/* libdir/" in whatever build/install script/infrastructure
they're using.  Or we could possibly have an option.

If what you're arguing for is in fact an "opt-style" install, then
that's fine, but I think it'll have to be something that can be
enabled rather than the default since it's my impression that FHS
style layouts are the definite majority.

>   Differing prefixes and a ./configure option to symlink into another
>   prefix is a clean solution

I think maybe I still don't have a good impression of what you're
preferred solution is (and that's likely my fault) -- I'm not sure
what the "prefixes" are here.

Overall, I still feel like the changes I've proposed are a fairly
small alteration to the current strategy, and seem to be likely to
work everywhere.  That's what's driving my immediate inclination.

And although we may want to do it anyway, having more than one
strategy, especially if they're significantly different, does increase
the support burden both on the coding side, and on the end-user side.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

>   /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1
>   /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4
>   /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2

Ahh, the potential fatal flaw -- where to the *.la libraries go, and
how does this strategy affect the current ltdl?  My guess is that
until we get versioning for ltdl and so can have

  /usr/lib/libguile-foo-bar.la.2.4.1

so that ltdl can find the right one, we may not be able to use the
strategy for the .so's above...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

>   /usr/lib/libguile-foo-bar.la.2.4.1
>
> so that ltdl can find the right one, we may not be able to use the
> strategy for the .so's above...

Though thinking further, maybe this is only a problem for libguile,
and people are a lot less likely to want to dynamic-link specific
versions of that, though that doesn't mean they'll never need to.

Putting the guile version in the lib name would fix that too, but I
think there's still a reasonably strong sentiment against
libguile-12-gwrap-glib-2-gl-3-whatever-4.

I guess the right way to start is still probably to see if we can fix
libtool and/or libguile-ltdl, and if so, that'll change the range of
available options...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

  Though at least for end-users compiling using guile-config, I'd hope
  the transition would be rather painless.

I think I'm almost convinced (and almost is enough) that's true.

  I don't really think that's feasible, at least not as the default.  At
  least for most of the linux distributions (and I'd guess solaris,
  etc.) that would be in contravention of the FHS (and predecessors),
  and I would guess also the LSB.

I just went and read parts of FHS, so I see your point on this.
That said, GNU software supports letting the user choose the prefix,
and we shouldn't lose that, but if our interpretion of where things
belong under the prefix includes versioned subdirs that's OK.

  Also we're going to *have* to change the install location of the
  headers, i.e. /usr/include/guile/VERSION/, at least for normal
  autoconf style installs, i.e. FHS compliant installs since using
  /usr/include/libguile.h doesn't allow multiple dev versions to be
  installed.

Either that or multiple prefixes, and I see that multiple prefixes are
frowned upon by the FHS.  Since there is no proposal on the table to
remove the ability to use --prefix, that's not an issue.

  If what you're arguing for is in fact an "opt-style" install, then
  that's fine, but I think it'll have to be something that can be
  enabled rather than the default since it's my impression that FHS
  style layouts are the definite majority.

I was asking for the current bebavior to be preserved unless someone
asks for --version-dirs, which would put things in /usr/lib/guile/1.x
instead of /usr/lib (and similarly for /usr/share, etc.).  But I guess
that really isn't necessary, as long as guile-config-using software
can just rebuild and run.  So I withdraw this objection.

  I think maybe I still don't have a good impression of what you're
  preferred solution is (and that's likely my fault) -- I'm not sure
  what the "prefixes" are here.

I meant:
guile14-src $ ./configure --prefix=/usr/pkg/guile/1.4
guile16-src $ ./configure --prefix=/usr/pkg/guile/1.6
guile18-src $ ./configure --prefix=/usr/pkg/guile/1.8
or perhaps one of them being the 'primary' and installed in /usr/pkg
directly.  But I see how this violate FHS and how people might not
like it.  And I  realize it causes problems in a rpath-prohibited
environment.

  Overall, I still feel like the changes I've proposed are a fairly
  small alteration to the current strategy, and seem to be likely to
  work everywhere.  That's what's driving my immediate inclination.

I may be overestimating their impact.  Perhaps if you wrote down
precisely what files would get installed in different places, and what
extra symlinks would be made (and under what circumstances) this would
all be clearer.  I just looked through what is in the 1.6 pkg, and see
a bunch of things.  I'll list them and annotate with what I think you
are proposing.  Except that I don't get what you mean for libs, so I
listed what came to me as I was doing this exercise.

Then, it would be good to understand the ripple effects on e.g. having
guile-gtk for two guile versions installed - can that just adopt the
same scheme?

bin/guile
bin/guile-snarf
bin/guile-config
bin/guile-tools
  put in bin/guile/X.Y, and symlink one to bin/guile
  presumably  the "I want the symlink in the standard place" is a
  configure option, so it can be assigned to the package denoted as
  primary by the package system maintainer.  Use --primary-symlinks as
  the configure option, perhaps.

include/libguile/__scm.h
[...]
include/guile/gh.h
include/guile/srfi/srfi-4.h
include/guile/srfi/srfi-13.h
include/guile/srfi/srfi-14.h
include/guile-readline/readline.h
include/libguile.h
  put in include/guile/X.Y/{libguile/*,guile/*,libguile.h}, with no symlinks.
  people should be using guile-config/pkgconfig, so there is no need
  to have anything work  unless the appropiate
  -I/usr/include/guile/1.4 is given.

info/guile.info
info/guile.info-1
[...]
  put in info/guile/X.Y/*, with symlinks from info if the
  --primary-symlinks option was given.  This makes them all available
  and the primary obtained by default.

lib/libguile.a
lib/libguile.la
lib/libguile.so
lib/libguile.so.15
lib/libguile.so.15.0
lib/libguile-ltdl.a
lib/libguile-ltdl.la
lib/libguile-ltdl.so
lib/libguile-ltdl.so.1
lib/libguile-ltdl.so.1.0
lib/libguilereadline-v-12.a
lib/libguilereadline-v-12.la
lib/libguilereadline-v-12.so
lib/libguilereadline-v-12.so.15
lib/libguilereadline-v-12.so.15.0
lib/libguile-srfi-srfi-4-v-1.a
lib/libguile-srfi-srfi-4-v-1.la
lib/libguile-srfi-srfi-4-v-1.so
lib/libguile-srfi-srfi-4-v-1.so.1
lib/libguile-srfi-srfi-4-v-1.so.1.0
lib/libguile-srfi-srfi-13-14-v-1.a
lib/libguile-srfi-srfi-13-14-v-1.la
lib/libguile-srfi-srfi-13-14-v-1.so
lib/libguile-srfi-srfi-13-14-v-1.so.1
lib/libguile-srfi-srfi-13-14-v-1.so.1.0
  put in lib/guile/X.Y
  symlinks for libguile.so.15/15.0 and other libs into lib/
  symlinks for libguile.a/libguile.la (?) if --primary-symlinks
  never a symlink in lib for libguile.so itself

  err, now I realize this isn't what you mean.  I think you have
  proposed putting the .sos with versions in $(prefix)/lib, and
  symlinks for libguile.so in the special link-time-only lib.  But I
  don't understand where the .a and .la versions go - is the
  /usr/lib/guile/X.Y scheme primary, or not?  With include files, it
  is primary, and it's only an accident of so naming that they don't
  collide for some cases.

  how about /usr/lib has no guile files, unless
  --lib-symlinks
  is given?  Then the rpath users will have a clean separation, and
  those without rpath can pick up libguile.so.{9,10,15} from /usr/lib.

share/aclocal/guile.m4
  put in share/guile/1.4/aclocal/guile.m4
  symlink in share/aclocal if --primary-symlinks

share/guile/1.6/oop/goops/active-slot.scm
[...]
  already versioned.  No changes needed.


So I realize now that I don't understand what you propose in terms of
moving libraries.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

  Putting the guile version in the lib name would fix that too, but I
  think there's still a reasonably strong sentiment against
  libguile-12-gwrap-glib-2-gl-3-whatever-4.

But is the sentiment well founded?  We've gone down the path of lib
symlinks, and it seems that it really is pretty hairy.

I hold up glib 1.2/2 as an example of a low-pain solution to what
would otherwise have been a very painful and chaotic transition.
Right now we are perhaps 0.2 to 0.3 of the way through it, and tons of
people have both versions - and both versions of dependent stuff like
ORBit - installed at the same time.  Over time more libraries will
move to the glib2 world, and programs as all the libraries are
available, and eventually people won't need glib 1.2.  Granted, this
is way more complicated than guile, but it's an excellent example of a
long chain of library dependencies when the base library has a major
change.  Granted, you can't do this often, and guile should try to do
it no more often than once every 5 years, but the coping mechanism
seems to work.

And I would suggest not keying on major numbers, but on compile time
changes, and thus the release numbers.  This only need be for when
'recompile everything' isn't a good answer.  libguile14 and libguile16
will be less confsing, IMHO.  Or does debian insist on upgrading a
package without upgrading things that depend on it?  If so, I think
one has to have a new package name that can coexist on every
incompatible change.  (NetBSD's make update does a pkg_delete -r and
then rebuilds all the depending packages.)


        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

>   Putting the guile version in the lib name would fix that too, but I
>   think there's still a reasonably strong sentiment against
>   libguile-12-gwrap-glib-2-gl-3-whatever-4.
>
> But is the sentiment well founded?  We've gone down the path of lib
> symlinks, and it seems that it really is pretty hairy.
>
> I hold up glib 1.2/2 as an example of a low-pain solution to what
> would otherwise have been a very painful and chaotic transition.

How do they handle it, and do they have the same dynamic-link issues?
Also, how do they handle the app1 -> libfoo -> libgtk, and app1 ->
libbar -> libbgtk with respect to upgrading, during the the period
when libfoo has been recompiled against the new libgtk, but libbar on
the system hasn't -- do they just require all libraries in the chain
to mention the versions of all the other libs they're linked against?

> And I would suggest not keying on major numbers, but on compile time
> changes, and thus the release numbers.

Well it's actually the major numbers that are required to indicate
binary compatibility, so they're the most "correct" indicator in
general.  However in guile, we've committed to changing all the lib
major numbers with each major release, so they're effectively
equivalent.

> Or does debian insist on upgrading a package without upgrading
> things that depend on it?

Right now Debian actually packages all the guile libs in
guile-1.6-libs, but that's only possible because we're planning to
bump the major sonames with every major release.  If we didn't then
binary packaging systems would have to have one binary package per
lib, i.e. libguile12*.deb, libguile-srfi*.deb, to accomodate for the
possibility that we might change the soname for some libs, but not all
of them in a given major release (i.e. unless we bump all of them,
guile-1.8-libs would have files that conflicted with guile-1.6-libs).

> If so, I think one has to have a new package name that can coexist
> on every incompatible change.  (NetBSD's make update does a
> pkg_delete -r and then rebuilds all the depending packages.)

One thing to keep in mind is that with a source-based distribution
like bsd or gentoo, many of these problems go away.  Having to support
multiple versions of installed binary packages definitely complicates
things.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> Either that or multiple prefixes, and I see that multiple prefixes are
> frowned upon by the FHS.  Since there is no proposal on the table to
> remove the ability to use --prefix, that's not an issue.

We'd definitely keep --prefix.  I think many of us use it all the
time, even under a distribution like Debian/RH, etc. for local
compiles.

> guile14-src $ ./configure --prefix=/usr/pkg/guile/1.4
> guile16-src $ ./configure --prefix=/usr/pkg/guile/1.6
> guile18-src $ ./configure --prefix=/usr/pkg/guile/1.8

Sure, I'd expect this to still work fine.

> Then, it would be good to understand the ripple effects on e.g. having
> guile-gtk for two guile versions installed - can that just adopt the
> same scheme?

Maybe -- now that we're talking about this again, I have the feeling
that I thought about the -L/usr/lib/guile/VERSION trick a while back
and rejected it for some reason :/  But if it works for guile, others
should also be able to use /usr/lib/FOO/VERSION for their own version
specific .so -> ../../libFOO.so.X.Y.Z  symlinks.

> bin/guile
> bin/guile-snarf
> bin/guile-config
> bin/guile-tools
>   put in bin/guile/X.Y, and symlink one to bin/guile

Actually I was thinking of ${bindir}/guile-X.Y{,-snarf,-config,...},
and perhaps an easy way to create the non-versioned symlinks.

this means that in the pkg approach, you'd probably have
/usr/pkg/guile/1.4/bin/guile-1.4, etc., unless we arranged for
--opt-style-install or similar.

> include/libguile.h
>   put in include/guile/X.Y/{libguile/*,guile/*,libguile.h}, with no symlinks.
>   people should be using guile-config/pkgconfig, so there is no need
>   to have anything work  unless the appropiate
>   -I/usr/include/guile/1.4 is given.

right.

> info/guile.info
> info/guile.info-1
> [...]
>   put in info/guile/X.Y/*, with symlinks from info if the
>   --primary-symlinks option was given.  This makes them all available
>   and the primary obtained by default.

This one is somewhat harder if we have any cross-links.  AFAIK there's
still no good solution for this, and if there is one, I'd *love* to
hear about it.  It's a real pain wrt the emacsen...

> lib/libguile.a

what I was thanking about is

  lib/guile/1.8/libguile.a
  lib/guile/1.8/libguile.la
  lib/guile/1.8/libguile.so -> ../../libguile.so.15.0.0
  lib/libguile.so.15
  lib/libguile.so.15.0
  lib/libguile.so.15.0.0

of course as I mentioned, we may have to have an enhanced ltdl before
this would work because we'd really need something like

  lib/libguile.la.15.0.0

rather than the above .la file.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Greg Troxel]

{list: I have received no hate mail for ranting so I presume this is
welcome; feel free to tell me otherwise!}

  > I hold up glib 1.2/2 as an example of a low-pain solution to what
  > would otherwise have been a very painful and chaotic transition.

  How do they handle it, and do they have the same dynamic-link issues?
  Also, how do they handle the app1 -> libfoo -> libgtk, and app1 ->
  libbar -> libbgtk with respect to upgrading, during the the period
  when libfoo has been recompiled against the new libgtk, but libbar on
  the system hasn't -- do they just require all libraries in the chain
  to mention the versions of all the other libs they're linked against?

libfoo stays with glib/gtk, and libfoo2 is built against glib2/gtk2.
For some things, the libraries have more substantial changes and have
entirely new names (see linc below, which is a 2-world thing only):

For foo = ORBit:

poblano gdt 997 ~ > ldd /usr/pkg/lib/libORBit.so
/usr/pkg/lib/libORBit.so:
         -lglib.13 => /usr/pkg/lib/libglib.so.13
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lintl.0 => /usr/lib/libintl.so.0

poblano gdt 1010 ~ > ldd /usr/pkg/bin/orbit-idl
/usr/pkg/bin/orbit-idl:
         -lglib.13 => /usr/pkg/lib/libglib.so.13
         -lIDL.0 => /usr/pkg/lib/libIDL.so.0
         -lgmodule.13 => /usr/pkg/lib/libgmodule.so.13
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lintl.0 => /usr/lib/libintl.so.0
         -lc.12 => /usr/lib/libc.so.12

poblano gdt 998 ~ > ldd /usr/pkg/lib/libORBit-2.so
/usr/pkg/lib/libORBit-2.so:
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -liconv.3 => /usr/pkg/lib/libiconv.so.3
         -lintl.0 => /usr/lib/libintl.so.0
         -lglib-2.0.200 => /usr/pkg/lib/libglib-2.0.so.200
         -lgobject-2.0.200 => /usr/pkg/lib/libgobject-2.0.so.200
         -lpthread.14 => /usr/pkg/lib/libpthread.so.14
         -lgthread-2.0.200 => /usr/pkg/lib/libgthread-2.0.so.200
         -llinc.1 => /usr/pkg/lib/liblinc.so.1
         -lgmodule-2.0.200 => /usr/pkg/lib/libgmodule-2.0.so.200
         -lpopt.0 => /usr/pkg/lib/libpopt.so.0

poblano gdt 1011 ~ > ldd /usr/pkg/bin/orbit-idl-2
/usr/pkg/bin/orbit-idl-2:
         -lpopt.0 => /usr/pkg/lib/libpopt.so.0
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -liconv.3 => /usr/pkg/lib/libiconv.so.3
         -lintl.0 => /usr/lib/libintl.so.0
         -lglib-2.0.200 => /usr/pkg/lib/libglib-2.0.so.200
         -lIDL-2.0 => /usr/pkg/lib/libIDL-2.so.0
         -lgobject-2.0.200 => /usr/pkg/lib/libgobject-2.0.so.200
         -lgmodule-2.0.200 => /usr/pkg/lib/libgmodule-2.0.so.200
         -lc.12 => /usr/lib/libc.so.12

There are 2 parallel worlds, one rooted on glib 1.2, and one on
glib-2.0.
This indeed doesn't scale, but it's the underlying interface changes
that break compiling that don't scale.  But it isn't quite that bad,
since in the guile world one would have the last guile-gtk version
that worked with guile 14, and one that works with 16.  Then there is
gnome-guile that does glib2/gtk2/ORBit2, and probably that would be
built for the new guile only.

  Well it's actually the major numbers that are required to indicate
  binary compatibility, so they're the most "correct" indicator in
  general.  However in guile, we've committed to changing all the lib
  major numbers with each major release, so they're effectively
  equivalent.

Consider a change that breaks binary compatibility but not compile
compatibility, say because there was a function and now it's a macro
and invokes some compatibility glue.  You have to bump the so number,
but upgrading the guile version doesn't require upstream maintainers
to do anything different, except maybe recompile.  This kind of change
doesn't hurt that badly in the package maintainer viewpoint, since it
doesn't force having to be able to compile against two versions at once.

  One thing to keep in mind is that with a source-based distribution
  like bsd or gentoo, many of these problems go away.  Having to support
  multiple versions of installed binary packages definitely complicates
  things.

It does, but named versions does this.  It looks ugly, but that's
because with a chain of n libs, you have 2^n versions.

Perhaps this is all a red herring and we can preserve compile-time
compatibility adequately.  Keeping the old libs around seems to be a
good solution for running old binaries.  In the specific case of
Gnucash, what about 1.6 made gnucash 1.6.8 not buildable, and was that
something that wasn't deprecated in 1.4?  We may be solving the wrong
problem.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Dale P. Smith]

On 27 Feb 2003 15:54:23 -0500
Greg Troxel <gdt@ir.bbn.com> wrote:

> {list: I have received no hate mail for ranting so I presume this is
> welcome; feel free to tell me otherwise!}
>

The guile-* lists are nice, warm, friendly place ...  as long as you don't
bring up the issue of #f not being eq? to '()

;^)

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x239               |


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Dale P. Smith]

On Thu, 27 Feb 2003 16:07:36 -0500
"Dale P. Smith" <dsmith@altustech.com> wrote:


Please forgive me, I meant that as private mail, not sent to the list.

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x239               |


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> {list: I have received no hate mail for ranting so I presume this is
> welcome; feel free to tell me otherwise!}

Well I'm interested, so don't worry about it :>

> There are 2 parallel worlds, one rooted on glib 1.2, and one on
> glib-2.0.  This indeed doesn't scale, but it's the underlying
> interface changes that break compiling that don't scale.  But it
> isn't quite that bad, since in the guile world one would have the
> last guile-gtk version that worked with guile 14, and one that works
> with 16.  Then there is gnome-guile that does glib2/gtk2/ORBit2, and
> probably that would be built for the new guile only.

Ahh, ok, thx.  One of the more aggravating questions which we've
already discussed to death here and on debian-devel, is how do I
handle allowing people to build the current version of g-wrap for
either guile 1.4 or guile 1.6 -- i.e. unless I embed the guile version
in g-wrap's libs' names (or the sonames), then there's no way to pick
a "correct" soname.

> Perhaps this is all a red herring and we can preserve compile-time
> compatibility adequately.  Keeping the old libs around seems to be a
> good solution for running old binaries.  In the specific case of
> Gnucash, what about 1.6 made gnucash 1.6.8 not buildable, and was that
> something that wasn't deprecated in 1.4?  We may be solving the wrong
> problem.

AFAIK gnucash just needed to be ported/updated.  I actually did that
work some time back for another project, but I don't think I preserved
the ability to use both guile 1.4 and guile 1.6, and at the time I
believe that would have been a problem.  I haven't been involved much
with gnucash lately, so I don't know where they actually stand on that
front, and unfortunately I don't think I have those changes anymore.
However, as far as I recall, I got gnucash working fine with guile
1.5.X.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Mikael Djurfeldt]

(Sorry for answering lately---been on vacation!)

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:
>
>> When Rob has added the GMP support there's only the signal handling
>> left of the major changes intended for the 1.8 release, right?
>
> There is also the issue of having good replacements for all of gh_.

I guess what I'm suggesting is to split the currently planned 1.8
into a leaner 1.8 and a 1.10, i.e., to make 1.8 less ambitious in
order to get out bugfixes and new technology faster.

The gh_ stuff (and other things in the current 1.8 TODO list) could be
done in 1.10.

> Also also, I promised rms to keep backwards compatability for a long
> time (and I do agree that it is important).  That means that the
> things that are deprecated in 1.6 and have already been removed from
> 1.8 need to be added back.

Yes, this would be a typical lean 1.8 thing, and is a good argument
why a lean 1.8 release wouldn't be painful.


I just want to add that this is only a suggestion.  While I think it
would be good to make a lean 1.8 release, I'm not going to argue
further for it.  :-)

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pkg-config support for guile

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

> Here is a patch against guile-1.6.1 to add pkg-config support.

Thanks.  I'm not sure what to do about this, tho.

I don't think we should offer two ways to get configuration
information about Guile.  When pkgconfig is better than our current
method, we should use it exclusively.  When not, we should keep our
current stuff.

(When I say "we should use pkgconfig exclusively", I mean we should
use it to re-implement guile-config in a compatible way.  We should
definitely continue to offer the guile-config interface.)

> The file won't be useful without pkg-config installed, of course,
> but this gives users a choice of configuration means.

Why would they need this choice?  [genuine question(tm)]

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pkg-config support for guile

[Greg Troxel]

  [I sent a patch to add pkg-config support.]

  I don't think we should offer two ways to get configuration
  information about Guile.  When pkgconfig is better than our current
  method, we should use it exclusively.  When not, we should keep our
  current stuff.

pkgconfig is better in that programs that use guile will not have to
include a guile-specific m4 fragment into configure - there is a
standard pkgconfig m4 fragment that suffices to link all programs that
use pkgconfig for config info.

But programs needing GUILE_MODULE_FOO will still need the guile m4.
This is really a separate problem from guile-config - using guile as a
scripting language rather than a libary, so not trying to use
pkgconfig here seems fine.

I don't understand why you think there should not be two ways.  Users
can use whichever way they like better, and this makes guile more
friendly.  Over time, I expect pkg-config to be more prevalent.  The
pkg-config support is very small, and most of the contents are
substituted via configure.  So having two ways is a reasonable
transition strategy.

  (When I say "we should use pkgconfig exclusively", I mean we should
  use it to re-implement guile-config in a compatible way.  We should
  definitely continue to offer the guile-config interface.)

Sure, the old interface should be retained.  But the real win comes
from people being able to just write a simple line to include the
library that is similar to how many other libraries are included.  I
have a line in some of my own (unpublished so far) sources that reads:

PKG_CHECK_MODULES(FOO, libfoo, AC_DEFINE(HAVE_LIBFOO), true)

The final 'true' prevents an error if the package is not found.

  > The file won't be useful without pkg-config installed, of course,
  > but this gives users a choice of configuration means.

  Why would they need this choice?  [genuine question(tm)]

Well, it seems the world is heading to a standardized method of
representing how to link with libraries (and handling recursive
dependencies, so linking with gtk gets you glib without explicitly
asking for it).  I view this as an abstraction of using libraries with
autoconf, and it's really only better because it implements a
well-defined interface instead of the ad-hoc
sort-of-like-other-packages homegrown one in guile.

The only downside is that the pkgconfig way requires that pkgconfig be
installed on systems where one links with pkgconfigized libraries.
pkgconfig is installed on most systems, since both the gnome and kde
worlds need it.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Neil Jerram]

[this is a very delayed reply to the thread about how to handle
multiple simultaneously installed Guile versions]

>>>>> "Greg" == Greg Troxel <gdt@ir.bbn.com> writes:

    Greg> {list: I have received no hate mail for ranting so I presume
    Greg> this is welcome; feel free to tell me otherwise!}

Your contributions here are very welcome.  So far, this issue seems to
run and run without ever being quite resolved; it would be wonderful
to finally come up with a solution that everyone is happy with.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

    Marius> Also, the deprecation mechanism should be made more
    Marius> user-oriented and be controlled with a macro like
    Marius> _GNU_SOURCE.

    Marius> Also also, I promised rms to keep backwards compatability
    Marius> for a long time (and I do agree that it is important).
    Marius> That means that the things that are deprecated in 1.6 and
    Marius> have already been removed from 1.8 need to be added back.
    Marius> I understand that this is an unwelcome mass of
    Marius> uninteresting work and I'm willing to do it myself, of
    Marius> course, eventually... :-/

These two `also's could be closely related, couldn't they?

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Release now?

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> >>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
> 
>     Marius> Also, the deprecation mechanism should be made more
>     Marius> user-oriented and be controlled with a macro like
>     Marius> _GNU_SOURCE.
> 
>     Marius> Also also, I promised rms to keep backwards compatability
>     Marius> for a long time (and I do agree that it is important).
>     Marius> That means that the things that are deprecated in 1.6 and
>     Marius> have already been removed from 1.8 need to be added back.
>     Marius> I understand that this is an unwelcome mass of
>     Marius> uninteresting work and I'm willing to do it myself, of
>     Marius> course, eventually... :-/
> 
> These two `also's could be closely related, couldn't they?

Yes, they are related, but they can be worked on independently.  I
hope that the 'per-inclusion' activation of deprecated things can be
done without changing our current internal method of marking things as
deprecated.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: pkg-config support for guile

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

>   [I sent a patch to add pkg-config support.]
> 
>   I don't think we should offer two ways to get configuration
>   information about Guile.  When pkgconfig is better than our current
>   method, we should use it exclusively.  When not, we should keep our
>   current stuff.
> 
> pkgconfig is better in that programs that use guile will not have to
> include a guile-specific m4 fragment into configure - there is a
> standard pkgconfig m4 fragment that suffices to link all programs that
> use pkgconfig for config info.
>
> But programs needing GUILE_MODULE_FOO will still need the guile m4.
> This is really a separate problem from guile-config - using guile as a
> scripting language rather than a libary, so not trying to use
> pkgconfig here seems fine.
> 
> I don't understand why you think there should not be two ways.  Users
> can use whichever way they like better, and this makes guile more
> friendly.

Yes, I agree.  I wasn't precise enough when I said "there should not
be two ways to get confiuration information about Guile".  I was
really only thinking about how we maintain the code for exporting this
configuration information, not about how users will access it.  That
is, my only worry is that when add support for pkg-config, and
continue to offer guile-config (which we should), then there is the
risk that the two mechanism diverge over time when they are separately
implemented.  There should only be a single point in the code where
the exported configuration information is defined and both user
interfaces (pkg-config and guile-config) should draw from that source.

For example, the "Libs:" line in guile.pc needs to stay in sync with
the corresponding stuff in guile-config.  This should happen
automatically.

Also, we will need documentation for how to use pkg-config with Guile,
maybe with a pointer to generic pkg-config.

That's what keeps me from applying the patch right away (and I hope
others agree that it is not unreasonable).

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel