Greg Troxel writes:
> This .so=>devel does not make sense to me. I thought the point was
> that -devel split things that people who wanted to compile against the
> package needed, but not things needed to run.
It seems to me that the dynamic FFI performs, at run time, the same jobs
that a C com
On 12 February 2013 12:20, Nala Ginrut wrote:
> Put that link .so in guile rather than guile-devel is the exception I
> mentioned. The regular packaging policy not allow it.
>
[Again, referring only to Debian.]
Right. This applies only to libguilereadline-v-18.so, not
libguile-2.0.so. I had ov
在 2013-2-12 AM10:10，"Daniel Hartwig" 写道：
>
> On 11 February 2013 23:23, Greg Troxel wrote:
> > (First, "all mainstream distros" is only talking about Linux.)
> >
> > This .so=>devel does not make sense to me. I thought the point was
> > that -devel split things that people who wanted to compile
On 11 February 2013 23:23, Greg Troxel wrote:
> (First, "all mainstream distros" is only talking about Linux.)
>
> This .so=>devel does not make sense to me. I thought the point was
> that -devel split things that people who wanted to compile against the
> package needed, but not things needed t
Nala Ginrut writes:
> On Sat, 2013-02-09 at 16:12 +0100, Ludovic Courtès wrote:
>>
>> Daniel Hartwig skribis:
>> An issue with the FFI is distros where .la and .so files are only
>> available in the -dev package, because then ‘dynamic-link’ won’t work
>> unless that -dev package is installed (
Mike Gran skribis:
> Right now, the Guile project does a poor job of testing Guile on
> multiple platforms. Hydra does check that i686-linux, x86_64-linux
> and x86_64-darwin compile, but, that's about the extent of multi-platform
> testing. (There are Hydra jobs for Cygwin and Solaris, but, th
On 11 February 2013 17:38, Nala Ginrut wrote:
> But there's a different for MIME, since it should be a part of web
> module IMO (or not?). So I'm hesitated again.
There is no pressing need to include or not. While it is a work in
progress it is easier to distribute and inspect if it is an extern
> I have the feeling that we should implement our own dynamic-link
> function without libltdl. It would eliminate a dependency and allow us
> to use other search path rules, like ones that could deal with this
> case. I think the situation would actually be better on other
> architectures because
On Sun, 2013-02-10 at 09:41 +0800, Daniel Hartwig wrote:
> On 6 February 2013 21:13, Nala Ginrut wrote:
> > /usr/share/mime is contained in 'shared-mime-info' package, at least for
> > openSUSE. The suggestion you gave means Guile will depend on this
> > package. Personally, I don't think that's w
On Sat, 2013-02-09 at 16:12 +0100, Ludovic Courtès wrote:
> Hi,
>
> Daniel Hartwig skribis:
>
> > By the way, I very much like the conventions used in the GnuTLS
> > bindings. The enums in particular make a lot of sense for a security
> > library, with the extreme type safety they provide. I w
() Andy Wingo
() Mon, 11 Feb 2013 09:20:55 +0100
- Coordination cost (working with upstream on bugs/features)
For ltdl, my instinct is "no".
Just MHO :)
I imagine no one likes to hear the curmudgeon spew, but i feel it is my
duty (to GNU, Guile, and my fellow programmers) to trot ou
Howdy,
On Sat 09 Feb 2013 18:50, Mark H Weaver writes:
> Andy Wingo writes:
>
>> I have the feeling that we should implement our own FOO function
>> without libBAR.
>
> Wouldn't it be better to fix these problems in libBAR, to the benefit
> of all its users, than for each of its users to duplic
12 matches
Mail list logo
