From: Jeremy Katz <katzj@redhat.com>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: RE: [PATCH] reiserfs module for pygrub
Date: Mon, 23 May 2005 23:17:24 -0400 [thread overview]
Message-ID: <1116904644.3439.26.camel@bree.local.net> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D1E41B6@liverpoolst.ad.cl.cam.ac.uk>
On Tue, 2005-05-24 at 01:14 +0100, Ian Pratt wrote:
> > What if we check instead for the headers being present and
> > only building the filesystem modules that there's support for
> > on the system? Then distributors can ensure they have the
> > right things in their buildsystem and anyone else can do the
> > same. The attached patch should implement that for libext2fs.
>
> Seems a sensible approach to me. Some people will no doubt hate the fact
> that the output will depend on the build host. Perhaps have an
> environment variable that can be set to overide the autodetect? (and
> hence cause a build failure)
I guess it's easy enough to do something like this. I wish distutils
had a standardized way of doing things like this similar to autoconf
(... and this even with how much I hate autoconf ;-)
> > > Also, at runtime, are there
> > > issues with libraries being present? Can you load the library
> > > dynamically if required?
> >
> > The libraries get linked dynamically into the python module.
> > If at runtime, the library isn't present, it won't cause a
> > fatal error (you won't be able to access those types of
> > filesystems, but it won't fall over on the import)
>
> Given that the libext2fs is 90KB, I wander if we should just staticaly
> link? Not sure.
I'm not sure there's a way to do static linking in distutils without
completely reinventing the wheel. When you start thinking about lib vs
lib64 differences, this is less than fun.
Jeremy
next prev parent reply other threads:[~2005-05-24 3:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-24 0:14 [PATCH] reiserfs module for pygrub Ian Pratt
2005-05-24 3:17 ` Jeremy Katz [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-05-24 1:27 Ian Pratt
2005-05-24 3:17 ` Jeremy Katz
2005-05-24 4:09 ` aq
2005-05-24 4:15 ` aq
2005-05-24 19:34 ` Jeremy Katz
2005-05-25 21:57 ` aq
2005-05-19 1:32 Ian Pratt
2005-05-19 2:43 ` aq
2005-05-18 19:37 Ian Pratt
2005-05-19 1:15 ` aq
2005-05-23 23:57 ` Jeremy Katz
2005-05-24 1:04 ` aq
2005-05-18 18:46 aq
2005-05-23 23:57 ` Jeremy Katz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1116904644.3439.26.camel@bree.local.net \
--to=katzj@redhat.com \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.