I am trying to build a Builder for python extensions and I run into
some difficulties. The basic idea is to build *.c -> shared libraries,
but python defines via distutils.sysconfig.get_config_vars() precisely
which c compiler, which commands and flags should be used for compile,
link and so on. What I want to do is to use all of the existing c
infrastructure for dependency handling but run precisely the cmdline
that python provides to compile and link. I tried to use guess_shared
and overwrite some of it's calls, but guess_shared always changes
stuff around: dst "blah" becomes "libblah.dylib" which is not valid
for python (it should be "blah.so").
I am a bit lost and I have no idea how to properly implement this.
Could someone point me to a good start?
Cheers,
Holger
fbuildroot.py:
import fbuild.builders.c
import pickle
def build(ctx):
stdout, stderr = ctx.execute((
'/opt/local/bin/python2.6',
'-c',
'import distutils.sysconfig, pickle; '
'print pickle.dumps(distutils.sysconfig.get_config_vars())'
), stdout_quieter=1)
static = fbuild.builders.c.guess_static(ctx,
macros=pickle.loads(stdout))
static.build_exe('foo', ['foo.c'])
And I'll add some hooks in order to replace the .dylib to .so
extension. Theoretically the compiler shouldn't matter since c has a
standard calling convention. However, it's possible to set specific
executables, by explicitly picking the builder, and setting the
executable like:
import fbuild.builders.c.gcc
fbuild.builders.c.gcc.shared(ctx, exe='/usr/bin/gcc', ...)
Do you know of other restrictions though?
> --
>
> You received this message because you are subscribed to the Google Groups "fbuild" group.
> To post to this group, send email to fbu...@googlegroups.com.
> To unsubscribe from this group, send email to fbuild+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/fbuild?hl=en.
>
>
>
On 27 Dez., 02:11, Erick Tryzelaar <erick.tryzel...@gmail.com> wrote:
> Hm, well the first way I could see doing this is you could run an
> external python shell to get those variables. This could be a bit
> ugly, as in:
>
> fbuildroot.py:
>
> import fbuild.builders.c
> import pickle
>
> def build(ctx):
> stdout, stderr = ctx.execute((
> '/opt/local/bin/python2.6',
> '-c',
> 'import distutils.sysconfig, pickle; '
> 'print pickle.dumps(distutils.sysconfig.get_config_vars())'
> ), stdout_quieter=1)
>
> static = fbuild.builders.c.guess_static(ctx,
> macros=pickle.loads(stdout))
>
> static.build_exe('foo', ['foo.c'])
>
That's actually exactly how I did it. It didn't completly come through
because some hooks are missing
> And I'll add some hooks in order to replace the .dylib to .so
> extension. Theoretically the compiler shouldn't matter since c has a
> standard calling convention. However, it's possible to set specific
> executables, by explicitly picking the builder, and setting the
> executable like:
I tried this. I would also need complete control over how the library
is build (that is, he shouldn't use ar,
but use gcc for everything. And he shouldn't add -dynamic or
something, python dictates which switches to use)
> Do you know of other restrictions though?
When can you add those hooks? I'd really like to work on it while I am
on the conference I am currently attending ;)
Cheers,
Holger
When can you add those hooks? I'd really like to work on it while I am
on the conference I am currently attending ;)
Cheers,
Holger
I pushed out my changes. Now you can write:
def build(ctx):
stdout, stderr = ctx.execute((
'/opt/local/bin/python2.6',
'-c',
'import distutils.sysconfig, pickle; '
'print pickle.dumps(distutils.sysconfig.get_config_vars())'
), stdout_quieter=1)
shared = fbuild.builders.c.guess_shared(ctx,
macros=pickle.loads(stdout),
lib_prefix='',
lib_suffix='.so')
shared.build_lib('foo', ['foo.c'])